Re: [Haskell-cafe] Re: (flawed?) benchmark : sort

Speaking as someone who often has to answer questions along the lines of "why isn't my code generating the results I want on your system?", I wouldn't call it evil, just "commonly mistaken for Real". NaN breaks most assumptions about ordering: (NaN <= _) == false (NaN == _) == false (NaN >= _) == false It doesn't even compare equal to a bitwise copy of itself. This would imply that it's impossible to write a stable sort for (IEEE) floating-point types. x < (x+n) (and variations thereof) does not always hold either. - Derek Brandon S. Allbery KF8NH wrote:

On Mar 11, 2008, at 0:20 , Chaddaï Fouché wrote:

...

2008/3/11, David Menendez :

...

I think Adrian is just arguing that a == b should imply f a == f b, for all definable f, in which case it doesn't *matter* which of two equal elements you choose, because there's no semantic difference.

I completely agree that this propriety should be true for all Eq instance exported by a public module. I don't care if it is not the case in a isolated code, but libraries shouldn't break expected invariant (or at least be very cautious and warn the user). Even Eq Double respects this propriety as far as I know.

I wouldn't want to bet on that (Eq Double, that is). Floating point's just *evil*.