test(conformance): score exponent splits on the inference primitive, and correct the metric

[gHashTag]

#586 scored splits on round-trip error, one element at a time, with no scale. That is the wrong workload for a quantised pipeline: every deployment applies a per-tensor scale before encoding, which removes exactly the dynamic-range pressure that wide exponents pay for.

This scores the primitive that actually runs — amax scaling, quantise weights, multiply against unquantised activations, sum.

It corrects itself once, and that is the finding

The first draft ranked on relative dot-product error alone. Under it, the golden rule's e3m4 beat both OCP FP8 splits at 8 bits, which looked like the first measured win for phi in this whole investigation.

It is not. That metric is dominated by the largest term, so a format can zero almost the entire tensor and still score well:

8 bits, one outlier 4096× the rest	weights zeroed
e2m5	98.9%
rule e3m4	97.6%
e4m3 fields	2.1%
e5m2 fields	0.0%

That is what the wider splits are for, and it is why OCP FP8 carries more exponent than the golden section would give it. Ranking is now among the feasible only, gated at 1% flushed.

Results, after the gate

width	rule	best feasible	note
8	e3m4, 3.5e-02	e3m4	e2m5 excluded — zeroes 1.6%
16	e6m9, 2.0e-03	e3m12, 1.7e-04	rule is 11× worse
32	e12m19, 1.7e-06	e4m27, 8.1e-09	rule is 207× worse

Rows are labelled "fields", deliberately

They carry the field widths of the named formats and not their specials. Measured: this e4m3 tops out at 480 where OCP FP8 E4M3 stops at 448 (its all-ones row is NaN); this e5m2 reaches 114688 where OCP E5M2 stops at 57344. Naming a row after a standard it does not implement is how "IEEE binary32" ended up on a row with different specials in #586.

Regime note, from the literature not from taste

E4M3 is the weight format and E5M2 the gradient/activation one, because activation outliers run around 100× the typical value while weight tails are far milder. This benchmark quantises weights only, so it exercises the E4M3 regime and says nothing about the one E5M2 exists for.

A tooling defect this uncovered

The format table read back as e5m11 on one run and e6m10 on the next while the file on disk said e5m10 both times. Cause: most mutations preserve the file's length, and Python decides a .pyc is current from the source's (mtime, size) — restore inside the same filesystem second and the interpreter serves bytecode compiled from the mutant. tri mutate now clears derived caches (t27#2177). Second contamination of this kind in two iterations.

What this still does not establish

No network was run and no task accuracy was measured. Activations are unquantised and the accumulator is exact, so this isolates weight quantisation and nothing else.