Re: [Haskell-cafe] Re: Why purely in haskell?
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
On Jan 11, 2008 7:47 AM, Miguel Mitrofanov
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.
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
If you can't stomach the weirdness of floating point then perhaps you should
try to define your own type that obeys all the expected laws? :)
On Jan 11, 2008 3:36 AM, 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (4)
-
Felipe Lessa -
Lennart Augustsson -
Miguel Mitrofanov -
Wolfgang Jeltsch