Re: Accuracy of floating point computation in MCL

[rwk@crl.dec.com (Bob Kerns)]

In article <1991Dec2.195334.29864@watdragon.waterloo.edu>, melewis@jeeves.waterloo.edu (Michael Lewis) writes:
> 
> The question is why isn't 3/10 coerced to  the same representation as 0.3?

Well, according to the draft ANSI standard (and I think
all the way bacl to CLtL I), that's exactly what's supposed
to happen.

"Rule of Float and Rational Contagion

When rationals and floats are combined by a numerical function,
the rational is first converted to a float of the same format.
..."

"When rationals and floats are compared by a numerical function,
the function RATIONAL is effectively called to convert the FLOAT
to a RATIONAL and then an exact compmarison is performed. ..."

So I think (by the first quoted section above) MCL has a bug wrt
plus and floating-point contagion.

But by the second, it does not have a bug with comparison, because
the float is to be coerced to a rational, and the proper rational
is not exactly 3/10.

If what you describe below is correct, it would appear to be
a bug in Franz CL (you are refering to Franz Allegro, right?)
It looks as if Franz Allegro effectively does RATIONALIZE instead
of RATIONAL.  RATIONALIZE tries to come up with the closest rational,
while RATIONAL assumes that the floating-point representation is
exact.

> For example in Franz Common Lisp we have 
> 
> <cl> (- .3 3/10)
> 
> 0.0

Correct.

> and consequently:
> 
> <cl> (< 3/10 0.3)
> NIL
> 
> and
> 
> <cl> (< .3 3/10)
> NIL

Incorrect.

> One person (jhowland%ariel.cs.trinity.edu) mentioned that J (a descendent
> of APL) permits a user determined tolerance for arithmetic comparisons.
> Has anyone  done this in MCL?  In general CL?

It's easy enough to do yourself.  After all, you're likely
to need different "fuzz factors" at different points in
your algorithm.