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: f43e6,c7637cfdf68e766
X-Google-Attributes: gidf43e6,public
X-Google-Thread: 103376,c7637cfdf68e766
X-Google-Attributes: gid103376,public
X-Google-Thread: 109d8a,c7637cfdf68e766
X-Google-Attributes: gid109d8a,public
X-Google-Thread: f8362,c7637cfdf68e766
X-Google-Attributes: gidf8362,public
X-Google-Thread: 107079,c7637cfdf68e766
X-Google-Attributes: gid107079,public
From: user <user@mailgw.sanders.lockheed.com>
Subject: Re: floating point comparison
Date: 1997/08/01
Message-ID: <33E261F7.2EFB@mailgw.sanders.lockheed.com>#1/1
X-Deja-AN: 261525953
References: <mheaney-ya023680002907972345420001@news.ni.net>
 <dewar.870304869@merv> <mheaney-ya023680003007972240570001@news.ni.net>
 <01bc9dca$762b6000$e1e989cc@gort>
Organization: Sanders
Newsgroups: 
 comp.lang.ada,sci.math.num-analysis,comp.software-eng,comp.theory,sci.math
Date: 1997-08-01T00:00:00+00:00
List-Id: <comp.lang.ada>


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.