Re: floating point comparison

["Charles R. Lyttle" <lyttlec@flash.net>]

Bob Binder  wrote:
> 
> Lynn Killingbeck <killbeck@phoenix.net> 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.