Decimal vs float Sum: Localhost Lab

Intro — what this post promises

Should a hot cumulative sum use float or decimal.Decimal? This lab reports ops/s for summing many 0.1-style addends on Linux localhost, plus a simple accuracy note (exact Decimal vs binary float drift). Not financial, tax, or accounting advice.

Related links:

• 01shoppercove.comstatistics vs manual mean localhost lab
• 02shoppercove.comjson dumps compact vs indent localhost lab
• 03shoppercove.compickle vs json roundtrip localhost lab
• 04shoppercove.comthreading local vs dict localhost lab
• 05shoppercove.comasyncio gather vs taskgroup localhost lab
• 06shoppercove.comhashlib md5 vs blake2b localhost lab
• 07shoppercove.comcsv reader vs split localhost lab
• 08shoppercove.comcounter vs dict tally localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5, decimal precision 28. Affiliates: 0. No Docker. Values built from Decimal("0.1") / float 0.1.

Verdict up front (n=1 000 000 loop): float ~43.01 Mops/s vs Decimal ~17.18 Mops/s (~2.5×). Float loop sum of 0.1 drifted by ~1.333e-06 from exact 100000; Decimal matched exact. Builtin sum(float) ~110.42 Mops/s and printed exact 100000.0 here (compensated summation) — still not a substitute for decimal money types.

Arms

Lab topology

n in {10_000, 100_000, 1_000_000} · 7 rounds · p50
metric: ops/s = n / p50_s
accuracy vs Decimal exact (0.1 × n)

Script: lab-evidence/85-decimal-vs-float-sum/results/run_lab.py.

Lead table — n=1 000 000 (p50)

Speed across n

Accuracy note (not advice)

0.1 is not exact in binary float, so a naive loop accumulates visible error as n grows (~1.6e-10 → ~1.3e-6 here). Decimal("0.1") summed exactly at this precision. Python’s builtin sum() on floats used a more accurate algorithm on this run and printed the clean integer-valued total — great for analytics, still not a decimal money type.

Reading it

• Float wins speed (~2.5× on the 1 M loop); Decimal wins exact base-10 addends.
• Use float for scientific/telemetry sums where relative error is acceptable.
• Use Decimal (or integer cents) when base-10 exactness matters more than Mops/s.
• Do not treat this as ledger/tax guidance — pick types with your domain rules and tests.

float sum() vs float loop

On 3.13, sum(list_of_floats) was both faster (~110.42 vs ~43.01 Mops/s) and more accurate for this 0.1×n case than a handwritten loop. Prefer sum/math.fsum over naive loops when you stay in binary float — and still switch to Decimal/integers when exact decimal fractions are a requirement.

Integer cents alternative

For currency-like totals, many teams store integer minor units (cents) and only format on output — fast like int add, exact like Decimal for two-place money. This lab did not bench int cents; it is the usual escape hatch when Decimal Mops/s hurt and float error is unacceptable.

Pitfalls

• Constructing Decimal(0.1) from a float (imports binary error) — use Decimal("0.1").
• Comparing stringified floats to Decimals carelessly.
• Assuming “sum() was exact once” means money is safe in float.
• Ignoring precision context (getcontext().prec) for huge Decimal workloads.

Reproduce

python3 lab-evidence/85-decimal-vs-float-sum/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box. Default Decimal precision 28. Not mpmath/numpy. Not banking standards (IEEE 754-decimal, currency rounding modes).

Takeaway

Float loop ~43.01 Mops/s vs Decimal ~17.18 Mops/s (~2.5×) at n=1 M, but the float loop was ~1.333e-06 off exact 0.1×n while Decimal matched. Speed is float; exact tenths are Decimal (or integer cents). Choose deliberately.