Date: 22 Nov 1992 13:23:39 +1100
From: Bill Metzenthen <APM233M AT vaxc DOT cc DOT monash DOT edu DOT au>
Subject: Re: asin (& atan) ok?
To: djgpp AT sun DOT soe DOT clarkson DOT edu

Peter Stephenson <pws AT s-a DOT amtp DOT liv DOT ac DOT uk> writes:

[stuff deleted]

> If you're using emu387, the atan() emulation is certainly a bit off for
> large arguments: it gives 4*atan(1.0) as 3.05 instead of pi (does the
> state of Tennessee know?  :-) (historical joke)).  The asin() routine
> calls fpatan so suffers from this. wmemu387 seems to have the same problem.

Hmmm, one of the things I did in wmemu387 was improve the accuracy of
the fpatan function. The above statement therefore comes as quite a
surprise to me! This caused me to fire up ms-dos (I normally run Linux
these days) and run the following little program:

    #include <math.h>
    #include <stdio.h>
    main() {
    printf("atan -> %f, pi = %f, diff = %g\n",
       4.*atan(1.0), M_PI, 4.*atan(1.0) - M_PI); }

When I compiled this and ran it I got:

atan -> 3.1415927, pi = 3.1415927, diff = 1.225148e-16

This primarily shows the error in M_PI, not atan(1)!  (The small error
here is due to the fact that the result returned by atan() is accurate
to something like 63 or 64 bits precision, while M_PI is a double and
therefore accurate to only 54 bits or so.)

> It looks like it's computing atan as a power series for all arguments

Yes, the original emu387 uses a truncated Taylor series. It is not a
good way of computing atan. On the other hand, wmemu387 uses
polynomials, the coefficients of which are *not* simply taken from a
power series.

The only problem which I am aware of with the fpatan code in wmemu387
is that it is a little slower than it needs to be (but still much
faster than the original emu387). I have managed to remove this minor
problem and I hope to release a new emulator for djgpp (with source)
rsn.


--Bill