Fundamentals 9 min read

Why 0.1+0.1 Equals 0.2 but 0.1+0.2 Doesn’t Equal 0.3: The IEEE‑754 Float Mystery Explained

This article demystifies why adding two approximated 0.1 values yields an exact 0.2 in floating‑point arithmetic while adding 0.1 and 0.2 fails to produce an exact 0.3, by detailing IEEE‑754 double‑precision storage, binary conversion, rounding effects, and Java code verification.

ITPUB
ITPUB
ITPUB
Why 0.1+0.1 Equals 0.2 but 0.1+0.2 Doesn’t Equal 0.3: The IEEE‑754 Float Mystery Explained

During a technical interview, a candidate is asked why 0.1+0.1 equals 0.2 but 0.1+0.2 does not equal 0.3. The answer lies in how IEEE‑754 double‑precision floating‑point numbers store decimal fractions.

1. How computers store 0.1 (IEEE‑754 double‑precision)

Decimal fractions are first converted to binary fractions, then stored in 64 bits divided into three fields:

Sign bit (1 bit) : 0 for positive numbers.

Exponent (11 bits) : stored with a bias of 1023. For 0.1 the true exponent is –4, so the stored exponent is 1023‑4 = 1019 (binary 01111111011).

Mantissa (52 bits) : the fractional part after normalising the binary number to the form 1.xxxxx × 2^e. The leading 1. is implicit and not stored; only the following bits are kept, rounded to 52 bits.

Because 0.1 in binary is an infinite repeating fraction 0.0001100110011…₂, the mantissa stores a rounded approximation.

2. Why 0.1 + 0.1 = 0.2 appears exact

Both 0.1 values are stored as the same approximated binary pattern. Adding them yields the binary pattern of 0.2, whose own approximation matches exactly after rounding. Hence the stored result of 0.1+0.1 is identical to the stored representation of 0.2.

// Java prints the actual stored values (not the mathematical ones)
System.out.println(new BigDecimal(0.1));
// 0.1000000000000000055511151231257827021181583404541015625
System.out.println(new BigDecimal(0.1).add(new BigDecimal(0.1)));
// 0.200000000000000011102230246251565404236316680908203125
System.out.println(new BigDecimal(0.2));
// 0.200000000000000011102230246251565404236316680908203125

3. Why 0.1 + 0.2 ≠ 0.3

When the approximated binary of 0.1 is added to that of 0.2, the resulting mantissa cannot be represented exactly within 52 bits. The rounding error does not cancel, so the stored result differs from the stored representation of 0.3.

// Java prints the actual stored values
System.out.println(new BigDecimal(0.1).add(new BigDecimal(0.2)));
// 0.3000000000000000444089209850062616169452667236328125
System.out.println(new BigDecimal(0.3));
// 0.299999999999999988897769753748434595763683319091796875

4. Interview answer template (three steps)

Core reason : IEEE‑754 stores decimal fractions as rounded binary approximations.

Case breakdown :

0.1 + 0.1 = 0.2 – rounding errors cancel, so the stored result matches 0.2.

0.1 + 0.2 ≠ 0.3 – rounding errors accumulate, producing a value different from the stored 0.3.

Practical mitigation : For exact arithmetic (e.g., monetary calculations) avoid double/float and use BigDecimal (constructed from String) or integer arithmetic (e.g., cents).

Understanding the “infinite binary → mantissa rounding → approximate addition” chain demonstrates deep knowledge beyond memorising that “0.1 cannot be represented exactly”.

JavainterviewBigDecimalfloating-pointIEEE-754
ITPUB
Written by

ITPUB

Official ITPUB account sharing technical insights, community news, and exciting events.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.