math.fsum vs sum Float Totals: Localhost Lab

Intro — what this post promises

Total floats with math.fsum vs builtin sum vs a naive += loop. This lab reports items/s on Linux localhost, plus a cancellation accuracy case that still bites on Python 3.13.

Related links:

• fractions vs float localhost lab
• statistics quantiles vs manual localhost lab
• decimal vs float sum localhost lab
• random choices vs sample localhost lab
• graphlib topo vs manual localhost lab
• functools cache vs lru localhost lab
• tomllib vs json localhost lab
• itertools batched vs chunk localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. Not Decimal (lab 85) and not Fraction (lab 122) — this is IEEE float summation only.

Verdict up front (n=100 000 uniform): sum ~205.04 Mitems/s; math.fsum ~188.64; naive loop ~84.48. Mixed magnitudes: sum ~206.94 vs fsum ~46.51. Accuracy: sum([1, 1e100, 1, -1e100]) → 0.0; math.fsum(...) → 2.0.

Arms

Seven rounds, p50 items/s. Uniform draws keep magnitudes similar; mixed-exponent draws force larger intermediate cancellations.

Lab topology

n in {10k, 100k, 1M} · uniform + mixed · 7 rounds · p50
metric: items/s = n / p50_s

Script: lab-evidence/123-math-fsum-vs-sum/results/run_lab.py.

Lead table — n=100 000 (p50 Mitems/s)

On uniform data, sum and fsum are close; the naive loop loses badly to interpreter overhead.

Scale (uniform)

Throughput stays in the same ballpark as n grows — both paths are C-backed; the story is accuracy under cancellation, not asymptotic surprise.

Cancellation footgun

For [1, 1e100, 1, -1e100]: sum → 0.0, fsum → 2.0. Prefer math.fsum when large partials can cancel. Keep the classic mixed int/float literals in regression tests — all-float versions can take a different sum path on 3.13 and hide the bug.

Mixed-magnitude cost

On mixed exponents, fsum slowed to ~46.51 Mitems/s vs sum ~206.94 — precision work is not free. That is the trade: pay for shepherds of partials when correctness matters more than peak items/s.

Reading it for SRE work

• Hot path, similar magnitudes → sum.
• Large dynamic range / cancellation risk (log totals, compensated sensors) → math.fsum.
• Never hand-roll += for speed — it lost to both C paths.
• Exact decimals still want Decimal (lab 85) or Fraction (lab 122).

Document which reducer you pick in runbooks so on-call does not “optimize” away a deliberate fsum later.

Pitfalls

• Assuming sum and fsum always agree.
• Using fsum then wiping precision in display formats.
• Confusing with lab 85 Decimal arithmetic.
• Testing only all-float literals for cancellation demos on 3.13.
• Replacing fsum with sum in a hot path without an accuracy fixture.

Reproduce

python3 lab-evidence/123-math-fsum-vs-sum/results/run_lab.py

Evidence: summary.json, summary.txt under lab-evidence/123-math-fsum-vs-sum/results/.

Limits

One Linux box. CPython float summation only. Not GPU reductions, not multiprecision.

Takeaway

At 100 k uniforms, sum ~205.04 Mitems/s edged fsum ~188.64. Use math.fsum when cancellation matters — classic case: sum 0.0 vs fsum 2.0.