This is the mail archive of the
mailing list for the glibc project.
Re: Alternative math libraries
- To: moshier at moshier dot ne dot mediaone dot net
- Subject: Re: Alternative math libraries
- From: Bruce Allen <ballen at gravity dot phys dot uwm dot edu>
- Date: Thu, 24 May 2001 04:22:21 -0500 (CDT)
- cc: ballen at uwm dot edu, libc-alpha at sources dot redhat dot com
Thanks for sending me this. I don't have a use for it myself. I'm just
bothered that libm returns completely incorrect values for the trig
functions. You are correct that the ieee754 only governs sqrt() and not
any other functions. Every other serious math library I have seen returns
the (closest float to the) correct result.
If you look at the files http://www.cs.berkeley.edu/~wkahan/ieee754status/
(William Kahan is the father of the ieee754 conventions) you'll find he
lists returning an "invalid" flag for cos(2^120), rather than the correct
result, as one of his critiques of another library.
The documentation for Sun's numerical library
under "Argument reduction for trig functions" says:
"Trigonometric functions for radian arguments outside the range [-/4,/4]
are usually computed by reducing the argument to the indicated range by
subtracting integral multiples of /2.
Because is not a machine-representable number, it must be approximated.
The error in the final computed trigonometric function depends on the
rounding errors in argument reduction (with an approximate as well as the
rounding), and approximation errors in computing the trigonometric
function of the reduced argument. Even for fairly small arguments, the
relative error in the final result may be dominated by the argument
reduction error, while even for fairly large arguments, the error due to
argument reduction may be no worse than the other errors.
There is widespread misapprehension that trigonometric functions of all
large arguments are inherently inaccurate, and all small arguments
relatively accurate. This is based on the simple observation that large
enough machine-representable numbers are separated by a distance greater
There is no inherent boundary at which computed trigonometric function
values suddenly become bad, nor are the inaccurate function values
useless. Provided that the argument reduction is done consistently, the
fact that the argument reduction is performed with an approximation to is
practically undetectable, because all essential identities and
relationships are as well preserved for large arguments as for small.
libm and libsunmath trigonometric functions use an "infinitely" precise
for argument reduction. The value 2/ is computed to 916 hexadecimal digits
and stored in a lookup table to use during argument reduction.
(The missing character several places above is \pi).
It seems that all math libraries except for the glibc do this correctly.
I think it's too bad that the intel linux libm gives incorrect answers.
On Wed, 23 May 2001, Stephen L Moshier wrote:
> Here are two versions of Sun's fdlibm library that can be compiled on
> an x86 PC computer. I do not know what would happen if one tries to
> build the glibc version of fdlibm on a PC. The code that Sun made
> public functions just with Sun's pre-ANSI compiler on a Sun sparcstation
> and it has taken a lot of work by Drepper and others to produce versions
> for different computers and compilers.
> Newlib (http://sources.redhat.com/newlib/)
> This fdlibm version is the one used by Cygwin for Microsoft Windows.
> I was able to build it for a pc-linux box without much trouble.
> DJGPP (http://www.delorie.com/)
> This fdlibm was derived from the Newlib version, I believe.
> It comes with Delorie's self-contained development system for MS-DOS.
> I do not know how hard it would be to build it for linux. I do know
> that it was subjected to some math tests several years ago.