On Mar 22, 2007, at 8:21 AM, Ketil Malde wrote:
Neil Mitchell wrote:
I'm still not happy with adding more incompleteness into something that intuitively feels safe - compare is pretty benign. Having a crash on division is something that does appeal to me more. Are you suggesting that 0.0/0.0 should crash also? I'm no expert, but think returning a NaN is according to the floating point standard (IEEE 754), and I'm not convinced Haskell should break that.
IIRC, signaling NaNs (ie, throwing an error), are also allowed under IEEE 754, albeit less common. In the context of Haskell, I think it makes a lot more sense. Remove NaN as a value and Float/Double regain a total orders, and real equivalence relations (not PERs). Also, if I get a NaN in a calculation, I'd personally rather get an exception than have NaNs infect the entire computation and only find out later. Another potentially attractive option is to recast Eq as being only a PER (remove the reflexivity assumption) and allow Ord to be a partial order. Or maybe: class PEq a where { (==) (/=) :: a -> a -> Bool } class PEq a => Eq a class POrd a where { compare :: ....; (<=) :: ...; etc } class POrd a => Ord a so we introduce new classes with the relaxed semantics and make Ord/ Eq subclasses with no new operations. Although, this is obviously Haskell' territory.
If you use floating point, you need to know the pitfalls anyway. Maybe comparing NaNs should give random results? :-)
The bad thing is that comparison can hide the NaNs (for arithmetic, NaNs will be contagious, so you'll likely get a NaN riddled output). One thing I remember seeing (from Fortran compilers?) is that when a program execution involves a NaN, it is reported on termination, even if the NaN was in an intermediate calculation and not part of the final result. Something like that could perhaps be useful if the current behavior is kept?
-k
Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG