Re: floating point comparison

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

Matthew Heaney <mheaney@ni.net> wrote in article
<mheaney-ya023680003007972240570001@news.ni.net>...
> In article <dewar.870304869@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> 
> 
> >As for when it makes sense to compare floating-point values for equality,
> >that is a matter for the programmer to understand. Floating-point arithmetic
> >on modern IEEE machines is not some kind of approximate hocus-pocus, it
> >is a well defined arithmetic systenm, with well defined, well behaved
> >results, in which equality has a perfectly reasonable meaning.
> 
> OK, so if  do this
> 
> declare
>    m1, m2 : slope;
> begin
>    if m1 = m2 then
> 
> and I'm using IEEE floating point types (I'm on a SUN box), can I assume
> that the lines are parallel?

Assuming = is the equality operator (not assignment), and something 
has placed *exactly* equal values in m1 and m2 before the compare, 
then they'll compare equal.

But this isn't the source of the problem. 

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
};

E.g., with a hexadecimal fraction representation, there is no exact 
representation for 0.1, just at there is no exact decimal 
representation of 1/3.  In all the Fortans I used, the above hack 
would show this.  Unless your compiler designers have compensated
for this, the above (or another suitably choosen constant) will 
demonstrate this mismatch.


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