From:	"Erik Jensen" <eljensen AT online DOT no>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Problems with DJGPP V2.01 - atof() function
Date:	2 Dec 1996 06:05:01 GMT
Organization:	Telenor Online Public Access
Lines:	23
Message-ID:	<01bbe017$3558c3e0$c900d6c1@big-papa>
References:	<329e68a5 DOT 10316617 AT news DOT ua DOT pt> <57mtq1$4mo AT vidar DOT diku DOT dk> <32A02DD1 DOT 1157 AT pobox DOT oleane DOT com> <Pine DOT SOL DOT 3 DOT 91 DOT 961201085145 DOT 18913B-100000 AT aten> <32A18E63 DOT 3F09 AT pobox DOT oleane DOT com>
NNTP-Posting-Host:	oslo1111.telepost.no
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Francois Charton <deef AT pobox DOT oleane DOT com> wrote in article
<32A18E63 DOT 3F09 AT pobox DOT oleane DOT com>...
> 
> This is quite interesting : the "more precise" 80bit number, or the cast 
> to double gives the wrong answer (mathematically I mean), whilst the 
> "rough" float truncate yields the right one... (And the truncated number 
> is bigger than the "less truncated" one: this is not what could be 
> expected from a truncature operation on a positive number).
> 
> 
> Francois
> 
> 

His example says noting of how imprecise the two results were. The "more
precise" 80bit result may have been 113 - 1e-15 rounding correctly to 112
and the "less precise" number being 113 + 1e-13 rounding correctly to 113.
Which is why it's always a good idea to add .5 before converting it to int.

-Erik-

- Raw text -