SAME SUM

What stays the same

The values are generated once from seed 4217: 1,534 moderate values with magnitudes between 2⁻⁶ and 2⁹ and random signs, each rounded to a multiple of 2⁻²⁰. Two more values complete the set: L, the binary64 nearest φ · 2⁴⁰ as evaluated (about 1.78 × 10¹²), at stored position 385, and −L at stored position 1,153.

Every order adds each of the 1,536 values exactly once, one at a time, into a single binary64 accumulator that starts at zero. Nothing else touches the running total.

What changes

Only the permutation. Given keeps the stored order. Ascending and Descending sort by |x| with a stable tie rule, so +L comes before −L in both.

In real arithmetic, addition is commutative and associative, so all three orders share one exact sum. In binary64, every addition rounds its exact result to the nearest number with a 53-bit significand, and the next addition starts from that rounded value.

Why the large pair matters

While the accumulator holds L, whose exponent is 40, its lowest kept bit is 2⁻¹². Contributions below 2⁻¹² cannot be represented independently at that scale. Rounding to nearest can move the stored result upward or downward; the signed correction records the difference. When −L arrives the subtraction is exact (Sterbenz's lemma applies), but it only removes L. It cannot undo earlier rounding errors.

Without L, every partial sum of these grid values is smaller than 2²⁰ in magnitude and so needs at most 40 significant bits; those additions cannot round. Given holds L for 768 additions. Ascending meets L once, at step 1,535, with the whole moderate total in the accumulator. Descending cancels the pair in its first two steps.

An exact ledger

Every value here, and every stored partial sum, is an integer count of 2⁻²⁰, kept as a BigInt. The exact running totals are integer sums. Knuth's TwoSum recovers the rounding error of each floating-point addition as a binary64; the page checks it against the BigInt difference at every step, and checks that computed total plus the sum of signed rounding corrections equals the exact total for each order.

Every dyadic fraction has a terminating decimal expansion, so the audit decimals below are exact. Readouts marked with a place count are rounded for display.

What this exhibit does not test

It is not a ranking of summation orders. Sorting by increasing magnitude is common advice and often limits error well; in this specimen, the opposite order wins because the largest values cancel. Descending is exact for this multiset, not in general.

Compensated (Kahan–Babuška, Neumaier) and pairwise summation change the algorithm rather than the order, and are outside this study. No fused multiply-add, extended precision or reassociation is involved: ECMAScript defines Number addition as IEEE 754 binary64 with ties to even.

Further reading

David Goldberg, What Every Computer Scientist Should Know About Floating-Point Arithmetic (1991). Nicholas J. Higham, “The Accuracy of Floating Point Summation,” SIAM Journal on Scientific Computing 14 (1993). Donald E. Knuth, The Art of Computer Programming, Vol. 2, §4.2.2, for the exact error of a floating-point sum. ECMAScript Number::add specifies the arithmetic used here.