fiddlerwoaroof/improvise
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(core): the exactness test merges both ways and from_parts refuses sums that contradict their counts (improvise-qddo)

Browse Source 
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VdfEGXA7aJ6ftMsCc9PJze
This commit is contained in:
Claude (dbsp-sources)
2026-10-10 19:48:34 -07:00
committed by Edward Langley
parent 8ba4bd0a6c
commit f7404778b0
3 changed files with 33 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
context/code/source.md
+2 -1
View File
@@ -79,5 +79,6 @@ lists, and two), at both widths and for all five functions: over 5,000 triples.
`Summary::from_parts(Numbers::from_parts(count, exact_sum, least, greatest)?, Agreement)?`. `Agreement`
is what the non-number values hold: `None`, `One(v)` or `Mixed`. Both constructors return a `Result`
and **refuse** a state no sequence of values could produce (extremes with no numbers, a NaN extreme,
least above greatest, one extreme without the other, a number among the "others"), because repairing
least above greatest, one extreme without the other, a sum with no numbers, no extremes beside a sum
that is not NaN, a number among the "others"), because repairing
it would hide an engine's bug.
context/test-evidence/core.md
+6 -3
View File
@@ -2317,7 +2317,8 @@ lost). The first two also fail `aggregating_differing_text_values_is_an_explicit
Review of #356 (Opus): the pool gained `1e16`, `1.0`, `-1e16`, `0.1` and `0.2`. A merge rounding each part's
sum before pooling, keeping the zero sign, changed 514 production answers while the workspace passed;
that rival now fails this test, `numbers_pool_what_the_formula_aggregate_pools` (a NaN-free split now,
compared as bits), `summaries_built_from_parts_merge_as_the_union_does` and the fixture test below, by name.
compared as bits), `summaries_built_from_parts_merge_as_the_union_does` and the fixture test below, by
name: four tests, for each of the three round-then-pool variants.
A read of several parts is a merge. The test merges every ordered pair of sequences of up to two
values and compares with the reference of the concatenation. Rivals: the least not merged, the
@@ -2369,12 +2370,14 @@ Review of #356 (Opus, Codex): `from_parts` repaired some impossible states and a
The earlier entry's claim that a NaN-extreme rival failed `parts_that_contradict_themselves_...` was
false: that test passed with the filter removed. Rivals now, each failing this test alone: NaN extreme
allowed, least above greatest allowed, extremes with no numbers allowed, a number accepted among the
others.
others, a sum with no numbers allowed, and no extremes beside a sum that is not NaN allowed.
### the_exact_sum_of_a_pool_of_cancelling_values_is_not_the_sum_of_rounded_parts
An exactness test needs inputs whose float sum is inexact and no NaN. `1e16 + 1.0 - 1e16` rounded part
by part is `0.0`; pooled exactly it is `1.0`. This pins the fixture rather than the code.
by part is `0.0`; pooled exactly it is `1.0`. The merge runs in both orders, so whichever part a rival
rounds is the inexact one: rounding only the other part, only self, or both each fail it (the first
version merged one way and a rival rounding only the exact part passed it; Opus caught that).
### keys_of_a_store_are_its_cells_keys_without_the_values