As in, the paper itself should be part of the reproducible build/eval pipeline. So many benefits:
- no manual copy/pasting
- prevent stale data issues
- easy to frequently recompile, for better dev experience
:)

oh graphing _within_ typst? that does sound cool!

We haven't used it here, but tables directly from csv is something I'm personally super hyped about.

If you also have the plotting, and then `typst watch`, things can be as simple as `./run_evals > data.csv` and then the paper is directly updated

Waaiittttt, so _specifically_ Z_2 and Z_3 are off. That's so strange. Yes I'm curious for the intuition :)

(also sorry I should have actually read the appendix more carefully -- just had more phone than pc time today)

But eps_i is not a random variable right? Since all expectations are already in the first E[Z_i]?

In that case you probably want the average eps_i instead of E_i[eps_i]?

I'm assuming this is all still in the infinitely long sequence limit? Or does it also hold for random finite sequences?

Surely they *are* identical though (but clearly not independent)?

But ok I finally understood thm 1 now. I was confused by the E[eps], since eps is not defined, and assumed you somehow meant E[eps_i]=E[Z_i]-mu instead (which in hindsight doesn't make sense as eps_i already is an expectation itself)

Ok, so then maybe the question is what is the right definition of mu. An expectation of the average or just an expectation?

So what I don't really get is why this needs a proof at all. Is this not simply true by definition?

Density: expected fraction of sampled kmers.
Expected gap = average gap = len/#samples = 1/density?

One could also take a De Bruijn sequence of sufficient order, where clearly 1/density=avg gap?

see this is what I meant re: facet's direction. if I'm not trying to make the tiniest lib ever I'm free to make it have the best DX/UX

It's just the preprintx template, and 'zero' for tables. Only (i think) customization is that we added level-4 headings for paragraph titles.

share.google/yMRotRTE1GQQ...

Pro only, like overleaf. Which is fair enough

First up: writing a toy gzip implementation to understand how this format even works, and what typical fastq.gz files look like (since compressors have freedom in how they compress things).

The language itself seems quite nice. Definitely learnt a lot from Tex, and there's some nice packages that **just work**. Like, rounding your data and displaying it with 3 significant digits (as most data should be) is pretty quick to figure out. No more being held back by the system's limitations.

I will never be able to code in web IDEs though. Even though the typst.app vim mode seems ok, it's just never gonna be as smooth as my native setup. Also, looks like it doesn't have history? I really don't like working on collaborative projects without proper versioning to check diffs.