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