Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uunet!brunix!mj
From: mj@brunix (Mark Johnson)
Newsgroups: comp.lang.prolog
Subject: Re: Floating Point
Message-ID: <19228@brunix.UUCP>
Date: 29 Oct 89 16:52:50 GMT
References: <2491@munnari.oz.au> <36169@srcsip.UUCP> <2524@munnari.oz.au> <19165@brunix.UUCP> <2565@munnari.oz.au>
Sender: news@brunix.UUCP
Reply-To: mj@monaco.UUCP (Mark Johnson)
Organization: Brown University Department of Computer Science
Lines: 55


In reply to ok@cs.mu.oz.au (Richard O'Keefe):

First, I agree with Richard's main point: if a programming language
claims to provide IEEE 754 floating point arithmetic (or whatever)
then it should implement that standard and not something else: i.e.
fuzzy equality or interval arithmetic or whatever should be used only
if it satisfies the standard.

> It is simply a MISTAKE to think of floating-point numbers as
> denoting real numbers.  It is indeed the case that
>         1.0 + scalb(1.0, -60) =:= 1.0
> must be true in IEEE 754 arithmetic and must be false in the reals, but
> all this tells us is that floating-point arithmetic is not the same
> algebra as real arithmetic, which we already knew.

But just because this is the way it is in IEEE 754 doesn't mean that
this is the way it should be in Prolog.  Maybe floats aren't the most
appropriate approximation to real numbers in a logic-programming 
(inspired) language?

I found Richard's response to my point about the incompleteness of
floating-point arithemtic (when expressions are interpreted in the
reals) a little confusing: I thought that the only reason why floating
point numbers are used is because they are an approximation to the
reals.  Isn't the question really just what properties of the reals
we want our approximation to capture, and whether completeness is one of
these properties?

About interval arithmetic as an approximation to real arithmetic,
he says:

> If you consider an interval as a pair of constraints on a real number,
> interval arithmetic is sound but not complete.  Amongst other things,
> if we assume that multiplication and division by powers of 16 are
> exact (which they are in VAX, IEEE, and IBM arithmetic), then
>         (X * 16.0) / 16.0
> will yield X exactly, but interval arithmetic will regard the 16.0s as
> imprecise and will return a wider interval than the X interval it started with.

Nevertheless, in such a system  X =:= (X * 16.0) / 16.0, since the intervals
on either side of the =:= have a non-empty intersection, so I think my
original claim about the completeness of interval arithmetic still stands.

By the way, I didn't claim that interval arithmetic is sound: as far as
I can see it is unsound for the same reason that floating point arithmetic
is an unsound approximation to real arithmetic: round-off errors will
make expressions like 1.0 + scalb(1.0, -60) =:= 1.0 true in both interval
and floating point arithmetic, even though it is false in real arithmetic.

Of course, there are other problems with interval arithmetic: for example,
if X is the interval [-0.5, 0.5], then what interval should 1/X be?
Similar problems arise for the trig functions.

Mark