From ok@atlas.otago.ac.nz  Tue May  9 03:43:13 2000
Received: from atlas.otago.ac.nz (atlas.otago.ac.nz [139.80.32.250])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id DAA24230;
	Tue, 9 May 2000 03:43:11 +0200 (MET DST)
Received: (from ok@localhost)
	by atlas.otago.ac.nz (8.9.3/8.9.3) id NAA28932;
	Tue, 9 May 2000 13:43:18 +1200 (NZST)
Date: Tue, 9 May 2000 13:43:18 +1200 (NZST)
From: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
Message-Id: <200005090143.NAA28932@atlas.otago.ac.nz>
To: jan@swi.psy.uva.nl, paul@inet.co.za
Subject: Re: handling small numbers
Cc: ok@atlas.otago.ac.nz, prolog@swi.psy.uva.nl, timm@csee.wvu.edu

Paul Sephton <paul@inet.co.za> wrote:
	How about simply using the languages inherent properties, and simply 
	failing the goal?  After all, if the programmer knows that the integer 
	representation has a maximum of 32 bits and happens to produce a larger 
	number, that is what I would like to expect.
	
I discussed this in some detail in my 1984 Edinburgh paper.
The point is that it is a *WRONG* answer.
The key idea is Dijkstra's notion that we write a program for
a "Sufficiently Large" abstract machine.
We don't _have_ Sufficiently Large real machines.
What we _can_ have is "Hopefully Sufficiently Large" machines
which either give us the right answer or *tell* us they couldn't
give us the right answer.

Now, if I write in a Prolog program

	(I = 2147483647, J is I + 1)

then the answer "no" is *WRONG*; there really truly *does* exist a
solution to that query.  It is just that there is a defect in the
implementation such that the implementation cannot represent the
correct answer.  In my exception handling design for Quintus, I
classified exceptions into 16 categories; this one I called a
"representation fault", and there are lots more of them.

If you want to work with machine integers, then by all means have a
set of machine integer operations.  If you want to write

	(I = 2147483647, J is plus32(I,1))

then the best of luck to you, and you get to define the semantics of
plus32.

	Silently promoting to a float has a lot of advantages-

except the advantage of giving you correct answers.  In the context
of this specific thread, it has the very nasty disadvantage of
*quietly* reintroducing the very roundoff problems that the use of
integer arithmetic was supposed to avoid.

By the way, there is nothing whatsoever wrong with a Prolog system
offering 53-bit integer arithmetic implemented internally using
IEEE floating point.  Addition, subtraction, multiplication, and
even division (thanks to fmod() and some awkward code) can be done
on _exact_ integers using IEEE floating point arithmetic.
But that's not the same as exposing floating-point properties such
as round-off into calculations that should be free of them.
If I want Basic, I know where to find it.

	Likewise, exceptions generated by overflows/underflows ( or anything else 
	for that matter) can be a real pain in the neck, and as I have pointed 
	out, the language can manage quite well without this:
	
Yes, but programmers can't.
"Your query doesn't HAVE any answer"
and
"Your query may have an answer but I'm too limited to find it"
are different statements demanding different responses from the programmer.

Note that IEEE arithmetic defines floating-point overflow away, so

	go(X) :-
	  X is VeryBigNumber1 * VeryBigNumber2.
	go(_) :-
	  writef('Sorry- cannot seem to get the answer\n').
	
WOULD NOT WORK AS INTENDED in an IEEE-using Prolog.  You would have to
write
	go(X) :-
	    Y is VeryBigNumber1 * VeryBigNumber2,
	    (   finite(Y) -> X = Y
	    ;   write('Sorry:  answer is not representable.'), nl
	    ).

	Dash it all- program flow in prolog is based on exceptions!

No, it isn't.  Exceptions are *non-local* transfers of control;
backtracking in Prolog is entirely local.

