alt Hacker NewsPlease look at the link where context is clear here. Floating point has limited precision and the complete inability to exactly represent some numbers.
Example, this equality check is false:
0.1 + 0.2 == 0.3
Because the last bits of a floating point number, after any practical chain of operations, is practically random, do to errors from limited precision. Yes you can always know what the result will exactly be for any operation, if you know the exact number and operations used. Good luck with something like sin/cos though, where implementations can vary wildly depending on the platform/library.
Your problem only occurs when you try to naively transport equality of real numbers into equality of floating point numbers.
https://www.netlib.org/fp/dtoa.c is how eg CPython parses literals like 0.3 into floating point numbers and how it converts floating point numbers back to strings. Lo and behold: these algorithm compare floating point numbers for equality, and would break catastrophically, if the compiler were allowed to willy-nilly fiddle with the bit patterns.
The authors of these algorithm did care about floating point equality, and that is not a mistake. (However it would be a mistake to assume that equality of mathematical real numbers translates to equality of floating point numbers.)
> Yes you can always know what the result will exactly be for any operation, if you know the exact number and operations used.
Yes, and for some algorithms like illustrated above this is exactly what people do, and have to do.
And the lower bits of 0.1 + 0.2 ain't random: they are the same on your computer as on mine, whether we run the code in 1999 or in 2029.
https://news.ycombinator.com/item?id=47767398 has a discussion.