When does math.fsum give a different total than the built-in sum() over the same floats?

### The mechanism: every addition rounds A Python `float` is an IEEE 754 binary64 value with 53 bits of significand. Every arithmetic operation on two floats computes the exact mathematical result and then rounds it to the nearest representable float. One rounding is at most half an ulp (unit in the last place) of error — tiny. The problem is that a summation performs one rounding **per addition**, and those errors do not cancel. Add `n` values left to right and the worst-case relative error grows with `n`; add values of very different magnitudes and the small ones are rounded straight out of the running total, because the exact sum needs more than 53 bits to hold. This is the "absorption" failure: once the accumulator reaches `1e16`, adding `1.0` to it cannot change it, so the `1.0` is silently discarded. The error is a property of the accumulation order, not of the inputs — which is why naive float summation is not even commutative. ### What the built-in `sum()` actually does today The interview folklore is that `sum()` drifts and `math.fsum()` fixes it. That was true through Python 3.11, where `sum([0.1] * 10)` returned `0.9999999999999999`. **In Python 3.12 the built-in `sum()` was changed to use Neumaier compensated summation for floats** (and for mixed ints and floats). It keeps a second float `c` that carries the low-order bits lost by each addition, and adds `c` back at the very end. On 3.12 and later — including 3.14 — `sum([0.1] * 10)` returns exactly `1.0`, and the result is far less dependent on ordering. So the honest answer to "does `sum()` drift?" starts with *when*: on any currently supported interpreter it compensates, and for ordinary data — a column of prices, a list of durations, a million samples of the same rough magnitude — it now agrees with `math.fsum` bit for bit. Note what is **not** compensated: a hand-written accumulator. `total = 0.0` followed by `total += v` in a `for` loop, or `functools.reduce(operator.add, values)`, or `itertools.accumulate(values)`, all still perform plain left-to-right addition and still produce `0.9999999999999999` on 3.14. The compensation lives inside `sum()`, not in the `+` operator. ### What `math.fsum` does differently `math.fsum` implements Shewchuk's exact-summation algorithm. Instead of one running total plus one correction term, it maintains a **list of non-overlapping partial sums** whose exact mathematical sum equals the exact sum of everything consumed so far. Each incoming value is merged into that list using exact two-sum arithmetic, so nothing is ever thrown away mid-stream. Only at the very end are the partials collapsed into a single `float`, with **one** rounding. The guarantee is therefore stronger than "more accurate": the result is the *correctly rounded* value of the exact sum, and it is independent of the input order. Neumaier's single correction term is not always enough, because the discarded bits can themselves be too large to represent alongside `c`. Three or more widely separated magnitudes that cancel is the standard counterexample, and it still separates the two functions on 3.14: ```python import math values = [1e40, 1e20, 1.0, -1e40, -1e20] sum(values) # 0.0 -- the 1.0 is absorbed and never recovered math.fsum(values) # 1.0 -- the exact total, rounded once ``` ### The cost, and when to pay it `math.fsum` is roughly two to three times slower than `sum()` on a long list of floats, and it allocates a small partials list. It also has a sharper failure mode: an intermediate partial can overflow, and `math.fsum([1e308, 1e308, -1e308, -1e308])` raises `OverflowError`, where `sum()` quietly returns `inf`. A `nan` anywhere propagates through both. Reach for `math.fsum` when the data genuinely spans many orders of magnitude, when there is heavy cancellation between large positives and large negatives, when a residual or a difference of two sums is the quantity of interest, or when a total must be reproducible regardless of the order rows arrive in. Reach for `sum()` everywhere else — it is the default for a reason, and since 3.12 it is a good one. ### What neither of them is for Accuracy is not exactness. If the requirement is that a total of money be *exact* to the cent, no binary summation is the answer, however well rounded — that is a job for exact decimal arithmetic. And if you are averaging, `statistics.mean` already sidesteps the whole question by accumulating in exact rational arithmetic (`statistics.mean([0.1] * 10)` is exactly `0.1`), while `statistics.fmean` is the fast float path. The senior version of this answer is to stop asserting a total is "wrong" and instead say by how much: compute both totals, take the difference, and compare it against a tolerance with `math.isclose`. Most of the time the gap is a few ulps and irrelevant; when it is not, the data has told you it needs `math.fsum` — or that it should never have been in floats at all.