Mail Archives: djgpp/1992/11/21/21:57:13
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
- Raw text -