Subject: Re: handling small numbers

From: Jan Wielemaker <[email-masked]>
Date: Mon, 8 May 2000 09:45:58 +0200

On Mon, 08 May 2000, Richard A. O'Keefe wrote:

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

But also for many purposes `similar enough'.  This holds in particular
for engineering applications (which happens to be my background :-). 
It also holds for many of the things we do around here with Prolog
related to graphics (except for using numbers as bit-vectors).

I do agree raising an exception should at least be an option.

> - 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 agree to that.  I only never got around doing it.  There never has
been demand for it where I work, nobody came along with a bag of money
and nobody who just added it.

Closest is the work on the GNU mp-library interface by Robert van
Engelen.  This work uses the SWI-Prolog string objects to store mp
numbers.  The only trouble is that it is not integrated into standard
Prolog arithmetic.  This wouldn't be really hard I think, but certainly
more than a couple of days.

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

It's not (for the implementors).  The infra-structure for raising
exceptions from arithmetic is there anyway and the checks for overflow
too.  It is certainly not less work to convert the result silently to
floats.

	Regards --- Jan