Coursework

DNA data-storage simulator

The problem

DNA can hold data for a very long time in very little space, but writing and reading it is noisy in a way disks are not. Besides wrong letters (substitutions), the chemistry drops letters (deletions), adds letters (insertions) and loses whole strands (erasures). An insertion or deletion shifts every letter after it, so codes built for wrong letters alone cannot recover the data.

What I built

• An encoder that maps data into DNA strings, a reversible two-bits-per-letter mapping, plus a separate visualisation that reports GC content and long runs of one letter.
• Noisy-channel simulations with substitutions, insertions, deletions and erasures. The Python simulations expose seeds; the repository’s standalone browser demo draws fresh random errors.
• Three ways back: Reed–Solomon codewords for substitutions and erasures, LT-style fountain codes decoded by belief propagation for lost strands, and a simplified HEDGES-style beam search for insertions and deletions.
• Eight figures and an interactive browser demo, so each stage can be seen, not only read about. An individual project in a group-based course.

Result

These are synthetic teaching simulations, not physical storage experiments. The Python figures use seeded channels; the repository’s standalone browser demonstration uses fresh randomness, so its noisy runs are not reproducible by seed. This site’s DNA channel is a separate, seeded illustration. No measured physical-storage performance is claimed.

How it works

1. 01Databits
2. 02Encodetwo bits per letter
3. 03Channelsubs, indels, erasures
4. 04DecodeRS, fountain, beam search
5. 05Data backor a stated failure

Limits

• The HEDGES-style decoder is a simplified custom beam search, not the published HEDGES algorithm.
• The Reed–Solomon figure encodes codewords but does not run a decoder, and its seeded case (two erasures plus one unknown error) is outside the RS(10,7) correction bound.
• The fountain example is a construction check, not a robustness measurement, and the bits-per-letter curve is a hand-coded reference for plotting, not a measurement.
• The GC illustration is not a balancing codec: complementing A/T and C/G cannot change the GC fraction.

SysY to LLVM IR compiler

The problem

A compiler has to turn source code into something a real toolchain accepts, with every corner of the language right: calls that return nothing, short-circuit evaluation with side effects, nested loops with break and continue, names that shadow other names.

What I built

• A compiler for a subset of SysY, a C-like language, written in Java.
• A visitor-based generator that emits LLVM IR through the LLVM 13 C API, over an ANTLR4 grammar based on the course’s.
• An individual course project. The code stays private under the course’s rules, so this page describes it rather than linking it.

Result

In a recorded post-course check, I added 12 extra test programs covering void calls, short-circuit side effects, nested break and continue, recursion, shadowing, hex and octal literals, and early returns. The check compared executable exit statuses against clang compiling the same source as C. It found a named call to a void function, which is invalid IR. After a two-line fix, the recorded run matched exit statuses for all 30 programs. This is historical evidence, not a fresh run or a comparison of full program output.

How it works

1. 01SysY sourcea subset of C
2. 02Lex and parseANTLR4
3. 03Visit the treetypes, scopes
4. 04Emit LLVM IRLLVM C API
5. 05Compareexit status vs clang

Limits

• Public case study only: the course solutions and grammar remain private.
• A fresh compiler run was not performed in this review because the required Java/LLVM toolchain was unavailable.
• Matching exit statuses does not establish matching stdout, full semantic equivalence or correctness for arbitrary programs.
• Array syntax is accepted by the grammar but is not implemented by the IR generator.

Links

• Repository: dna-storage-simulationgithub.com/Oscar-Codespace/dna-storage-simulation