docs: soften tiny oracle self-test expectation

[CooperSheroy]

Summary

Soften the tiny-oracle self-test wording from a hard 32/32 expectation to the maintainer-confirmed ~30-32/32 range when floating-point near-ties flip top-1 on some toolchains.

Validation

• make check
• CUDA changes were tested with make -C c cuda-test (if applicable)
• Performance claims include hardware, commands, and repeatable measurements

Compatibility

• The default CPU build remains dependency-free
• No model files, generated binaries, or benchmark artifacts are included

Closes #482

[JustVugg]

Thanks for this, and for approaching it from the honesty angle rather than just filing a complaint — a docs claim that overstates what the code does is a real defect, and #482 raised a legitimate one.

I approved the workflows (they were held because this is your first PR here — my oversight, not yours) and I also ran the gate myself before answering, because I didn't want to weaken a headline claim on a single datapoint:

$ SNAP=./glm_tiny TF=1 ./colibri 64 16 16
PREFILL (teacher-forcing) C vs oracle: 32/32 positions

gcc -O3 -march=native, x86-64 Linux, current dev. 32/32. So "typically 30-32/32" doesn't match the reference build — on it, the claim as written is exactly true. @woolcoxm's 30/32 in #482 is real too, and the near-tie explanation is almost certainly right, but it's toolchain-specific rather than typical.

Two things also worth knowing: make check does not run this gate, so CI neither confirms nor contradicts either of us; and the two positions in question are floating-point near-ties, which is precisely the case where compiler flags (FMA contraction, vectorization, a different libm) legitimately change the result without anything being wrong.

So I'd like to keep the strength and add the condition, rather than downgrade the claim. Something like:

The forward pass is validated token-exact against a transformers oracle (teacher-forcing 32/32 on the reference build). Two of the tiny oracle's positions are floating-point near-ties, so a different compiler or flags can flip them — see #482.

That tells a reader both true things: the engine is token-exact where we measure it, and here is the honest caveat with a pointer to the evidence. "Typically 30-32" tells them we're unsure, which isn't what the measurements say.

Would you rework it along those lines? Happy to take it either as an update here or to keep discussing the wording — and if you can reproduce 30/32 on a mainstream toolchain, that changes my mind and I'd rather know.

[JustVugg]

Heads-up: this now conflicts, and it's my doing — #521 rewrote the "Get started" sections of README.md and the quickstart a few hours ago, which is exactly where your changes land. Sorry for moving the ground under an open PR.

The substantive question from my previous comment still stands (I measure 32/32 on the reference build, so "typically 30-32/32" doesn't match what the gate actually reports), so if you rebase, it's worth folding both in at once: rebase onto current dev and reword to keep the claim's strength while stating the condition — token-exact 32/32 on the reference build, with the two floating-point near-ties and a pointer to #482 as the honest caveat.

If the rebase is annoying, say so and I'll take the wording from here and credit you — you found a real gap between what we claim and what we verify, and that shouldn't be lost to a merge conflict.

[JustVugg]

Reminder that this still needs a rebase — my #521 rewrote the same README/quickstart sections, so it conflicts. The substance (softening the oracle claim) I'd still like to fold in, but with the wording we discussed: keep "token-exact 32/32 on the reference build" and add the near-tie caveat + #482 pointer, rather than downgrading to "typically 30-32". If the rebase is a hassle, say so and I'll take the wording from here with credit to you.