From ok@atlas.otago.ac.nz  Mon May  8 05:00:02 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 FAA20878;
	Mon, 8 May 2000 05:00:00 +0200 (MET DST)
Received: (from ok@localhost)
	by atlas.otago.ac.nz (8.9.3/8.9.3) id PAA22493;
	Mon, 8 May 2000 15:00:06 +1200 (NZST)
Date: Mon, 8 May 2000 15:00:06 +1200 (NZST)
From: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
Message-Id: <200005080300.PAA22493@atlas.otago.ac.nz>
To: jan@swi.psy.uva.nl, ok@atlas.otago.ac.nz, prolog@swi.psy.uva.nl,
        timm@csee.wvu.edu
Subject: Re:  handling small numbers

	> First, exact rational calculations tend to give you large
	> numerators and denominators, and SWI Prolog arithmetic is,
	> um, a bit unpleasant there.
	> 	?- X is 1000*1000*1000*1000.
	> 	X = 1e+12 		% why isn't it 1000000000000?
	> 	Yes			% maybe that's how bignums print??
	> 	?- X is 1000*1000*1000*1000, integer(X).
	> 	No			% nope, it realy did float it.
	> So if you calculate your numerators and denominators _directly_,
	> SWI Prolog is going to screw you with floating point arithmetic
	> anyway.
	
	SWI-Prolog its are 32-bits, so X is 1000*1000*1000*1000 has a problem.
	There are two solutions: raise an exception or promote to a float (=
	C double).

No, there are three solutions:
 - raise an overflow exception (if you can't give the right answer,
   you should never give a wrong one)

 - give the wrong answer (floating point numbers do not obey the same
   axioms as integers; they are a _different_ and in many ways
   _incompatible_ algebra)

 - give the right answer, using multiple precision arithmetic.
   This is what Lisp and Smalltalk do, and its what I always wanted Quintus
   to do except somehow it never got scheduled (but I _did_ get some of the
   necessary infrastructure in there the year before I left).  Heck, it's
   even what Erlang does, and Erlang is a language for telecoms
   applications!

This was spelled out in my 1984	Edinburgh paper, which was given the
number BS/6 in the catalogue of papers for the development of the standard.
In the closing year of the 20th century, there is no longer any good reason
for non-machine-oriented programming languages to give incorrect answers
to integer calculations.

	I've choosen for the latter for `convience'.

Giving wrong answers is convenient for implementors.
In the long run, it is convenient for no-one else.
	
In this particular case, there is plenty of free source code for
bignums around.  There's the stuff I've used for years in C, taken
from Elk; there's stuff from DEC; there's stuff from the GNU library;
and there's stuff in Squeak (there's a new implementation of LongInteger,
which is supposed to be faster than the old code; I think it's in 2.8a).

