[Haskell-cafe] Re: Why purely in haskell?
Felipe Lessa
felipe.lessa at gmail.com
Fri Jan 11 05:03:03 EST 2008
On Jan 11, 2008 7:47 AM, Miguel Mitrofanov <miguelimo38 at yandex.ru> wrote:
> > However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking.
>
> Just for the record: the following is from Firebug (JavaScript debugger for Firefox) session:
>
> >>> a = 0/0
> NaN
> >>> a == a
> false
> >>> a === a
> false
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. However you can always define something
like
newtype NotADouble = N Double
...
instance Eq NotADouble where
N x == N y = (isNaN x && isNaN y) || (x == y)
...
--
Felipe.
More information about the Haskell-Cafe
mailing list