From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c7637cfdf68e766 X-Google-Attributes: gid103376,public X-Google-Thread: f8362,c7637cfdf68e766 X-Google-Attributes: gidf8362,public X-Google-Thread: f43e6,c7637cfdf68e766 X-Google-Attributes: gidf43e6,public X-Google-Thread: 107079,c7637cfdf68e766 X-Google-Attributes: gid107079,public X-Google-Thread: 109d8a,c7637cfdf68e766 X-Google-Attributes: gid109d8a,public From: Samuel Mize Subject: Re: floating point comparison Date: 1997/07/31 Message-ID: <33E0EFFA.698E@link.com>#1/1 X-Deja-AN: 260961517 References: Organization: Hughes Training Inc. Reply-To: smize@link.com Newsgroups: comp.lang.ada,sci.math.num-analysis,comp.software-eng,comp.theory,sci.math Date: 1997-07-31T00:00:00+00:00 List-Id: [reformatted for line length] Matthew Heaney wrote: > > In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > >As for when it makes sense to compare floating-point values > >for equality, that is a matter for the programmer to understand. > >Floating-point arithmetic on modern IEEE machines is not some kind > > of approximate hocus-pocus, it is a well defined arithmetic systenm, > >with well defined, well behaved results, in which equality has a > > perfectly reasonable meaning. > > OK, so if do this > > declare > m1, m2 : slope; > begin > if m1 = m2 then > > and I'm using IEEE floating point types (I'm on a SUN box), can I assume > that the lines are parallel? IEEE float calculation is a well-defined arithmetic system, but it does not always match exact real-number arithmetic. You need to read up in one or more of the references other people provided, to determine how the differences impact your computations. The short answer is that there is no short answer. The longer short answer is that usually, the inaccuracy of the data swamps the imprecision of discrete floating-point arithmetic. If you're measuring lengths under 10 yards to the nearest foot, it really doesn't matter if you compute the rectangular area with 32 or 64 bits. In this case, you might consider 10.01 and 9.09 equal. If you're measuring to the nearest inch, you might not. In neither case are you approaching the precision of the machine. There are cases where the machine precision plays a part. For instance, solution by successive approximation may thrash indefinitely if the value you are hunting is further than your "close enough" criterion from two "adjacent" approximations. You might also find that the computations you are doing introduce a significant level of imprecision due to representation limits, although usually anything that amplifies imprecision also amplifies the inaccuracy of your data. And there are special boundary cases, e.g. trig functions zooming off to infinity. There really is no substitute for some knowledge of numerical analysis, even if self-taught. You have to at least know enough to tell when you are safe, and when you need to be careful. There isn't a set of cookbook directions that will guide you. What makes Ada intimidating in this respect is that the standard tries to make these issues visible and controllable, instead of giving you whatever's on the machine and ignoring the problem. (A language like that wouldn't get a better grade than C.)* Best, Sam Mize * Yes, it was gratuitous. :-)