andrewt@cluster.cs.su.oz (Andrew Taylor) (05/08/90)
Some (most?) Prolog implementations do not check for overflow on (integer) arithemtic. This doesn't seem acceptable to me. I'm interested to know why this is. Is it laziness? Is it deliberate? Is it inherited from the implementation languages (often C)? Does it worry anyone else?
pgl@cup.portal.com (Peter G Ludemann) (05/09/90)
I would assume that not checking for arithmetic overflow is part of a misguided attempt to be "efficient". Getting a wrong answer in half the time does not impress me, but evidently it does impress some people, especially in a "Very High Level Language". C, of course, is a primary offender; some C implementations do not make detecting integer overflow easy. It would be interesting to find out which Prologs support arithmetic overflow detection and whether the ISO standard intends to insist on checking for overflow. By-the-way, IBM-Prolog checks for overflow even though it's unlikely (rational numbers that fit into 2**24 bytes are supported). Any other Prologs which support overflow detection and/or big numbers? - Peter Ludemann --- standard disclaimer ---
ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) (05/09/90)
In article <870@cluster.cs.su.oz>, andrewt@cluster.cs.su.oz (Andrew Taylor) writes: > Some (most?) Prolog implementations do not check for overflow on > (integer) arithmetic. Some Prolog systems (for example LPA) _do_ check for overflow, and then deliver the result as a floating-point number. IMEO (like IMHO except E=educated) this kind of *wrong* answer is just as bad as the other kind, but some people like it. I'd like to put in a kind word for ZYX Prolog; those fine people have provided arbitrary precision integers (just like Common Lisp, which ZYX Prolog has been very strongly influenced by). Instead of giving you a wrong answer or apologising for not being able to give a right answer, ZYX Prolog gives you the right answer. Nice. > This doesn't seem acceptable to me. > Does it worry anyone else? I don't find it acceptable either, and yes I'm worried by it. (I am also very worried indeed by C...) > I'm interested to know why this is. Is it laziness? > Is it inherited from the implementation languages (often C)? Well, Xerox Quintus Prolog provides arbitrary precision integers. They came free with the implementation language (Lisp). If you are trying to produce a reasonably portable system (like SB Prolog) it is rather tricky to detect or handle integer overflow in a portable way. For example, because the C standard permits an implementation to signal exceptions for overflow in signed arithmetic, all your operations have to be done with unsigned arithmetic. Instead of writing X = Y + Z; in your C code, you have to write unsigned long lY = Y, lZ = Z; unsigned long lX = lY+lZ; if (Y >= 0 ? Z >= 0 && (long)lX < 0 : Z < 0 && (long)lX >= 0) /* the answer has the wrong sign */ signal_overflow_in_plus(); else X = (long)lX; You really don't want to see what multiplication looks like. The result can't honestly be called fast. The way to get fast safe integer arithmetic is to rely on hardware generated overflow signals (either a flag in the PSW or a trap), but you can't get at that information *portably* in C. And of course if you are stealing tag bits out of the number, things get worse. If you steal bits from the top of a word, you have to do unsigned long lY = Y << N_TAG_BITS; unsigned long lZ = Z << N_TAG_BITS; ... else X = (lX >> N_TAG_BITS) | INT_TAG; If you steal bits from the bottom of a word, it's easier: unsigned long lX = (lY-INT_TAG) + lZ; If you want to make a *fast* Prolog implementation, you have fun till it hurts hacking assembly code on lots of machines, and until you actually try it, you wouldn't believe how different the ways of detecting overflow are on some machines and how hard some architects have made it. Speed, the difficulty of doing it, and the tradition that it is ok for computer programming languages to do arithmetic wrong, all play a part.
sfk@otter.hpl.hp.com (Steve Knight) (05/10/90)
Andrew Taylor writes: > Some (most?) Prolog implementations do not check for overflow on > (integer) arithemtic. This doesn't seem acceptable to me. I agree that it is unacceptable for an implementation to silently perform incorrectly. Even given Richard O'Keefe's comments on the difficulties of doing it, I would have expected the ability to turn on arithmetic-checking at the very least. Perhaps I am missing something .... ? There are a couple of Prologs that avoid this problem by providing arbitrary precision arithmetic. As an example, Poplog Prolog offers the Common Lisp model of arithmetic, which includes big integers, rationals, single and double precision floats, and complex numbers -- together with the usual mathematical functions (e.g. sin, cos, arcsin, sqrt, exp, log, ... ). Steve