X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f
Sender: micah AT 12-234-128-39 DOT client DOT attbi DOT com
Newsgroups: comp.os.msdos.djgpp,comp.lang.c++
Subject: Re: Weird double problem?!
References: <142c67c0 DOT 0204092338 DOT 1ce7acb3 AT posting DOT google DOT com> <15Ss8.263184$q2 DOT 31204 AT sccrnsc01>
From: Micah Cowan
Message-ID:
Lines: 53
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
NNTP-Posting-Host: 12.234.128.128
X-Complaints-To: abuse AT attbi DOT com
X-Trace: sccrnsc02 1018430686 12.234.128.128 (Wed, 10 Apr 2002 09:24:46 GMT)
NNTP-Posting-Date: Wed, 10 Apr 2002 09:24:46 GMT
Organization: AT&T Broadband
Date: Wed, 10 Apr 2002 09:24:46 GMT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com
"Victor Bazarov" writes:
> "Taras" wrote...
> > Just doing some basic programming for maths, and something really
> > weird happened. I'm using RHIDE 1.4.9 w/ djgpp 2.03. I have this
> > line in my
> > program:
> >
> > const double stepSize;
> > stepSize = 0.1;
>
> The above code should not compile. You've declared a const without
> initialising it and then you're modifying a const value without any
> const-cast. You probably meant
>
> const double stepSize = 0.1;
>
> > when i step through the program and watch the variable step size, when
> > it
> > is assigned the value of 0.1, in the watch window it says the value is
> > 0.10000000000000001. I don't think it has something to do with the
> > displaying of the number, because when I store the result of
> > 1/stepSize
> > into an integer variable, the value of that variable is 9 (when it
> > should be
> > 10) Does anyone know where the last digit came from?
>
> From the fact that 1/10 cannot be represented _precisely_ in your
> computer memory.
Well... 1/10 *can* be represented, precisely, in your computer
memory. Just not as a binary floating point number :)
To the OP: think about the decimal representation of 1/3: 0.33333...
That number cannot be represented precisely in decimal without an
infinite number of digits. But in base 3, it'd be easy to write:
0.1. In decimal, 1/10 is easily expressed as 0.1, but in binary
notation, it requires an infinite number of digits. Since the
computer stores everything in binary, you can't represent 0.1 exactly
as a floating point number.
Floating point numbers are notoriously imprecise, in general. You
should pretty much never count on a floating point number to hold
exactly the value you placed in it. The usual way of dealing with
this imprecision is to account for it in all equality tests, by
comparing the difference to a small number representing the acceptable
margin of error.
If you *need* exactly exact numbers, then store them as a pair of
integers. After all, both 1/10 and 1/3 are exactly representable in
the form in which you find them written in this sentence ;)
Micah