fractions.Fraction vs float: Localhost Lab

Intro — what this post promises

Exact rational math with fractions.Fraction vs float (and a Decimal reference arm). This lab reports ops/s on Linux localhost, plus exactness checks for ratios that cancel in theory and diverge in binary float.

Related links:

• statistics quantiles vs manual 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
• path glob vs fnmatch localhost lab
• itertools batched vs chunk localhost lab
• exitstack vs nested with localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5 on this Linux box. Affiliates: 0. Differentiates from Decimal-vs-float sum (lab 85) — focus here is Fraction rationals and exact canceling products, not money decimals.

Verdict up front: float sum 0.1×50 k ~119415247 ops/s; Decimal ~20714012; Fraction ~2420034. Ratio product ∏ i/(i+1): float ~30498219 ops/s vs Fraction ~1311467 — Fraction stays exact (1/5001).

Arms

Each arm measures wall time with time.perf_counter over seven rounds and reports p50 ops/s so one noisy sample cannot dominate the lead table.

Lab topology

n_sum=50000 · ratio_n=5000 · 7 rounds · p50
metric: ops/s = element_ops / p50_s

Script: lab-evidence/122-fractions-vs-float/results/run_lab.py. Same machine, same interpreter — no invented timings.

Lead table (p50 ops/s)

Float leads throughput. Fraction pays for arbitrary-precision gcd work on every multiply/add.

Exactness

• Ratio product: Fraction 1/5001; float 0.00019996000799840023 (last bits ≠ float(Fraction) = 0.0001999600079984003).
• Prefer Fraction(1, 10) or Fraction("0.1") — not Fraction(0.1), which freezes binary residue into a huge numerator/denominator.

On this run, sum([0.1]*50000) may print as a tidy 5000.0. That cosmetic print does not make float a rational type; the canceling product still drifts from exact 1/5001.

Construction checklist

Reading it for SRE work

• Billing rates, mix ratios, probability fractions that must cancel cleanly → Fraction.
• Hot path averages and gauges → float, accept binary error and document it.
• Never build Fraction from a polluted float and expect exact decimal tenths.
• Lab 85 already covered Decimal sums; this post is rational exactness under load.

If you only need “close enough” for dashboards, float’s ~119415247 ops/s is the right tool. If auditors ask for exact 1/5001, Fraction’s slower path is the one that answers without hand-waving.

Pitfalls

• Fraction(0.1) capturing binary float residue.
• Unbounded Fraction growth in long products without limit_denominator.
• Using Fraction in a numpy/GPU path by accident.
• Comparing speed alone without stating exactness goals.
• Treating a pretty printed float total as proof of exactness.

Reproduce

python3 lab-evidence/122-fractions-vs-float/results/run_lab.py

Evidence: summary.json, summary.txt under lab-evidence/122-fractions-vs-float/results/.

Limits

One Linux box, CPython 3.13.5, pure-Python Fraction. Not mpmath, not GPU reductions, not multi-process.

Takeaway

Float wins throughput (~119415247 ops/s on the 0.1 sum); Fraction is slower (~2420034) but keeps exact rationals like 1/5001. Use Fraction when exact ratios matter; use float when speed dominates and binary error is acceptable.