Re-run the precision-invariance experiment under matched stopping (current numbers are uncontrolled)

[neuromechanist]

Surfaced via #206, where 0.971 was read as the cost of float32. Investigating that reading showed the number cannot support any float32 claim, in either direction: the comparison is not controlled.

The defect is in the experiment, not the wording

.context/issue-90/ksweep_findings.md:56 records the cause:

at k=152 the f32 run hit the natural-gradient lrate floor (1e-12) at iter 1735 and stopped early, landing on a marginally different optimum than the full-2000-iter f64 runs.

So the k=152 rows in docs/guides/validation.md:278-284 compare a 1735-iteration f32 run against 2000-iteration f64 runs:

Pair (at k=152)	|corr|	what it actually varies
native-Fortran f64 vs PyTorch-CUDA f64	0.995	implementation
native-Fortran f64 vs PyTorch-CUDA f32	0.971	implementation + precision + 265 fewer iterations
PyTorch-CUDA f64 vs PyTorch-CUDA f32	0.979	precision + 265 fewer iterations

Precision and iteration count are confounded. Neither 0.971 nor 0.979 isolates anything, so no amount of relabelling makes them mean what the surrounding prose says they mean. The published guide currently attributes the residual to "the float32 path" while the controlled contrast that would establish it was never run.

This also sits badly against docs/guides/validation.md:200, which calls k=30 "the definitive float32 == float64 result" at 1.000. Both arms completed 2000 iterations there, so that one IS controlled, but the two sections then appear to contradict each other with no stated reason.

What a correct experiment looks like

• Matched stopping across arms. Either pin all arms to an identical iteration count, or record and report the per-arm stop iteration and reason alongside every number.
• Identical seed and initialization across arms, so precision is the only variable in the precision contrast.
• Separate the contrasts rather than mixing them in one table: precision alone (same implementation, same device, f32 vs f64) and implementation alone (Fortran f64 vs torch f64).
• Sweep k, since the effect is k-dependent and a single k cannot distinguish "precision matters more on larger data" from "the f32 arm stopped early on larger data".
• Report log-likelihood as well as matched component correlation. LL is the objective being optimized; correlation is a downstream proxy and is degenerate on under-determined components.
• Re-derive the guide's float32 guidance from whatever the controlled numbers show, rather than editing the prose around the existing ones.

Sequencing: blocked on #207

#207 adds the missing Fortran convergence criteria (min_dll/maxincs, min_nd/use_grad_norm) to AMICATorchNG. The early stop that confounded this experiment was lrate_floor firing, so #207 changes stopping behaviour directly. Re-running before it lands would produce numbers that are stale on arrival.

Scope note

docs/guides/validation.md is the reproduction reference cited by the JOSS paper (openjournals/joss-reviews#11093). The paper itself claims "single-precision runs agree with double precision to four or five significant digits", which is a log-likelihood claim rather than a correlation claim and is not the same statement as these rows; check whether it traces to a controlled run before the paper is finalized.

[neuromechanist]

Design decision: all arms run to a matched fixed budget, 2000 or 6000 iterations, with the convergence criteria explicitly disabled for the experiment (use_min_dll=False, use_grad_norm=False). No arm is allowed to self-terminate. That makes precision the only variable in the precision contrast, which is the whole point.

Running 6000 as well as 2000 is worth the compute. Two things it settles that 2000 cannot:

• Whether the ~0.98 plateau is a precision floor or just unfinished convergence. The NG backend is already known to need roughly twice Fortran's iterations to reach the same mean log-likelihood (ADR 0003 / Multi-model NG log-likelihood is ~0.02 lower and more variable than Fortran #51), so a plateau measured at 2000 may simply be the slower arm not having arrived yet.
• Whether f32 and f64 converge to the same optimum given enough budget, or to genuinely different ones.

Cost is not a concern: CUDA float64 is ~39 ms/iteration at 70 channels, so 6000 iterations is a few minutes per arm.

One caveat that must not get lost in the write-up

Forcing matched iterations removes the confound, but the early stop is itself plausibly a float32 effect, not an accident: the lrate annealed to its 1e-12 floor because the log-likelihood kept decreasing, and f32 rounding noise near convergence is a likely cause of those decreases. If so, "f32 anneals to the learning-rate floor earlier than f64" is a real finding about float32, not noise to be engineered away.

So the experiment should report both:

1. The matched-budget contrast (2000 and 6000, no early stopping) — this is the clean precision comparison and the one the guide's claims should rest on.
2. The unconstrained behaviour — for each arm, whether it would have stopped early, at which iteration, and why. Recorded as a property of float32, not suppressed.

Reporting only (1) would replace a misleading number with an incomplete one.

Also needs checking

Whether the lrate floor break in AMICATorchNG can even be suppressed for an experimental run without patching the class. If it cannot, that is a testability gap worth fixing as part of #207, which is already touching this exact code path.