Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Jul 2001 12:08:40 -0700
From:      Jim Pirzyk <Jim.Pirzyk@disney.com>
To:        Stephen Montgomery-Smith <stephen@math.missouri.edu>
Cc:        jmcoopr@webmail.bmi.net, freebsd-hackers@FreeBSD.ORG
Subject:   Re: math library difference between linux emulation and native freebsd (and native linux)
Message-ID:  <iss.52.3b5098b7.43caa.1@mercury.fan.fa.disney.com>
In-Reply-To: <3B50966E.1D6E5DCC@math.missouri.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

On Saturday, July 14, 2001, at 11:58 AM, Stephen Montgomery-Smith wrote:

> 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!!!

I know with the base and mantissa, not all floating points in that range
can be represented.  The higher, or smaller (negative) numbers you go,
the loss of percision you get in those ranges.  The first numbers I found
having this problem is 19.901112.  This is with exp(), pow also had some
cases that were different.

- JimP

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?iss.52.3b5098b7.43caa.1>