On Fri, 24 Oct 1997, S.D.Mechveliani wrote:
> For example, x^(2^n) --> x^0, if 2^n > maximal_Int.
>
> For the algebra, it would be better to
> *break in such case with the overflow message*.
I'm not sure that people who want to write `production systems' (i.e.,
ones that will be run when the original author is no longer around to
figure out what went wrong for bad input and how it can be fixed) would
agree. Surely the best idea is to do something equivalent to the IEEE
floating point standard which defines certain returned bit patterns to
mean `over/underflow occurred', etc. The programmer can then handle this
either
in the simple way of calling error, or try to carry on in some suitable
way. In a similar way there could be a tainted bit pattern for
overflow, perhaps with testing functions built into the prelude. This
would be even more useful since tainted bit-patterns in further
calculations are defined to produce a tainted bit-pattern result, so
overflow needn't be explicitly tested for each atomic operation.
> With this, the researcher runs the faster program and does not
> risk to get the incorrect result.
That sounds close to trying to have it both ways: Int's are
a (usefully large) approximation to Integers (or the mathematical
integers) which can be implemented quickly precisely because they are
bounded. The price you pay is that operations like +, *, etc become
partial functions, and consequently your function definitions must take
account of this.
david
------------------------------------------------------------------------
rm 2.01, Merchant Venturers Bldg APOLOGY
http://www.cs.bris.ac.uk/~tweed/ IS
work tel: (0117) 9545104 POLICY
