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: 109d8a,c7637cfdf68e766 X-Google-Attributes: gid109d8a,public X-Google-Thread: 103376,c7637cfdf68e766 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,c7637cfdf68e766 X-Google-Attributes: gidf43e6,public X-Google-Thread: 107079,c7637cfdf68e766 X-Google-Attributes: gid107079,public X-Google-Thread: f8362,c7637cfdf68e766 X-Google-Attributes: gidf8362,public From: Lynn Killingbeck Subject: Re: floating point comparison Date: 1997/08/02 Message-ID: <33E3ED97.4A56@phoenix.net>#1/1 X-Deja-AN: 261851943 References: <01bc9dca$762b6000$e1e989cc@gort> <33E261F7.2EFB@mailgw.sanders.lockheed.com> Organization: Re-Tired Reply-To: killbeck@phoenix.net Newsgroups: comp.lang.ada,sci.math.num-analysis,comp.software-eng,comp.theory,sci.math Date: 1997-08-02T00:00:00+00:00 List-Id: 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