stillwater-sc / universal / 26733598966

84%

master: 84%

Build Type

push

github

Committed by web-flow

Commit Message

fix(elreal): addRec_step renormalization breaks 0-overlap (#1034) (#1036)

add() could emit a value-correct but non-0-overlap (and even out-of-order)
block stream whenever one operand stream became empty while the workspace still
held blocks that belonged between the pending blocks of the other operand.

Minimal trigger:
  add(2^-90, [2^0, 2^-60]) -> [2^0, 2^-90, 2^-60]   (wrong: out of order)
  correct                  -> [2^0, 2^-60]

Root cause: in addRec_step's "one operand empty, workspace non-empty" cases, the
code drained the workspace (emitting workspace.front() repeatedly) and then
streamed the non-empty operand -- never merging that operand against the leftover
workspace. The dissertation's addRec re-injects the workspace tail into the
operand slot (`addRec fs [] (e:es) = e : addRec fs es []`), which the comment
even stated but the code did not do. Fix: after emitting the workspace head,
re-inject removeZeros(workspace tail) as a ZBCL into the now-empty operand slot
(symmetric for fs/gs) so the twoSum/threeAdd merge continues correctly. Adds a
zbcl_of_vec helper.

This fixes both the single-add case and the deep lazy-fold composition that
Phase 5 worked around via priestRenorm (a future sum() could now chain add()).

Regression test elastic/elreal/arithmetic/add_renormalization.cpp covers the
minimal trigger, the 2^(-30 i) regroup fold, and an operand landing between
workspace blocks; checks 0-overlap + exact dyadic value.

All 21 elreal tests pass on gcc and clang (Release) and with assertions on; no
regression in addition.cpp / threeAdd.cpp.

Resolves #1034

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Coverage Stats

6 of 9 new or added lines in 1 file covered. (66.67%)

3 existing lines in 2 files now uncovered.

47095 of 55952 relevant lines covered (84.17%)

6028268.96 hits per line