Date: Sat, 14 Jul 2001 21:03:14 -0700 From: Jim Pirzyk <Jim.Pirzyk@disney.com> To: jmcoopr@webmail.bmi.net, Stephen Montgomery-Smith <stephen@math.missouri.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: math library difference between linux emulation and native freebsd (and native linux) Message-ID: <01071421031403.00729@snoopy> In-Reply-To: <200107141907.MAA07030@smtp.bmi.net> References: <200107141907.MAA07030@smtp.bmi.net>
next in thread | previous in thread | raw e-mail | index | archive | help
So the solution to my problem was to set the __INITIAL_NPXCW__ to
0x37F. What I can think of is that the freebsd binary sets
the Control Word to this before running but the linux binary
does not (because it is assumed to already be set by the kernel
at boot time). So I would think the linux kernel module would need
to set it also.
- JimP
On Saturday 14 July 2001 12:00 pm, jmcoopr@webmail.bmi.net wrote:
> 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
> ------------------------------------------------------
--
--- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $
__o Jim.Pirzyk@disney.com ------------- pirzyk@freebsd.org
_'\<,_ Senior Systems Engineer, Walt Disney Feature Animation
(*)/ (*)
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?01071421031403.00729>