Type 0.1 + 0.2 into the calculator above and press equals. The answer displayed is 0.3 — because the tool rounds its output to ten decimal places before showing it. But the raw arithmetic underneath returns 0.30000000000000004. That tiny fragment did not appear from nowhere; it is the visible surface of a deeper phenomenon: every floating-point operation leaves a rounding residue, and when you chain enough operations together, those residues can accumulate into an error that matters.
Why computers cannot store 0.1 exactly
Computers store numbers in binary — a system of ones and zeros. Just as the fraction 1/3 cannot be written exactly in decimal (it becomes 0.3333… forever), the number 0.1 cannot be written exactly in binary. The closest the computer can get in the 64-bit double-precision format used by JavaScript — and therefore by every browser-based calculator — is approximately 0.1000000000000000055511151231257827021181583404541015625.
This representation is governed by the IEEE 754 standard, which defines how all modern processors handle decimal numbers. The standard guarantees that each arithmetic operation returns the closest representable result — but "closest" is not "exact." That gap, however small, is a rounding error by definition.
How errors grow through a chain
A single rounding error of 5 × 10⁻¹⁷ is imperceptible. The concern is what happens when you use that slightly-off result as the input to the next operation, and that result feeds the one after, and so on. As the Wikipedia article on round-off error describes it: "When a sequence of calculations with an input involving any roundoff error are made, errors may accumulate, sometimes dominating the calculation."
Two mechanisms drive the growth:
- Additive drift — in a long summation (adding up many small values), each addition may round in the same direction. The individual errors do not cancel; they pile up. Adding a thousand numbers that each carry an error of
10⁻¹⁵can produce a final error around10⁻¹²— still tiny in absolute terms, but a million times larger than the per-step error. - Subtractive cancellation — subtracting two nearly equal numbers can amplify relative error sharply. If both values are imprecise at the 15th decimal place and the first 14 digits cancel out, the error now dominates what is left. Calculators use this in trigonometric identities and other near-cancellation cases, which is why their trig functions are implemented with special care.
A concrete example from repeated rounding
Rounding a number at each step rather than at the end produces a compound error that is larger than a single round. Round 9.945309 to two decimal places and you get 9.95 (error: 0.0047). Round that to one decimal place and you get 10.0 (total error: 0.055). Rounding all the way in a single step — 9.945309 to one decimal — gives 9.9, with a total error of only 0.045. The two-step path introduced extra error because the first round pushed the value past the next threshold.
This is why a calculation that shows an intermediate result — for example, copying a rounded value from one calculation into the next — can produce a slightly different final answer than keeping all the precision in one unbroken expression.
What the calculator does to manage this
The calculator above applies a final rounding step after evaluating each expression: the raw floating-point result is rounded to ten decimal places before display. The internal code uses Math.round(result * 1e10) / 1e10, which cleans away the floating-point residue for most everyday calculations. That is why 0.1 + 0.2 shows as 0.3 rather than the raw 0.30000000000000004.
This is a pragmatic choice: it eliminates distracting noise at the end of most results. It also means the calculator will not display errors much smaller than 10⁻¹⁰, regardless of how they arose. For the vast majority of practical calculations — homework, budgets, engineering estimates — ten significant decimal places is more precision than the problem requires, so this rounding is a feature, not a compromise.
When accumulated error actually matters
For everyday use, accumulated rounding error is rarely a problem. It becomes relevant in these situations:
- Very long summations — adding hundreds of financial figures or measurement readings manually, step by step, rather than in one expression.
- Iterative formulas — calculations where an output feeds back in as the next input for many cycles, such as compound interest over hundreds of periods.
- Near-cancellation — subtracting two quantities that are almost equal, which can expose the rounding residue that normally hides far to the right.
- Intermediate rounding by hand — copying a rounded intermediate result into the next step instead of keeping it in the same expression.
The practical mitigation is straightforward: enter the whole formula in one expression when you can, avoid rounding intermediate values by hand, and treat a result with many decimal places as an approximation rather than an exact answer if any of your input values were themselves approximate.
Check yourself: type0.1 + 0.2into the calculator above — you will see0.3. The display is cleaned, but the underlying arithmetic is not exact. For a long chain of steps, keep the full expression on one line whenever possible: the calculator handles the accumulated rounding internally, rather than you introducing extra drift by copying rounded intermediates by hand.