Re: floating point comparison

[Lynn Killingbeck <killbeck@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