[Negitivefrags]

This is actually caused by the use of the x87 80 bit floating point registers. (Infamous GCC bug #323)

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.

[jepler]

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.

[Negitivefrags]

You don't need (and shouldn't do) any kind of fuzzy comparison for less than for floats.

[jepler]

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

[enqk]

It seems more logical to pre-quantise the timestamps before insertion. (Actual solution I've seen practiced)

[tgjsrkghruksd]

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.