From:	kagel AT quasar DOT bloomberg DOT com
Date:	Thu, 6 Feb 1997 09:27:58 -0500
Message-Id:	<9702061427.AA26252@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.970206083831.4379F-100000@is> (message from Eli Zaretskii on Thu, 6 Feb 1997 08:44:11 +0200 (IST))
Subject:	Re: double-->int: What's wrong here?
Reply-To:	kagel AT dg1 DOT bloomberg DOT com

   Date: Thu, 6 Feb 1997 08:44:11 +0200 (IST)
   From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>

   On Wed, 5 Feb 1997, Vyacheslav O. Myskin wrote:

   > The output is:
   > n1=214  n2=215  d2=215.000000
   > 
   > So why  n1 is not equal to n2? It's not fun because I used n1 as an
   > argument to malloc() and kept getting SIGSEGVs later :(

   Never assume floating-point computations are exact: they aren't.  The
   exact reason for what your example printed are immaterial (it's a long and
   quite dull story; you might consider adding -S to gcc command line and
   looking at the assembly it generates to see what's going on).  The real
   lesson is that you should always round the FP numbers explicitly before
   using them as counters of anything.  In your case, say n1 = .05/d1 + 0.5
   and live happily ever after. 

But Eli, 1.0/4300.0 ==> 0.000232558139535  
and n1 = .05/d1 ==> 215.000000000000000
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.
Vyacheslav may have indeed found something.  Vyacheslav are you using the
emulator or an x87?  Which?

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