The Scientific Calculator

Why 0.1 + 0.2 Is 0.30000000000000004

Why binary floating point makes 0.1 plus 0.2 come out as 0.30000000000000004, and how this calculator rounds it back to a clean 0.3.

floating pointbinaryprecision

· Akash Pandey

Type 0.1 + 0.2 into nearly any calculator that works in binary floating point and the raw answer is 0.30000000000000004, not 0.3. This calculator produces the same value internally, then rounds it for display, so you see 0.3. The culprit is a mismatch in bases: humans write numbers in base 10, computers store them in base 2, and 0.1 does not exist exactly in base 2.

Key Takeaways

  • 0.1 + 0.2 is 0.30000000000000004 in binary floating point, in every language.
  • 0.1 in binary is a repeating pattern, 0.0001100110011….
  • This calculator rounds results to 12 significant digits, so it shows 0.3, not the raw double.
  • The stored value of 0.1 comes out to 0.10000000000000000555111512312578….

Where the extra digits come from

You already know that some fractions do not fit cleanly in base 10. One third is 0.333…, repeating forever, because 3 is not a factor of 10. Computers store numbers in base 2, where the only clean fractions have powers of two in the denominator: halves, quarters, eighths. One tenth is not in that list. In binary, 0.1 is 0.0001100110011…, repeating forever, exactly the way one third repeats in decimal.

A double-precision number has 53 bits for the digits, so the infinite binary expansion gets cut short. The value stored when you type 0.1 is 0.1000000000000000055511151231257827021181583404541015625. It is close to 0.1 but not equal to it. Add two of those slightly off values and the errors do not cancel; they stack, and the sum lands one step past 0.3. Hence 0.30000000000000004. This is the IEEE 754 standard, implemented by essentially every processor and language, so the same answer appears in JavaScript, Python, C, and Excel.

What this calculator does about it

The operating contract on this site is spelled out in the floating point arithmetic guide: every result is rounded to 12 significant digits before it is shown. A double carries about 15 to 17 reliable digits, so rounding at 12 keeps every digit that can be trusted and drops the last few, which is exactly where the accumulated noise lives.

Worked example 1: type it in. On the main calculator, type 0.1+0.2. The display returns 0.3. The underlying double is 0.30000000000000004, but the display rule hides it. Pull the same trick in the other direction with 0.3-0.2: the raw result is 0.09999999999999998, and the display shows 0.1. Multiplication does it too: 1.1*3 holds 3.3000000000000003 and displays 3.3.

When the answer genuinely cannot be pinned down, the calculator does not pretend. Type 1/3 and it shows 0.333333333333, twelve threes and then it stops. The significant figures guide explains exactly how that rounding and those display limits work.

When the difference matters

For daily arithmetic, homework, and engineering estimates, 12 reliable digits is far more precision than any measurement justifies. It matters in three narrower situations, all described in the floating point arithmetic guide:

  • Money. Do not store currency as a floating-point number. Pence and cents as whole integers are the safe route, and running totals of tiny errors are a known class of accounting bug.
  • Equality checks in code. Testing whether two computed floats are equal is unreliable; compare with a small tolerance instead.
  • Long chains of operations. Errors accumulate, and subtracting two nearly equal numbers loses the most precision.

Worked example 2: exact fractions. When you need an exactly correct fraction, the fraction calculator keeps numerators and denominators as whole numbers and never rounds. Type 1/3 + 1/3 + 1/3 there and it returns exactly 1. Do the same sum with the displayed decimals, 0.333333333333 + 0.333333333333 + 0.333333333333, and the result is 0.999999999999. Same idea, different worlds.

Worked example 3: roots and squares. sqrt(2)^2 is a classic tripwire. Logically, the square root of 2 squared is 2. On the calculator the raw result is 2.0000000000000004, rounded for display to 2. When you need the exact value, keep the root form and evaluate once at the end, which the calculator function reference discusses under the √ key.

There is also an integer boundary worth knowing. Below 2^53 − 1 = 9,007,199,254,740,991, every whole number is representable exactly and the calculator prints all its digits. Above that line, values like 19! switch to scientific notation rather than claiming precision that does not exist.

Frequently asked questions

Is 0.1 plus 0.2 really 0.3 or not?

In exact decimal arithmetic it is. In binary floating point, the stored result is 0.30000000000000004. This calculator returns that same value internally and rounds to 12 significant digits for display, so you see 0.3.

Is this a bug in the calculator?

No. It is the IEEE 754 standard that every mainstream processor and language implements. Programs and calculators that appear to avoid the problem are hiding it with display rounding, exactly as this one does.

How can I get an exact answer?

Use the fraction calculator for rational arithmetic, which never rounds, or keep symbolic forms like sqrt(2) and pi in the expression until the final step.

Why does 1 divided by 3 show only twelve threes?

Because one third has no exact representation in either base. The calculator shows twelve reliable digits and stops rather than pretending the value terminates.