This question already has an answer here:
- Floating Point Limitations 3 answers
I spent an hour today trying to figure out why
return abs(val-desired) <= 0.1
was occasionally returning False
, despite val
and desired
having an absolute difference of <=0.1
. After some debugging, I found out that -13.2 + 13.3 = 0.10000000000000142
. Now I understand that CPUs cannot easily represent most real numbers, but this is an exception, because you can subtract 0.00000000000000142
and get 0.1
, so it can be represented in Python.
I am running Python 2.7 on Intel Core architecture CPUs (this is all I have been able to test it on). I'm curious to know how I can store a value of 0.1
despite not being able to apply arithmetic to particular floating point values. val
and desired
are float
values.
Yes, this can be a bit surprising:
All these numbers can be represented with some 16 digits of accuracy. So why:
Why only 14 digits of accuracy in that case?
Well, that's because 13.3 and -13.2 have 16 digits of accuracy, which means 14 decimal points, since there are two digits before the decimal point. So the result also have 14 decimal points of accuracy. Even though the computer can represent numbers with 16 digits.
If we make the numbers bigger, the accuracy of the result decreases further:
In short, the accuracy of the result depends on the accuracy of the input.
To directly address your question of "how do I store a value like 0.1 and do an exact comparison to it when I have imprecise floating-point numbers," the answer is to use a different type to represent your numbers. Python has a decimal module for doing decimal fixed-point and floating-point math instead of binary -- in decimal, obviously, 0.1, -13.2, and 13.3 can all be represented exactly instead of approximately; or you can set a specific level of precision when doing calculations using decimal and discard digits below that level of significance.
The other common alternative is to use integers instead of floats by artificially multiplying by some power of ten.
"Now I understand that CPUs cannot easily represent most floating point numbers with high resolution", the fact you asked this question indicates that you don't understand. None of the real values 13.2, 13.3 nor 0.1 can be represented exactly as floating point numbers: