Re: floating point comparison

["Bob Binder (remove .mapson to email)" <rbinder@rbsc.mapson.com>]

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.


-- 
______________________________________________________________________________ 
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