T27.AI

Blog

Equal stored width removed an accuracy lead

2026-08-21 · 6 min read

A corrected equal-stored-width remeasurement withdrew an earlier 2.1×/2.6× lead over takum and records the oracle and budget defects that changed the reading.

MeasurementReproducibilitySelf-critiqueFPGAAccuracy

[measured — equal stored width] The site’s earlier 2.1×/2.6× accuracy lead over takum was withdrawn after a remeasurement exposed two confounds: an oracle sign error on negative codes and a nominal rather than equal-stored-width budget.

At 16 stored bits, TNF(4,8) records 5.323e-3 against takum16 at 5.697e-3. At 32 stored bits, TNF(4,24) records 1.203e-7 against takum32 at 1.264e-7. Under the equal-stored-width comparison, these values are treated as a tie rather than an accuracy lead; the earlier 2.1×/2.6× statement remains visible as retracted.

Why the result changed

The earlier number combined a faulty sign path with a budget that did not count stored width on the same basis. The correction keeps the old claim visible, records why it was withdrawn, and moves the comparison to the measured equal-width rows.

Stored widthTNFtakumReading
16 bits5.323e-35.697e-3tie at equal stored width
32 bits1.203e-71.264e-7tie at equal stored width
A corrected number is more useful when the retracted number remains visible.

What this does not establish

The useful engineering result is procedural: preserve the withdrawn figure, name the oracle defect and budget mismatch, and keep the equal-width measurement beside the correction. That makes a change in belief auditable rather than silent.

What this does not settle

Receipts

Every figure above is measured, and the limits are named with it.