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