4 ms·

Please look at the link where context is clear here. Floating point has limited precision and the complete inability to exactly represent some numbers. Example

by nomel 2mo ago

Please 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.

eru 2mo ago
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 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 https://news.ycombinator.com/item?id=47767398 has a discussion.
- nomel 2mo ago
  > Your problem only occurs when you try to naively transport equality of real numbers into equality of floating point numbers. This is not a naivety problem, it's as I said, that floating point numbers cannot represent some numbers. In practical use, we see this as a precision problem, thus requiring tolerances. Yes, that discussion is precisely what I'm talking about. That tolerance is required because the bits below the tolerance are not stable. They will practically be, after some practical operations, random which is why you need to ignore them. As I said, yes you will know what those meaningless lower bits will be, at any point in time, if you know the algs, which is why I said "considered to be" and "practical". And yes, old code will produce the same numbers as new code, if the same hardware/libraries/implementations are used. But, since even the order of operation will change the lower bits, due to precision limits. This will usually NOT be true across libraries. If you're using hardware sin/cos, then it will not be true even if the same library is used, since different platforms can use different implementations/approximations of hardware sin/cos. This is all fine, because if you're actually doing this type of work, the fact that floating point numbers have limited precision, therefore requiring a tolerance for comparison, is well understood (see your discussion link). Cheers!

by nomel 2mo ago

eru 2mo ago

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 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 https://news.ycombinator.com/item?id=47767398 has a discussion.

nomel 2mo ago
> Your problem only occurs when you try to naively transport equality of real numbers into equality of floating point numbers. This is not a naivety problem, it's as I said, that floating point numbers cannot represent some numbers. In practical use, we see this as a precision problem, thus requiring tolerances. Yes, that discussion is precisely what I'm talking about. That tolerance is required because the bits below the tolerance are not stable. They will practically be, after some practical operations, random which is why you need to ignore them. As I said, yes you will know what those meaningless lower bits will be, at any point in time, if you know the algs, which is why I said "considered to be" and "practical". And yes, old code will produce the same numbers as new code, if the same hardware/libraries/implementations are used. But, since even the order of operation will change the lower bits, due to precision limits. This will usually NOT be true across libraries. If you're using hardware sin/cos, then it will not be true even if the same library is used, since different platforms can use different implementations/approximations of hardware sin/cos. This is all fine, because if you're actually doing this type of work, the fact that floating point numbers have limited precision, therefore requiring a tolerance for comparison, is well understood (see your discussion link). Cheers!