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

jerzy.karczmarczuk at info.unicaen.fr jerzy.karczmarczuk at info.unicaen.fr
Fri Jan 11 07:21:45 EST 2008


Ketil Malde:
> Wolfgang Jeltsch:
>> 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. 
> 
> 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.)

People, you are monsters.
First, despite the *common, well known* truth that Haskell is not
Mathematics, this illusion seems to be extremely persistent! Haskell is
a victim -
no, some users are victims of its success as a formal language, not just
as a coding tool... They *want* to have Eq as they imagine the equality,
including the comparison between incomparable. This is BTW a long standing
philosophical problem. For centuries some speculative guys tried to analyse
such "assertions" as God == God, or death==death. Or myself==myself.
Of course, even if they produced some cute conclusions, they had no
whatsoever sense for the others. Now we have the modern variants of it:
NaN == NaN, bottom == bottom ... 

Of course, there are differences, since NaN is, no - ARE well defined
*objects*. In IEEE there may be several NaNs, if the exponent is e_max+1,
then *any* significand (mantissa for the dinosaurs) is good for a NaN. 

++ 

Then, I see here, and on some other lists some tendency to speculate on the
numerics by people who really don't need it, and don't use it. The bombing
of NaN *might* be a profound compilation option, but for people who really
do numerical work, this is a blessing NOT to have it.
 - Zero (or minimum, etc.) finders don't explode on your face when the
 automaton gets out of the range because of the instabilities.
 - Vectorized computations which produce plenty of good numbers and sometimes
 diverge, do not invalidate all work.
 - Ignoring Int overflow is a cheap way of having `mod` (MAXINT+1). Useful
 for many purposes.
 - In such vector/matrix packages as Matlab, where arrays may represent
 geometric objects, NaNs mean: "no coordinates here, empty". Simple and
 useful.
etc. 

So, don't "sanitize" anything, unless you know what you are really doing!
I would suggest to Wolfgang Jeltsch a little more of reserve before making
sharp categorical proposals concerning the fl. point computations (and
also acknowledge that NaN is not a unique entity). It is easy to propose -
in the name of "purity" to massacre existing structures; several religious
sects and political doctrines were born in such a way. The result was
usually horrible... 

The Num hierarchy in Haskell is bad, we know it, especially for people who
do some more formal mathematics. There are more interesting problems to
solve than organising a crusade against IEEE, "illegalizing" the Ord
instance for numbers, etc. 

Jerzy Karczmarczuk 




More information about the Haskell-Cafe mailing list