Date: Sat, 14 Jul 2001 12:00:43 -0700 From: jmcoopr@webmail.bmi.net To: Stephen Montgomery-Smith <stephen@math.missouri.edu>, Jim.Pirzyk@disney.com, freebsd-hackers@FreeBSD.ORG Subject: Re: math library difference between linux emulation and native freebsd (and native linux) Message-ID: <200107141907.MAA07030@smtp.bmi.net> In-Reply-To: <3B50966E.1D6E5DCC@math.missouri.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In <3B50966E.1D6E5DCC@math.missouri.edu>, on 07/14/2001
at 01:58 PM, Stephen Montgomery-Smith <stephen@math.missouri.edu>
said:
>Yes, I tried out the program
>#include <stdio.h>
>#include <math.h>
>main() {
> double x,y;
> int i;
> x = 53.278500;
> y = exp(x);
> printf("%8lf\n",x);
> for(i=0;i<sizeof(double);i++)
> printf("%x ",((unsigned char*)(&x))[i]);
> printf("\n");
> printf("%8lf\n",y);
> for(i=0;i<sizeof(double);i++)
> printf("%x ",((unsigned char*)(&y))[i]);
> printf("\n");
>}
>On FreeBSD and Linux I get
>53.278500
>cf f7 53 e3 a5 a3 4a 40
>137581029243568449912832.000000
>e7 7d 89 54 48 22 bd 44
>and on Linux emulation under FreeBSD I get
>53.278500
>cf f7 53 e3 a5 a3 4a 40
>137581029243567812378624.000000
>c1 7d 89 54 48 22 bd 44
>I don't really know the format of IEEE very well, but it looks like
>some low order bits are different - the answers are really different.
>I also tried the same experiment with sin and gamma - then the problem
>does not occur. Well except that the answer for gamma(53.278500) is
>reported as 157.464664 which is way wrong.
>When I tried it for x=52 they gave almost the same answer, only
>seperated by the last bit (the decimal versions were reported as the
>same). For x=54 they both gave the same wrong answer 160.331128.
>I don't know a whole lot about IEEE. What is the largest number it is
>supposed to handle? Looking at man math it says it should handle
>numbers as large as 1.8e308 - we certainly are not in that range!!!
But remember, floating point is DIFFERENT--nothing is exact. You can
create a number with a magnitude about 1.8e308, but you sure don't get
308 significant digits. Very big and very small floating point
quantities need special treatment to avoid all sorts of underflow,
overflow, singularity, degraded precision, etc. Naive, calculator-like
assumptions about floating point will get one into trouble very, very
quickly.
The real question should be how many significant digits are the Linux /
FreeBSD implementations alike.
For:
4-byte floats--6 digits is all you're likely to get, the rest is noise
8-byte doubles--12-13 digits is all that is reasonable
10-byte long doubles--15 digits, and then the world falls in
Expectations beyond this are beyond the capability of i386 floating
point hardware. They're also way beyond what you usually need.
jmc
------------------------------------------------------
jmcoopr@webmail.bmi.net
Using OS/2 since 1.0
------------------------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107141907.MAA07030>