On Apr 7, 2006, at 1:36 AM, [EMAIL PROTECTED] wrote:
G'day all.
Quoting Robert Dockins <[EMAIL PROTECTED]>:
Ewwwwww! Be careful how far you depend on properties of
typeclasses, and make
sure you document it when you do.
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.
Cheers,
Andrew Bromage
Rob Dockins
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
