[Larceny-users] A Floating Hole

[William D Clinger]

David Rush wrote:
> Well, the man page on my Debian Etch says that FLT_MIN == DBL_MIN ==
> LDBL_MIN == 1E-37, which seems silly but there you go. In any case,
> the cos approximation is rather less accurate than any of those
> minima.

You need to understand that Larceny's value for (acos 0)
is the best IEEE double precision approximation to pi/2.
It is not pi/2, however, so the cos procedure correctly
returns a nonzero value for (acos 0).  If cos were to
return 0.0 for (acos 0), then cos would be *less* accurate
than is currently the case.

> Naah, I figured that part out already. What I'm really looking for is
> a way to minimize the roundoff error in trig functions (so I can
> actually find the zeros). It's looking like reducing all trig
> evaluations to the +x+y quadrant and using symmetry to return to the
> actual value might be the best answer. _Numerical Recipes_ also
> recommends using a mutant recurrence relation for iterating sines and
> cosines over equally spaced angular samples, and I'm thinking of
> trying that.

As explained above, the only way to do better is to use
more precision throughout, or to use something other than
binary floating point.

Larceny will continue to represent inexact reals in IEEE
floating point.  Given that design decision, which is
regarded as best current practice, this isn't something
Larceny can fix.

Will