Problem with the math library functions

Question

Hi,
I encountered a problem related to some functions provided by math library on sun. I narrowed it down to the following test program:
========================================================
#include<stdio.h>
#include<math.h>
void pow_res()
double x = 10.0;
double y = 2.5;
printf("pow(%.2e, %.2e):%.20e\n", x, y, pow(10.0, 2.5));
void cos_res()
double x = -6.433230338433114370e-02;
printf("x:%.20e cos(x):%.20e\n", x, cos(x));
int main()
pow_res();
cos_res();
return 0;
========================================================
The above test program has to be linked with any math library. It is �libm� for amd64/linux, but for sparc we have choice between �libm� and �libmopt�. I am compiling above program with "cc <test_program.c> <-lm/-lmopt>" command.
On sparc, if the above test program is getting linked with �-lm" then it gives same results for the �cos� on both amd64 and sparc, but gives different results (16th decimal digit onward) for �pow�. If it is getting linked with �-lmopt� then it gives same result for the �pow� on both the platforms, but gives different results for �cos�. Linux results match with the amd64 results.
The �Numerical Computation Guide� provided by SUN (ftp://docs-pdf.sun.com/802-5692/802-5692.pdf page 40, table 2.10 ) says that you can trust only 15-17 decimal digits for double calculation. But here the requirement is to match the sparc results exactly with the amd64/linux or at least match the result till 20th decimal digit. I guess it is something to do with the FPU setting either through compiler options or code. I tried many different compiler options, like -fast, different combinations of compiler options provided by -fast macro, but nothing helped.
Following is the system configuration:
Amd64:
gcc version: 3.3.6
OS: RedHat Enterprise Linux 3.0 U7 (Linux 2.4.21-40.ELsmp x86_64)
Sparc:
cc version: Sun C 5.8 Patch 121015-01
OS: SunOS 5.9 Generic_118558-21 sun4u sparc SUNW,Sun-Fire-280R
It will be great if somebody can explain the problem and the solution to get rid of it.
Many thanks,
Sunil

Answer 1

Transcendental functions are not specified to be correctly rounded in the same
sense as +-*/.     So it's entirely possible, and often observed, that libraries of equal
quality deliver slightly different results.
To simplify, suppose one wanted to compute x = 4*atan(1.0)
which happens to be the
transcendental number pi which is roughly, in hex and in decimali:
.C90F DAA2 2168 C234 C... * 2^4 or 3.141592653589793239...
But binary floating-point arithmetic can only represent certain rational numbers of
the form of an integer of at most 53 significant bits times a power of two. The
nearest double-precision number to pi is
.C90F DAA2 2168 C * 2^4 or roughly 3.141592653589793116...
This particular number has a large but finite decimal expansion. And if you
do printf with %e.20 you will get the 20 decimal digits of that double-precision
number's expansion, not the 20 decimal digits of pi, which only agrees to the
15 significant decimals 3.141592653589793 and differs afterward.
In the case of pow(10.0,2.5), (which happens to be sqrt(1.0e5))
the correct result in hex looks something like
.9E1D 276F D4BA C410 C... * 2^9 or roughly 3.162277660168379332...E+2
in hex notation, while the closest double precision number is
.9E1D 276F D4BA C8 * 2^9 or roughly 3.162277660168379612...E+2
but it's only slightly closer than the next closest double precision number
.9E1D 276F D4BA c0 *2^9 or roughly 3.162277660168379043...E+2
Either answer is a good answer, and math libraries might that only aspire to
deliver results that are close to correctly rounded might deliver either, depending
on which approximation algorithm is used, which might depend on what's fastest
on a particular processor.
So why don't math libraries deliver correctly rounded results instead of almost?
Because the slight extra increase in accuracy doesn't do much good for most
people, and the major decrease in performance is noticeable by lots of people.
The main payoff of correctly rounded transcendental functions is that they
promote uniform numerical results across platforms, which is worth something
to some people but not much to many people.
So for those who find it worthwhile, there are correctly rounded transcendental
function libraries available. Sun's development version is available at
http://www.sun.com/download/products.xml?id=41797765
Another solution for some people is to change double variables and functions
to long double, using powl and cosl in the examples. That increases the
accuracy to almost 20 digits on x86 and over 30 digits on SPARC, and while
the same issues eventually arise, most users would never encounter them.
The SPARC long double implementation is in software rather than hardware,
and so entails a major performance reduction compared to double.
The Numerical Computation Guide at docs.sun.com discusses many of these
issues at greater length.