# Why is 0.3 - 0.2 - 0.1 not equal to zero?

190 views (last 30 days)

Show older comments

Why does

0.3 - 0.2 - 0.1 == 0

or

v = 0:0.1:1;

any(v == 0.3)

(or similar numbers) reply false?

### Accepted Answer

Jan
on 26 Dec 2012

Edited: Jan
on 26 Dec 2012

##### 5 Comments

John D'Errico
on 30 Aug 2021

Walter Roberson
on 30 Aug 2021

128 bit representation that did not change the range, the error would be about 6e-36, but not 0.

### More Answers (2)

John D'Errico
on 30 Aug 2021

Edited: John D'Errico
on 30 Aug 2021

Let me add my take on the problem.

Suppose we try to represent these numbers in a binary form? That is, represent 1/10 = 0.1 in decimal, but as a binary number? We must do that because all floating point numbers are stored in binary form. Even if decimal storage was used, we would still have problems. For example, does 2/3 - 1/3 == 1/3? Surely that must be true in decimal arithmetic?

Suppose we weree working in 10 digits of precision in a decimal arithmetic storage form. What would 1/3 look like?

X = 0.3333333333

Y = 0.6666666667

I've rounded both values to their closest approximation I can find in a decimal form, with only 10 digits after the point. Now Y-X will be:

Y - X = 0.6666666667 - 0.3333333333 = 0.3333333334

And that is not the same value as X. But you say, I should have used Y = 0.6666666666 instead, rounding down. Then we would have Y-X=X.

But then we must also have X+Y = 3/3 = 1. And if we had rounded Y down to make the last result work, then we would see:

X = Y = 0.3333333333 + 0.6666666666 = 0.9999999999

So there will always be some contradiction, as long as we are forced to use a finite decimal storage for numbers that have no finite representation in that base.

The same applies to any binary storage form. This is how doubles and singles are stored in MATLAB. A double uses 52 binary bits to store the number. MATLAB comes as close as it can, but only 52 bits represent the mantissa.

So what would the number 1/10 look like in binary? If we think of the binary bits like this:

0.00011001100110011001100110011001100110011001100110011...

That is...

1/10 = 2^-4 + 2^-5 + 2^-8 + 2^-9 + 2^-12 + 2^-13 + 2^-16 + 2^-17 + ...

TRY IT!

format long g

2^-4 + 2^-5 + 2^-8 + 2^-9 + 2^-12 + 2^-13 + 2^-16 + 2^-17

I had to stop somewhere. If I add in a few more terms, we will come closer. In fact, the binary expansion that MATLAB uses for the number 1/10 is:

approx = sum(2.^[-4 -5 -8 -9 -12 -13 -16 -17 -20 -21 -24 -25 -28 -29 -32 -33 -36 -37 -40 -41 -44 -45 -48 -49 -52 -53 -55])

Which looks like 0.1 as displayed by MATLAB but is it? Is it EXACTLY 0.1?

sprintf('%0.55f',approx)

sprintf('%0.55f',1/10)

As you can see, both values are now seen to be the same. But neither is exaclty 0.1, only the closest approximation MATLAB could find for that number.

Similarly, we could try to approximate 0.2 and 0.3 as binary numbers, but again, we will fail as long as we are forced to use a finite number of binary bits in the approximation. And as we saw with the decimal examples before, we will always fail some of the time. Sometimes, things work. For example, try these two examples:

0.2 - 0.1 == 0.1

0.3 - 0.2 == 0.1

So one of those trivial mathematical identities seems to work, but the other fails. Again, the problem is, MATLAB can use only a finite number of bits to represent any number. And when those numbers are not representable exactly in a finite number of bits, we will aways SOMETIMES see a contradiction to what we expect must be true.

This does not happen all of the time. For example, what is the representation of the number 1/8 == 0.125 in MATLAB?

sprintf('%0.55f',1/8)

So MATLAB gets that EXACTLY correct. The trick is, 1/8 is just a power of 2 itself. So it is exactly representable in a binary form. And that means we will see this ALWAYS work in MATLAB:

1/2 - 1/8 == 3/8

Simple positive or negative powers of 2 (and integer multiples of them) will be correctly represented, as long as a finite number of bits are sufficient to do the job. But 0.1, 0.2, and 0.3? While they are finitely representable as decimals, that is not the case in binary. And THAT is my take on why 0.3-0.2-0.1 is not equal to zero in MATLAB.

##### 0 Comments

Walter Roberson
on 29 Jun 2022

Edited: Walter Roberson
on 9 Aug 2023

Consider any finite-length positional notation with a fixed base, B. For example, base 10 and 0.193 meaning 1 * 10^-1 + 9 * 10^-2 + 3 * 10^-3 -- or to put it another way, (1*10^2 + 9*10^1 + 3*10^0)/10^3 . 193 / 10^3 .

Consider a number between 0 and 1. Hypothesize that we can express it as a rational fraction, an integer N divided by M digits of the base, N / B^M . Now let the number be 1 divided by a number that is relatively prime to B, N/B^M = 1/P, with N an integer 0 to (B^M - 1) . For example, 3 is relatively prime to 10, so N/10^M = 1/'3 would be an example.

Now, cross multiply the denominator to get N = B^M / P . But our hypothesis is that B and P are relatively prime, so we know that B^M cannot be divided exactly by P.

Therefore, for any finite length M for fixed integer base B, there exist numbers (rational numbers even!) that cannot be exactly represented in the base. In the previous example, 1/3 cannot be exactly represented in any fixed length number of decimal digits; neither can 1/7 or 1/11 or 1/13 ...

Now, let the base be 2, and the relative prime be 10. N = 2^M/10 cannot work out, for any finite number of digits. Except for 2^(-infinity) there is no power of 2 that is exactly divisible by 10.

And therefore, there is no possible finite base-2 positional representation of 1/10 (or 1/100 or 1/1000). And so as long as you are using finite binary representation, 0.001 (base 10) can never exactly equal 1/1000 . So when you multiply 0.001 represented in finite positional binary by 350, you are never going to get exactly 350/1000 .

The question then becomes whether the value that you do get for 350*0.001 is the same approximation as you get for writing 0.350 . And the answer for that happens to be NO. And if it were the same, that would be by chance, and there would be different numbers that failed to work out.

Given any particular rounding system, even given any fixed number of extra "guard" digits for multiplication, you can show that as long as you are using a finite positional integer base system, that there will be cases like this, where the rounded representations will not be equal after a multiplication.

I am emphasizing that this is not a MATLAB bug: this is an inherent problem for every finite positional integer-base number system.

You could reduce problems if you immediately switch everything to indefinite-precision rational numbers and carry out the calculations as rationals, but (A) this would require growing amounts of memory as you went through the calculations; and (B) it would not completely solve the problems anyhow. (For example, if the user wrote 0.3333333333 then were they "intending" to write the rational 1/3, or were they "intending" to write the rational 3333333333/10000000000 ?)

MATLAB chose finite binary representation because that is what your computer hardware uses.

##### 0 Comments

### See Also

### Categories

### Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!