From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Possible truncation error
Date: 27 Jun 2000 19:21:17 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 19
Message-ID: <8jaurd$1tg$1@nets3.rz.RWTH-Aachen.DE>
References: <_x665.15310$Za1 DOT 242989 AT newsc DOT telia DOT net>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 962133677 1968 137.226.32.75 (27 Jun 2000 19:21:17 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 27 Jun 2000 19:21:17 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Erik Berglund <erik2 DOT berglund AT telia DOT com> wrote:
> Hi, I tried the following program, which gives
> j=9999. I think the right result should be 10000,
> because a=0x40c3880000000000, which is exactly 10000.

In a nutshell: hidden extra precision. The FPU registers keep
temporary results in 'long double' precision. Only if you force the
values back into memory (like your access to it via pointers to
integer does it), they'll become proper double's again. Microscopic
differences in results may be generated by the optimizer moving around
code, in this situation.

Morale: don't *ever* rely on the contents of the last (few) binary
digits of floating point numbers.  They're allowed to behave totally
unpredictably.  Don't try to understand the logic behind their
behaviour --- there is none.
-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.