[Haskell-cafe] Re: Why purely in haskell?

[Wolfgang Jeltsch]

Am Freitag, 11. Januar 2008 11:03 schrieb Felipe Lessa:
> Another thing for the record: Goldberg says
>
> "The introduction of NaNs can be confusing, because a NaN is never
> equal to any other number (including another NaN), so x = x is no
> longer always true. In fact, the expression x /= x is the simplest way
> to test for a NaN if the IEEE recommended function Isnan is not
> provided. Furthermore, NaNs are unordered with respect to all other
> numbers, so x <= y cannot be defined as not x > y. Since the
> introduction of NaNs causes floating-point numbers to become partially
> ordered, a compare function that returns one of <, =, >, or unordered
> can make it easier for the programmer to deal with comparisons."
>
> Goldberg, David. What Every Computer Scientist Should Know About
> Floating-Point Arithmetic.
> http://docs.sun.com/source/806-3568/ncg_goldberg.html .
>
> As GNU is not Unix, NaN is not a number, so what is standard about
> numbers doesn't work for them. I don't think there's a compeling
> reason about changing this behavior, specially because it's what's
> specified in the IEEE 754.

There is a really compelling reason: If the order on floating point numbers is 
partial then there is no meaningful Ord instance for them.

And what do Hugs and GHCi say?  Their answers are plain horror:

    Hugs, version 20050308:

        compare (0 / 0) (0 / 0) => EQ

        0 / 0 == 0 / 0 => False

    GHCi 6.8.2:

        compare (0 / 0) (0 / 0) => GT

        0 / 0 > 0 / 0 => False

Anyone interested in filing bug reports?

> […]

Best wishes,
Wolfgang