From: kagel AT quasar DOT bloomberg DOT com Date: Thu, 6 Feb 1997 10:23:28 -0500 Message-Id: <9702061523.AA26361@quasar.bloomberg.com > To: eliz AT is DOT elta DOT co DOT il Cc: myskin AT inp DOT nsk DOT su, djgpp AT delorie DOT com In-Reply-To: (message from Eli Zaretskii on Thu, 6 Feb 1997 16:46:42 +0200 (IST)) Subject: Re: double-->int: What's wrong here? Reply-To: kagel AT dg1 DOT bloomberg DOT com Date: Thu, 6 Feb 1997 16:46:42 +0200 (IST) From: Eli Zaretskii On Thu, 6 Feb 1997 kagel AT quasar DOT bloomberg DOT com wrote: > to the limit of a double's precision (the next 5 digits would 86000 in the > 80bit internal x87 representation. There is no imprecision in this calculation > due to binary floating point effects and adding 0.5 will not change the results. Are you sure? Did you run that small test program with and without + 0.5? If not, please do. I'm pretty sure it will help. Same exact results. BTW I am testing on a DG using GCC I am not home to test DJGPP on my Cyrix 686 so this may be the difference in internal precision between the x87 and M88100's MMU. However I checked the results in bc, which does not use binary floating point and got the exact same results to 15 decimal places as the "C" test program (in fact that is where I got the value for digits 16-20). Since all of the operands are exactly representable in 64bit IEEE floating point (ie 1, 4300, .05, 0.000232558139535, & 215.0) this is not a rounding problem but either 1) FPU error, 2) FPU Emulator error, or 3) Error in the generated assembler code. I'm just saying we do not now enough yet to dismiss this guy's problem as sloppy floating point source code. (BTW I agree with your recommendation in the general case, though, I usually use 0.505 as an error correction value.) -- Art S. Kagel, kagel AT quasar DOT bloomberg DOT com A proverb is no proverb to you 'till life has illustrated it. -- John Keats