Re:Comparing Floating-Point Numbers Is Tricky
by jepler on Thursday March 30, 2017 @07:59PM
(#14000059)
Yes, though I'm specifically talking about when you decide to define a 'bool less_than(double, double)' that uses some kind of fuzzy comparison approach internally. This can affect any platform, not just one with the "bug #323" behavior in it.
Re:Comparing Floating-Point Numbers Is Tricky
by Negitivefrags on Thursday March 30, 2017 @08:50PM
(#14000382)
You don't need (and shouldn't do) any kind of fuzzy comparison for less than for floats.
Re:Comparing Floating-Point Numbers Is Tricky
by jepler on Thursday March 30, 2017 @09:38PM
(#14000582)
You sure might imagine you need to. For instance, suppose you want to average pieces of data that are timestamped "almost the same", but could arrive to be processed with varying delays, including out of order arrival (so you can't just say "is this datum at 'about the same time as' the datum received just prior"). There are better approaches, but the one I inherited involved using a std::map which used a fuzzy less than as the ordering predicate; and my main task was to diagnose why, once in a blue moon, a segmentation fault could occur when doing some operation on the map (insertion, I think).
Re:Comparing Floating-Point Numbers Is Tricky
by enqk on Thursday March 30, 2017 @10:37PM
(#14000820)
It seems more logical to pre-quantise the timestamps before insertion. (Actual solution I've seen practiced)
Re:Comparing Floating-Point Numbers Is Tricky
by tgjsrkghruksd on Friday March 31, 2017 @02:02AM
(#14001476)
As bug #323 points out, truncating floats is an incomplete solution and brings its own problems. The GNU people were not simply being lazy or ignorant, their approach was valid.
The "bug" is x87 design, period. And x87 is the past. It's old, and bad. SSE and IEEE 754 is the present.
When the float is first inserted into the set/map it has 80 bit precision, but that gets truncated to float or double precision during the store. This breaks the ordering as you are saying, but it's not an inherent flaw with floats as such.
The problem goes away if you compile with -mfpmath=sse because then the math will be performed in the same precision as the storage format.
Bug #323 is responsible for a huge amount of mistrust of floats that they don't deserve. Other compilers don't have this problem because they truncate the floats before any comparison.