[Larceny-users] A Floating Hole

[William D Clinger]

David Rush wrote:
> I am currently moderately annoyed that
> 
> > (cos (acos 0))
> 6.123233995736766e-17
> 
> on Larceny. Now it appears that this is an inescapable feature of the
> C runtime;

Indeed, it illustrates the inescapable misfeature known as
roundoff error.  Most real numbers, including pi/2, are not
representable in binary floating point of any finite precision.
The consequent small errors are more likely to accumulate
during subsequent computations than to cancel themselves out.

> however, given that FLT_MIN on the x86 platform is 1E-37,
> mapping this result to #i0 is somewhat problematic.

FLT_MIN isn't relevant here, since Larceny uses IEEE double
precision.  Were Larceny to use single precision, as you are
assuming, the roundoff errors would be much worse.

> I'm wondering if there
> is a Larceny-specific way to either
> 
> 1) get a more accurate cos function (e.g. POSIX cosl which returns a
> long double)

No, although you could use Larceny's FFI to do that.

> 2) extract some kind of underlying precision information about the
> Larceny's flonums (and maybe individual operations)

(system-features) will give you that information.  Currently,
however, all supported varieties of Larceny use IEEE double
precision on all supported architectures.

Perhaps you will feel better about this once you realize that
C programs experience the same kinds of roundoff error.  For
example:

#include <stdlib.h>
#include <math.h>
#include <stdio.h>

int main( int argc, char **argv ) {
  printf("%g\n", cos(acos(0.0)));
}

On the two machines I tried, the result was 6.12323e-17,
which is consistent with Larceny's result.  Note that C
uses double or extended precision for the above program.

Other data points for (cos (acos 0)):

    Bigloo    6.1230317691119e-17
    Chicken   6.12303176911189e-17
    Gambit-C  6.123031769111886e-17
    Ikarus    6.123031769111886e-17
    Kawa      6.123233995736766E-17
    Larceny   6.123031769111886e-17
    MIT       6.123031769111886e-17
    PLT       6.123031769111886e-17
    Petite    6.123031769111886e-17
    Scheme48  6.123031769111886e-17
    scm       6.123031769111886e-17
    Ypsilon   6.123031769111886e-17

The outputs shown for Bigloo and Chicken illustrate
their violation of R5RS 6.2.6.  Kawa's result is the
same as what I get from C, which may mean Kawa uses
an extended precision for the intermediate result
(of acos) instead of rounding to double precision;
that usually improves accuracy or has no effect, but
occasionally gives a less accurate result.

Will