Subject: Re: handling small numbers

From: "Richard A. O'Keefe" <[email-masked]>
Date: Tue, 9 May 2000 16:45:05 +1200 (NZST)

"Dick" wrote about bounded arithmetic that
	
	I'm probably way out of line here but it suddenly stuck me
	that this is rather like the closed world assumption written into
	the implementation rather than the data base:

I don't see the analogy myself.  The closed world assumption is basically
"anything I don't KNOW isn't TRUE".  It's about clauses.
The bounded arithmetic kluge says "what I can't REPRESENT doesn't
EXIST anywhere".  It's about terms.

The fundamental point is that if you mess with the semantics of integers,
all hell is let loose (just as it is in C).  Over in comp.std.c they had
a pet saying for use when you strayed into undefined territory: "the
compiler can make demons fly out of your nose."

	I personally regret that we can't switch arithemetics and keep
	the same notation, finite, infinite, modulo N ... I've been wanting
	ways to program in some of the stranger ones for a long time.
	
But we *can* switch arithmetics and keep essentially the same notation.
It would be a serious mistake to switch arithmetic globally, because even
if you are adding up the elements of a vector modulo 17, you may have rather
more elements than 17 in the vector.  An arithmetic expression is just a
term, and a goal can be represented by a term.  So all it takes is

	unsigned(( I is 2147483647, J is I + 1 ))

to do one thing, and

	modulo(17, ( I is 2147483647, J is I + 1 ))

to do another, and so on.  There's precedent:  that's exactly what the
LONG.PL package in DEC-10 Prolog did.  From the header comment:

    Rational numbers are produced by using the predicates

                    eval(Command)

                    eval(Expression, Answer)

The commands included is/2, even/1, odd/1, compare/3, the usual arithmetic
comparisons, and write/1.  A revision done since I left Quintus added
whole/1 and finite/1, also callable directly.

In testing whether long.pl worked under SWI Prolog, I ran into the
problem that put/1, which is *supposed* to evaluate its argument in
Edinburgh-compatible Prologs, completely fails to do so!  Imagine
my surprise when put("0") raised an exception!  That should be fixed.