[Haskell-cafe] Re: Why purely in haskell?

[Roman Leshchinskiy]

Wolfgang Jeltsch wrote:
> Am Freitag, 11. Januar 2008 11:33 schrieben Sie:
>> Wolfgang Jeltsch <g9ks157k at acme.softbase.org> writes:
>>> However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking.
>>>  It doesn’t adhere to any meaningful axiom set for Eq.
>> Tough luck, but that's how floating point works, and what the
>> numericalists know, and possibly even love (although I have my
>> doubts).  Sanitizing this behavior would make Haskell less usable for
>> real-world numerical problems.
> 
> The IEEE floating point equivalence test has to yield false when comparing NaN 
> with NaN.  Haskell’s (==) has to yield True or undefined when comparing a 
> value with itself.  So Haskell’s (==) just has to be different from the IEEE 
> floating point equivalence test.  What about providing a separate function 
> for the latter?

I wonder where the requirement on (==) you mention above is specified. I 
can't find it in the report but maybe I just overlooked it. OTOH, the 
report does say: "The Ord class is used for totally ordered datatypes". 
IEEE comparisons are not a total ordering so in principle, they can't be 
used in the Ord methods. Also, comparing IEEE-like numbers for equality 
is practically always a mistake (the cases where it isn't are 
exceedingly rare) so the Eq instance for Float and Double doesn't 
actually provide any meaningful functionality.

Anyway, having "correct" but inefficient implementations of Eq and Ord 
method for floating-point numbers sounds like a good idea to me, 
provided that the fast comparisons are still available. Personally, I'd 
be fine with not having those instances at all but that's just me, I guess.

>> As a compromise, what about an option to make NaN (and presumably the
>> infinities) cause an immediate exception?  (And, cetero censeo,
>> exceptions for Int overflow as well.)
> 
> This would be far better (and far more Haskell-like).

No, it would be far more Haskell-like not to use Float and Double (nor 
Int, for that matter) for things they shouldn't be used for. If all you 
want are fractions use Rational. Float and Double are (or should be) 
only for high-performance computations and people implementing those 
ought to know what they are doing. If they don't, they'll have much 
bigger problems than NaNs not being equal to themselves. BTW, some 
algorithms depend on silent NaNs and many depend on infinity.

As an aside, I'd recommend

   http://citeseer.ist.psu.edu/goldberg91what.html

as an introduction to some of the problems with floating point. The 
paper also talks about some uses for silent NaNs.

Roman