{"slug": "floating-point-will-quietly-corrupt-your-emissions-math-and-0-1-0-2-already-you", "title": "Floating-point will quietly corrupt your emissions math, and 0.1 + 0.2 already warned you", "summary": "This article explains how floating-point arithmetic errors, like the well-known `0.1 + 0.2` discrepancy, become critical defects in emissions accounting software. Unlike most applications where such tiny rounding errors are harmless, emissions calculations require exact reconciliation to the last digit for audit compliance, as even a 0.04 tCO2e difference constitutes an unexplained discrepancy. The author recommends using arbitrary-precision decimal arithmetic for reported figures or Kahan summation for performance-sensitive paths to eliminate these errors.", "body_md": "Every developer has seen this:\n\n```\n0.1 + 0.2\n// 0.30000000000000004\n```\n\nIt's the most-shared bug in programming. You learn it, you nod, you move on — because in most code the error is so far down the decimal that nothing notices. A pixel is off by a billionth. A timer fires a nanosecond late. Nobody files a ticket.\n\nThen you build a system whose entire job is to add thousands of numbers together and produce a total that has to match a figure someone calculated by hand. And the rounding error you waved away in the tutorial becomes a line in an audit report that says: *the system total does not reconcile to the source data.*\n\nThat's where I met this bug for real, building the calculation layer at [GreenCalculus.com](https://greencalculus.com). It runs over a thousand emissions calculators, and every one of them has the same hard requirement: the number the engine produces must reconcile, to the last reported digit, against the number a practitioner gets when they check the math themselves. \"Close enough\" is a finding. This post is the set of rules that get you from *the math looks right* to *the math reconciles*.\n\n## Why this bites harder in measurement code than anywhere else\n\nMost software treats numbers as means to an end — coordinates, counters, ratios feeding a render. The exact value rarely *is* the deliverable.\n\nIn emissions accounting, the number **is** the deliverable. A reported figure of `1,240.37 tCO2e`\n\nis the product. If an auditor recomputes it and gets `1,240.41`\n\n, the 0.04 isn't noise — it's an unexplained discrepancy, and unexplained discrepancies are exactly what an audit exists to surface. You don't get to say \"floating-point.\" You get to fix your data model.\n\nThree properties of this domain turn a harmless rounding error into a real defect:\n\n-\n**Massive summation.** A Scope 3 inventory adds tens of thousands of line items. Error accumulates with count. -\n**Wide dynamic range.** You add a 4,000,000 kg figure to a 0.002 kg figure in the same total. This is precisely the case floating-point handles worst. -\n**External reconciliation.** The output is checked against an independent calculation. There's no hiding internal drift, because someone outside your system recomputes it.\n\n## The float problem, stated precisely\n\nA 64-bit IEEE 754 float (`double`\n\n, JavaScript's only number type) stores 52 bits of mantissa — about 15–17 significant decimal digits. `0.1`\n\n, `0.2`\n\n, and `0.3`\n\nare not representable exactly in binary, the same way `1/3`\n\nisn't representable exactly in decimal. They're stored as the nearest available binary fraction, and the tiny errors survive arithmetic.\n\n```\n(0.1 + 0.2).toFixed(20)\n// \"0.30000000000000004441\"\n```\n\nFor a single operation the error is ~10⁻¹⁷. The problem is what happens when you do the operation 50,000 times, and when the operands differ in magnitude by a factor of a billion.\n\n## Failure mode 1: the total that won't reconcile\n\nNaive summation of a long list of factors:\n\n``` js\nfunction totalEmissions(lineItems) {\n  let total = 0;\n  for (const item of lineItems) {\n    total += item.activity * item.factor;   // each term carries float error\n  }\n  return total;\n}\n```\n\nEach `activity * item.factor`\n\nlands on the nearest representable double, slightly off. Each `+=`\n\nrounds again. Over tens of thousands of items the errors are *mostly* random and partly cancel — but \"mostly\" is not \"exactly,\" and the residual is deterministic for a given input order. Run the same data through a spreadsheet that sums in a different order and you get a different last digit. Now you have two \"correct\" totals that disagree, and no way to say which is right.\n\n### Fix: control precision at the boundary, not in the loop\n\nTwo defensible strategies, depending on stack.\n\n**Decimal arithmetic for the money-and-mass path.** Store and sum factors as arbitrary-precision decimals so there's no binary-representation error at all:\n\n``` python\nimport Decimal from 'decimal.js';\n\nfunction totalEmissions(lineItems) {\n  return lineItems\n    .reduce((acc, item) =>\n      acc.plus(new Decimal(item.activity).times(item.factor)),\n      new Decimal(0))\n    .toNumber();   // convert once, at the very end, after rounding regime applied\n}\n```\n\nDecimal is slower. You don't need it everywhere — you need it on the path whose output is a reported figure.\n\n**Kahan summation when you must stay in floats.** If the hot path can't afford Decimal, compensated summation recovers most of the lost low-order bits by tracking the rounding error and feeding it back in:\n\n``` js\nfunction kahanSum(values) {\n  let sum = 0;\n  let compensation = 0;        // running error term\n  for (const v of values) {\n    const y = v - compensation;\n    const t = sum + y;\n    compensation = (t - sum) - y;   // recovers what the addition just dropped\n    sum = t;\n  }\n  return sum;\n}\n```\n\nThe single addition `sum + y`\n\nloses the low bits of `y`\n\nwhen `sum`\n\nis large; the next line reconstructs exactly those bits and carries them into the following iteration. For a long sum of mixed-magnitude terms this is the difference between a stable total and one that drifts with input order.\n\n## Failure mode 2: the wide-magnitude swallow\n\nThis is the one that produces a *wrong* number, not just an unstable one.\n\n``` js\nlet total = 4_000_000.0;   // a large facility's annual figure, kg\ntotal += 0.002;            // a trace fugitive line, kg\ntotal === 4_000_000.002;   // true here — but stack enough trace lines...\n```\n\nWhen the accumulator is large and the addend is tiny, the addend's significant bits fall off the bottom of the mantissa and are silently dropped. One trace line is fine. Ten thousand of them, each individually swallowed, is a missing category total. The sum *looks* authoritative — it's a clean large number — which is exactly why nobody catches it by eye.\n\n### Fix: sum within magnitude bands, then combine\n\nAdd small things to small things before adding them to big things. Sort ascending and the smallest terms accumulate among themselves into a magnitude the large accumulator can actually absorb:\n\n``` js\nfunction bandedSum(values) {\n  const ascending = [...values].sort((a, b) => a - b);\n  return kahanSum(ascending);   // small-first ordering + compensation\n}\n```\n\nSorting ascending before a compensated sum is a cheap, robust default for \"many small, few large.\" It won't matter on uniform data — but reference-data sums are rarely uniform.\n\n## Failure mode 3: the ratio that amplifies\n\nIntensity metrics divide one computed figure by another — emissions per unit revenue, per tonne of product, per kWh. Division doesn't create error, but it *amplifies* whatever error the operands already carry, and ratios of two nearly-equal slightly-wrong numbers are the worst case.\n\n``` js\nconst intensityA = total2025 / output2025;\nconst intensityB = total2024 / output2024;\nconst yoyChange = (intensityA - intensityB) / intensityB;   // tiny - tiny, over tiny\n```\n\nWhen `intensityA`\n\nand `intensityB`\n\nare close, their difference is dominated by the rounding error in each, and dividing that noisy difference by a small base inflates it into a visible percentage. Your year-on-year intensity change can read as ±0.3% pure artefact.\n\n### Fix: defer rounding, widen the working precision\n\nCarry full precision through the entire chain and round **once**, at presentation. Never round an intermediate that feeds a later division. If the figures are reconciliation-critical, do the division in Decimal too — the cost is trivial relative to one division per report.\n\n## Failure mode 4: the unit-boundary shave\n\nEvery conversion is a multiply, and every multiply is a place to lose digits. The g → kg → t chain looks innocent:\n\n``` js\nconst grams = 1234567;\nconst kg = grams / 1000;        // 1234.567\nconst tonnes = kg / 1000;       // 1.234567\n// round-trip back up and compare:\ntonnes * 1000 * 1000 === grams; // not guaranteed\n```\n\nEach division lands on the nearest double; chaining them compounds the drift, and a value that round-trips through three units may not come back to where it started. The fix is the same architectural rule that governs the whole post: **store in one canonical unit at full precision, convert only at the display boundary.** Don't persist the converted value and re-derive from it — persist the canonical value and convert on read.\n\n## The rule underneath all four\n\nEvery one of these is the same decision made wrong: *where does precision get fixed, and how many times.* The failures all come from rounding early, rounding repeatedly, or rounding in the middle of a chain that isn't done yet.\n\nThe architecture that prevents all four:\n\n-\n**One canonical unit, full precision, in storage.** No pre-rounded, pre-converted values persisted. -\n**A declared rounding regime, applied once, at the boundary.** Half-up, half-even — pick one, document it, apply it where the number leaves the system, never before. -\n**Decimal on any path whose output is a reported figure.** Floats are fine for charts and progress bars. They are not fine for the deliverable. -\n**Compensated, magnitude-aware summation** wherever you must aggregate many terms in floating point.\n\nThis is the same shape as a rule we apply to every figure in the GreenCalculus data layer: a number is meaningless without its declared basis. There, the basis is the GWP version and the emission-factor source. Here, it's the unit and the rounding regime. In both cases the discipline is identical — *the number is not just its digits; it's its digits plus the declared rules that produced them.* Store the rules with the number, or you can't defend the number.\n\n`0.1 + 0.2`\n\nwas never the bug. It was the warning that your numbers carry rules you haven't written down yet.\n\n*The GreenCalculus calculation layer applies these rules across 1,000+ emissions calculators, every one of which has to reconcile against its source data to the last reported digit. Methodology documentation at greencalculus.com.*", "url": "https://wpnews.pro/news/floating-point-will-quietly-corrupt-your-emissions-math-and-0-1-0-2-already-you", "canonical_source": "https://dev.to/jeremiah_say/floating-point-will-quietly-corrupt-your-emissions-math-and-01-02-already-warned-you-g2", "published_at": "2026-05-23 00:04:20+00:00", "updated_at": "2026-05-23 00:32:45.797173+00:00", "lang": "en", "topics": ["developer-tools", "enterprise-software", "data", "science"], "entities": ["GreenCalculus.com"], "alternates": {"html": "https://wpnews.pro/news/floating-point-will-quietly-corrupt-your-emissions-math-and-0-1-0-2-already-you", "markdown": "https://wpnews.pro/news/floating-point-will-quietly-corrupt-your-emissions-math-and-0-1-0-2-already-you.md", "text": "https://wpnews.pro/news/floating-point-will-quietly-corrupt-your-emissions-math-and-0-1-0-2-already-you.txt", "jsonld": "https://wpnews.pro/news/floating-point-will-quietly-corrupt-your-emissions-math-and-0-1-0-2-already-you.jsonld"}}