[Haskell-cafe] Re: Why purely in haskell?
rl at cse.unsw.edu.au
Fri Jan 11 08:52:59 EST 2008
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
as an introduction to some of the problems with floating point. The
paper also talks about some uses for silent NaNs.
More information about the Haskell-Cafe