From owner-freebsd-hackers Sat Jul 14 12: 8: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.bmi.net (smtp.bmi.net [204.57.191.31]) by hub.freebsd.org (Postfix) with ESMTP id CFA5337B417 for ; Sat, 14 Jul 2001 12:07:56 -0700 (PDT) (envelope-from jmcoopr@webmail.bmi.net) Received: from warp-borg (dsl-154.bmi.net [207.173.60.230]) by smtp.bmi.net (Pro-8.9.3/Pro-8.9.3) with SMTP id MAA07030; Sat, 14 Jul 2001 12:07:26 -0700 From: jmcoopr@webmail.bmi.net Message-Id: <200107141907.MAA07030@smtp.bmi.net> Date: Sat, 14 Jul 2001 12:00:43 -0700 To: Stephen Montgomery-Smith , Jim.Pirzyk@disney.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <3B50966E.1D6E5DCC@math.missouri.edu> Subject: Re: math library difference between linux emulation and native freebsd (and native linux) X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.28a/28 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In <3B50966E.1D6E5DCC@math.missouri.edu>, on 07/14/2001 at 01:58 PM, Stephen Montgomery-Smith said: >Yes, I tried out the program >#include >#include >main() { > double x,y; > int i; > x = 53.278500; > y = exp(x); > printf("%8lf\n",x); > for(i=0;i printf("%x ",((unsigned char*)(&x))[i]); > printf("\n"); > printf("%8lf\n",y); > for(i=0;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