[Haskell-cafe] haskell gsoc proposal for richer numerical type
classes and supporting algorithms
daniel.is.fischer at web.de
Thu Apr 8 21:53:01 EDT 2010
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)
Prelude> isNaN (0.0/0.0)
Prelude> (0.0/0.0) == (0.0/0.0)
> 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.
More information about the Haskell-Cafe