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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: f43e6,c7637cfdf68e766 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,c7637cfdf68e766 X-Google-Attributes: gid103376,public X-Google-Thread: 107079,c7637cfdf68e766 X-Google-Attributes: gid107079,public X-Google-Thread: f8362,c7637cfdf68e766 X-Google-Attributes: gidf8362,public From: "Charles R. Lyttle" Subject: Re: floating point comparison Date: 1997/08/03 Message-ID: <33E4CA33.2E09AA09@flash.net>#1/1 X-Deja-AN: 262322427 Distribution: inet References: <01bc9dca$762b6000$e1e989cc@gort> <33E261F7.2EFB@mailgw.sanders.lockheed.com> <33E3ED97.4A56@phoenix.net> <01bca019$5218b9f0$e1e989cc@gort> Organization: Flashnet Communications, http://www.flash.net 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: Bob Binder wrote: > > 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. > > -- > The moral is don't rely on the compiler, but on proper program design. As soon as you lear the quirks of one compiler, a new release will be adopted that has a new set of quirks. Ada has all the tools to do it right. Anyone for writing "Numerical Recipes in Ada"? A good on-line GPL package would be very valuable.