Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: Arithmetic problems with Quintus Prolog
Message-ID: <880@cresswell.quintus.UUCP>
Date: 16 Apr 88 01:49:06 GMT
References: <873@cresswell.quintus.UUCP> <#a?GP4|0@sea.sm.unisys.com>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 60

In article <#a?GP4|0@sea.sm.unisys.com>, eggert@sea.sm.unisys.com (Paul Eggert) writes:
> In article <873@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe)
> argues that a Prolog implementation cannot obey the IEEE floating point
> standard while following the proposed rule "If a number can be exactly
> represented in both floating point and integer formats, then use integer
> format."  His argument has one crucial flaw that invalidates its conclusion.
> O'Keefe writes:
> 
> 	(5) For any integer N for which all expressions are defined, if
> 		ZI is N-N,
> 		NF is float(N),
> 		ZF is NF-NF
> 	    then ZF is distinguishable from -ZF by IEEE rules, but ZI is not
> 	    distinguishable from -ZI.
> 
> Not so.  Under the proposed rule, "N is -0" unifies N with -0.0, not with 0,
> so ZI can be distinguished from -ZI.

I'm afraid Paul Eggert has found an error that isn't there.
Let me trace through what happens in slow and painful steps.

	N is (stored as) an integer.
	ZI is N-N yields an INTEGER 0.
According to the rules of INTEGER arithmetic,	
	-ZI and ZI should thus be identical.
If ZI and -ZI are distinguishable, then the system in question is getting
its INTEGER arithmetic seriously wrong.

It turns out that there WAS an unstated assumption in my article.
I assumed that the goal was to get BOTH integer arithmetic AND floating
point arithmetic right.  Apparently, Eggert wants floating-point
arithmetic to be got right, with integers merely being an optimised way
of storing some floating-point numbers.  If that's what he wants, then
his proposed rule is indeed a consistent way of achieving it.

My "proof" that
	if you want arithmetic operations on integers to yield results
	consistent with the mathematical laws of integer arithmetic

	and you want arithmetic operations on floating point numbers
	to be allowed to be consistent with the IEEE 754 standard

	then you must make a rigid distinction between integers and
	floating point numbers
stands intact.

I find the attempt to confuse integers with floats extremely confusing
from an "intuition" point of view, because integers and floats MEAN
very different things.  Yes, the mathematical integers are (isomorphic to)
a subring of the field of real mathematical numbers, so that the integer
1 may safely be identified with the REAL number 1.  But the floating point
number 1.0 is not identical to the real number 1, does not represent it,
and does not share many of its properties.  Consider the fact that on an
IBM 370 (or any other machine whose floating point arithmetic doesn't use
base 2), there are positive floating-pointer numbers X < Y such that
(X+Y)/2 does not lie in the closed interval [X,Y].  This violates a basic
axiom of real arithmetic.  (This kind of bizarre behaviour is why I think
ALS Prolog is right to use the predicate float(X) to recognise floating-
point numbers, and BSI Prolog is wrong to use real(X).  To call floats
"reals" is to lie.)