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=3.8 required=5.0 tests=BAYES_00,INVALID_MSGID, RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 107079,c7637cfdf68e766 X-Google-Attributes: gid107079,public X-Google-Thread: f43e6,c7637cfdf68e766 X-Google-Attributes: gidf43e6,public X-Google-Thread: 109d8a,c7637cfdf68e766 X-Google-Attributes: gid109d8a,public X-Google-Thread: 103376,c7637cfdf68e766 X-Google-Attributes: gid103376,public X-Google-Thread: f8362,c7637cfdf68e766 X-Google-Attributes: gidf8362,public From: "Bob Binder (remove .mapson to email)" Subject: Re: floating point comparison Date: 1997/07/31 Message-ID: <01bc9dca$762b6000$e1e989cc@gort>#1/1 X-Deja-AN: 260945863 Distribution: inet References: Organization: RBSC Corporation 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: Matthew Heaney wrote in article ... > 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? Assuming = is the equality operator (not assignment), and something has placed *exactly* equal values in m1 and m2 before the compare, then they'll compare equal. But this isn't the source of the problem. I haven't followed the IEEE fp standard, but I can't imagine how (without resorting to some kind of BCD representation) any floating point scheme using a non-decimal radix gets around the fundamental fact that there are non-terminal fractions in this radix which are not non-terminal in a decimal radix. Try this: x, y float; x = 1.0; y = (x/10.0)*10.0; if x == y { // not likely } else { // more likely }; E.g., with a hexadecimal fraction representation, there is no exact representation for 0.1, just at there is no exact decimal representation of 1/3. In all the Fortans I used, the above hack would show this. Unless your compiler designers have compensated for this, the above (or another suitably choosen constant) will demonstrate this mismatch. -- ______________________________________________________________________________ Bob Binder http://www.rbsc.com RBSC Corporation 312 214-3280 tel Software Engineering 3 First National Plaza 312 214-3110 fax Process Improvement Suite 1400 rbinder@rbsc.mapson.com (remove .mapson to mail) Chicago, IL 60602-4205