A JavaScript reporting job sums millions of floating-point amounts, and its totals disagree with the source ledger by small amounts that change when the rows are processed in a different order. How do you diagnose this and decide on a fix?

## The symptom names the cause A total that changes with input order is close to a proof that the drift is floating-point accumulation rather than a logic bug. Real logic bugs — a bad filter, a duplicated row, a timezone boundary — usually shift the total by a recognisable amount and do not care about ordering. Rounding drift changes by tiny quantities that move when the order does. ## Why order matters Floating-point addition is commutative but *not associative*. Each `+` computes the exact sum of its two operands and then rounds that to the nearest double. Do it in a different order and you round different intermediate values: ```js const xs = Array(1e6).fill(0.01); xs.reduce((a, b) => a + b, 0); // 10000.000000171856, not 10000 ``` A million tiny roundings, each well under an epsilon, add up to a visible discrepancy. Note that this is not engine nondeterminism — the specification fixes the operation and the evaluation order, so the same order always yields the same total. It is the *choice* of order, made by your pipeline, that varies. ## Absorption is the sharper effect The more dramatic version is absorption (or swamping): when the running total is much larger than the next addend, the exact sum rounds straight back to the running total and the addend vanishes. ```js const vals = [1e9, ...Array(1000).fill(1e-9)]; vals.reduce((a, b) => a + b, 0) - 1e9; // 0 - all lost [...vals].reverse().reduce((a, b) => a + b, 0) - 1e9; // ~9.5e-7 - retained ``` Accumulating the small values first and the large one last preserves them; the other order discards a thousand additions entirely. This is why the same dataset reconciles when it arrives sorted and fails when it arrives by insertion order. ## Diagnosing it properly 1. **Freeze an input.** Capture one batch and make the job reproducible over it. 2. **Compute an exact reference.** Sum the same values as integer minor units, where addition cannot round. That total is the truth to compare against. 3. **Vary only the order.** Sorted ascending, sorted descending, shuffled. If the totals move and all sit near the exact reference, it is rounding. If one order is off by a whole unit or a whole row's worth, look for a data bug first. 4. **Characterise the magnitude spread.** Absorption needs a wide dynamic range; a million similar-sized values drift gently, whereas a few huge values among many tiny ones lose whole populations of addends. 5. **Check the reconciliation rule.** Often the real defect is that two systems compare totals for exact equality across representations that were never guaranteed to agree. ## The options, and what each one commits you to - **Exact integer accumulation.** Sum minor units. The drift does not shrink, it ceases to exist, and the total is order-independent and reproducible. This is the right answer whenever the domain is discrete — currency, counts, quantities with a fixed scale. It costs a representation change at the boundaries. - **Compensated summation (Kahan, or Neumaier for wide ranges).** Keep a second variable holding the error lost in the last addition and feed it back into the next one. Cheap, local, and dramatic: ```js function kahanSum(xs) { let sum = 0, c = 0; for (const x of xs) { const y = x - c; const t = sum + y; c = (t - sum) - y; sum = t; } return sum; } ``` It reduces error to near a single rounding, but it is still approximate and still order-sensitive in principle. - **Pairwise summation.** Add recursively in halves so error grows like log(n) rather than n. Naturally suited to chunked or parallel aggregation. - **Sorting by magnitude before summing.** Cheap to describe, expensive at scale, and it only mitigates absorption. - **Moving the aggregation to a component with exact decimal arithmetic.** A legitimate architectural answer when the data already lives there, at the cost of splitting where business rules run. ## The decision is about the domain The question a principal engineer actually answers is not "which summation algorithm" but "does this number have to be exact". A ledger total that must reconcile to the cent, feed an audit, or match a partner's statement is a discrete quantity and should never have been a float — the drift is a symptom of a representation mistake, and compensated summation would merely hide it below the current threshold until volume grows. A p95 latency, a sensor average, a forecast input is genuinely continuous; there exactness is meaningless and the right output is a documented error bound. So settle three things and write them down: which quantities in the system are exact by representation; what tolerance the approximate ones reconcile within, expressed relatively rather than as a fixed absolute; and where the aggregation of record happens, so two components never independently sum the same rows in different orders and then compare for equality. Make it a property of the platform rather than a fix applied to one report, or the same investigation recurs in the next quarter's dashboard.