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

[Daniel Fischer]

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 <wren at freegeek.org>
> > 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