[Haskell-cafe] Re: A question about "monad laws"

jerzy.karczmarczuk at info.unicaen.fr jerzy.karczmarczuk at info.unicaen.fr
Thu Feb 14 07:42:07 EST 2008


Jed Brown comments the answer of - 

 -- Roman Leshchinskiy who answers my question concerning the replacement
of floating-point numbers: 

>> > First, when I see the advice "use something else", I always ask "what",
>> > and I get an answer very, very rarely... Well? What do you propose?

>> For Haskell, Rational seems like a good choice. The fact that the 
>> standard requires defaulting to Double is quite unfortunate and 
>> inconsistent, IMO; the default should be Rational. Float and Double 
>> shouldn't even be in scope without an explicit import. There really 
>> is no good reason to use them unless you are
>> writing a binding to existing libraries or really need the performance.

Here Jed Brown says: 

> Until you need to evaluate a transcendental function. 
...
It would be killing, wouldn't it?... 

I would say more. It is known that in randomly taken, usual formulae in
physics, engineering, etc., if you start with rationals, *typically* the
GCD between numerator and denominator will be small, the reductions of
fractions are not very effective. Your rationals explode very fast!
If after some reasonable number of operations you get rationals whose
num/den have millions of digits, the program becomes *completely useless*,
this is not "just" the questions of performance. 

Richard O'Keefe said that people speculate about floating-point numbers
without knowing them. Well, nobody is perfect...
I am a bit disturbed by people, who speculate without ever *needing*
fl.p's, and who haven't thus the sensibility. For them this is a kind of
game. Well, it isn't. 

R.L. says: 

> For all practical purposes, the semantics of (==) is not well defined 
> for floating point numbers. That's one of the first things I used to 
> teach my students about floats: *never* compare them for equality. 
> So in my view, your example doesn't fail, it's undefined. 
> That Haskell provides (==) for floats is unfortunate. 

I disagree, on practical basis. Floating-point numbers are very well
defined, we know how the mantissa is represented. If the numbers are
normalized, as they should, plenty of low-level iterative algorithms
may use the equality - after some operation - to check that the machine-
precision convergence has been obtained. On the contrary, the verification 
that the absolute value between two terms is less than some threshold,
may be arbitrary or dubious. 

Jerzy Karczmarczuk 




More information about the Haskell-Cafe mailing list