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: 103376,c7637cfdf68e766 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,c7637cfdf68e766 X-Google-Attributes: gidf43e6,public X-Google-Thread: f8362,c7637cfdf68e766 X-Google-Attributes: gidf8362,public X-Google-Thread: 109d8a,c7637cfdf68e766 X-Google-Attributes: gid109d8a,public From: "Bob Binder (remove .mapson to email)" Subject: Re: floating point comparison Date: 1997/08/03 Message-ID: <01bca019$5218b9f0$e1e989cc@gort>#1/1 X-Deja-AN: 261973992 Distribution: inet References: <01bc9dca$762b6000$e1e989cc@gort> <33E261F7.2EFB@mailgw.sanders.lockheed.com> <33E3ED97.4A56@phoenix.net> Organization: RBSC Corporation Newsgroups: comp.lang.ada,sci.math.num-analysis,comp.software-eng,comp.theory,sci.math Date: 1997-08-03T00:00:00+00:00 List-Id: Lynn Killingbeck wrote in article <33E3ED97.4A56@phoenix.net>... > user wrote: > > > > Bob Binder wrote: > > > > > 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 > > > }; > > Although I am reading this in comp.lang.ada, the suggestion to try a > > simple example like this in C piqued my interest. > > > > On a Sun SPARC-5, with the built in compiler supplied by Sun, this > > code (fixed for syntax) found (x == y) to be true. Using 3.0 and > > 7.0 (neither of which have any chance of yielding an exact > > representation > > after the division) also found (x == y) to be true. > > > > The underlying machine arithmetic escapes me, but a simple mechanism > > such as retaining more precision in computation results, and rounding > > prior to comparison to some lesser degree of precision that still meets > > the spec, would work. Cheap calculators do this all the time, using > > something known as "guard digits," which retain precision that is not > > displayed in the (rounded) result. > > I did something like this a few years back, to show someone the problem > - and was very surprised when the results was equal, even though > (x/10.0) has no exact representation on a binary-based computer. Then I > looked at the generated code - and the COMPILER had optimised away all > the operations and just set x=y=1.0. There weren't any computations. I > think it was in someone's C (either Borland or Microsoft), but it's too > far back to remember the language/compiler details. > > Lynn Killingbeck > Interesting -- things have improved some from the stone age tools I used. I guess its a good thing that the simpler pitfalls are prevented -- but you'd have to look at the generated code to see just what is done by a particular compiler. The mismatch still lurks. The only way to deal with is to apply know good numerical design technique with a clear understanding of the quirks and limitations of particular compiler. Ironically, as compilers become better, these quirks become more obscure, and can promote overconfidence. -- ______________________________________________________________________________ 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