On Apr 7, 2006, at 9:43 AM, Jacques Carette wrote:
Robert Dockins wrote:
The behaviour of NaN actually makes perfect sense when you
realise that
it is Not a Number. Things that are not numbers are incomparable
with
things that are.
Yes, NaN can be of type Float. But it's not a Float.
If you take that tack, then you have to concede that the type
system isn't doing what it should (keeping me from having
something not-a-float where I expect a float). Any way you slice
it, its an unfortunate situation.
I'd personally rather that any operation generating NaN raises an
exception, a la divide by 0 at Int. I think (although I'm not
sure) that the floating point infinities play nice wrt equality
and ordering, so getting rid of NaN would restore at least _some_
semblance of proper algebraic behavior to the floating point
representations. (And the FFI already has CFloat/CDouble, so you
should use those when you really need to actually do something
with NaN generated by external code, and CFloat/CDobule should not
be members of Eq and Ord).
Or at the very least, attempting to compare NaN using (==) or (<)
and friends should raise an exception, rather than just returning
broken results.
Rob Dockins
The IEEE 754 standard explicitly specifies that complete
implementations can have either or both 'signalling' NaNs and
'quiet' NaNs. It appears that current Haskell implementations have
chosen to go with quiet NaNs, which is very surprising indeed, as
that does go "against" the type system. Signalling NaNs are more
consistent with the rest of Haskell's semantics.
However, it is also important to note that IEEE 754 also mandates
'trap handlers' for signalling NaNs, so that implementors may
choose (even at run-time, on a per-instance basis) what to do with
any given occurence of NaN. In particular, it is possible to
resume the computation with a _value_ being substituted in for that
NaN. These 'trap handlers' are also in there for division-by-zero,
so that one may _choose_ to return either infinity or raise an
actual exception.
If one reads the standard (IEEE 754) carefully enough, it is
possible to 'pick' an implementation of it which actually fits in
with Haskell fairly well. Yes, the standard is explicitly written
to have *choices* in it for implementors. The current
implementation is generally standard-compliant, but does not seem
to 'pick' a path of least-resistance wrt the rest of Haskell.
Is this an H' worthy item?
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
-- TMBG
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
