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:	<Pine.SUN.3.91.970206164519.5706D-100000@is> (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 <eliz AT is DOT elta DOT co DOT il>


   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

- Raw text -