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

[Derek Gladding]

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 <dave at zednenem.com>:
>>> 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*.
>