Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!xylogics!merk!alliant!linus!think!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.c Subject: Re: Inherent imprecision of floating point variables Message-ID: <39853@think.Think.COM> Date: 5 Jul 90 22:46:38 GMT References: <3300@crash.cts.com> <44436@ism780c.isc.com> <4186@jato.Jpl.Nasa.Gov> Sender: news@Think.COM Reply-To: barmar@nugodot.think.com (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 32 In article <4186@jato.Jpl.Nasa.Gov> kaleb@mars.UUCP (Kaleb Keithley) writes: >In article dylan@ibmpcug.CO.UK (Matthew Farwell) writes: [A for-loop iterating by 0.1] >-If its all to do with conversion routines, why doesn't this stop when f >-reaches 10? >Because (10.0 - 0.1) + 0.1 will never be exactly equal to 10.0. Well, it does on my IEEE-compliant Symbolics Lisp Machine. But other floating point formats may not have this property. And there are other floating point computations that don't obey normal arithmetic axioms; for instance, 10.0 * .1 == 1.0 .1+.1+.1+.1+.1+.1+.1+.1+.1+.1 == 1.0000001 This latter inequality is the reason the loop fails to terminate. The problem is that 1/10 is a repeating fraction in binary, so the internal representation of .1 can't be exactly right. The multiplication happens to round in such a way that the error is cancelled out, but the repeated additions accumulate the errors because there's a rounding step after each addition step. In fact, here's a smaller case that demonstrates this: .1 + .1 == .2 .5 + .1 == .6 .5 + (.1 + .1) == .7 (.5 + .1) + .1 == .70000005 -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar