Re: [Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms

Am Freitag 09 April 2010 02:51:23 schrieb Gregory Crosswhite:

On Apr 8, 2010, at 5:30 PM, Casey McCann wrote:

...

On Thu, Apr 8, 2010 at 7:58 PM, wren ng thornton wrote:

Exactly. NaN /= NaN

[...]

...

Indeed. NaN means that equality is not reflexive for floats in general, only a subset of them.

First of all, it isn't clear to me that NaN /= NaN,

Specified by IEEE 754, IIRC.

since in ghci the expression "1.0/0.0 == 1.0/0.0" evaluates to True.

Yes, but 1/0 isn't a NaN: Prelude> isNaN (1.0/0.0) False Prelude> isNaN (0.0/0.0) True Prelude> 1.0/0.0 Infinity Prelude> 0.0/0.0 NaN Prelude> (0.0/0.0) == (0.0/0.0) False

But even if that were the case, I would call that more of a technicality then meaning that equality is not reflexive for floats, since NaN is roughly the floating-point equivalent of _|_, and using the same argument one could also say that reflexivity does not hold in general for equating values of *any* Haskell type since (_|_ == _|_) does not return true but rather _|_.

Very roughly. But I agree with your point, though x == x returning False isn't quite the same as x == x returning _|_ (repeat 1 == repeat 1).

(Don't get me wrong, I agree with your point that multiplication and addition are neither associative nor distributive and other such nasty things occur when dealing with floating point numbers, it's just that I think that saying they are so messed up that even equality is not reflexive is a little harsher than they actually deserve. ;-) )

Yup. But using (==) on floating point numbers is dangerous even without NaNs. Warning against that can be beneficial.

Cheers, Greg