Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!wuarchive!wugate!uunet!brunix!mj
From: mj@brunix (Mark Johnson)
Newsgroups: comp.lang.prolog
Subject: Re: Floating Point
Message-ID: <19272@brunix.UUCP>
Date: 30 Oct 89 15:18:57 GMT
References: <2491@munnari.oz.au> <36169@srcsip.UUCP> <2524@munnari.oz.au> <19228@brunix.UUCP> <2583@munnari.oz.au>
Sender: news@brunix.UUCP
Reply-To: mj@monaco.UUCP (Mark Johnson)
Organization: Brown University Department of Computer Science
Lines: 32

Re: the discussion ok@cs.mu.oz.au (Richard O'Keefe) are having:

Of course in general Prolog should be what Prolog users want it to
be, so I have to agree with Richard's point that if

> customers are demanding floats, and what they want is floats that are the
> same as floats or doubles in C or Fortran or Pascal or Lisp.  

then probably Prolog should have floats.

On the other hand, I don't think that "customer demand" should be the
sole determinant of language design.  For example, even if "customer
demand" called for destructive assignment in Prolog I don't think
that that would convince me to support its inclusion in the language.

About soundness and completeness, Richard writes:

> I would *much* rather have soundness than completeness!

But as far as I can see, neither floating point nor interval arithmetic
can offer soundness when interpreted over the reals because of 
truncation error, as Richard himself pointed out, e.g.

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

So Richard's point about "loosing soundness" by allowing I1 =:= I2 to be true 
whenever I1 and I2 have a non-null intersection is a little misleading:
we never had it in the first place.

Mark