[m-dev.] Re: for review: accumulator introduction

Fergus Henderson fjh at cs.mu.OZ.AU
Thu Jun 10 22:17:25 AEST 1999


On 10-Jun-1999, Peter Ross <petdr at cs.mu.OZ.AU> wrote:
> On 07-Jun-1999, Lee Naish <lee at cs.mu.OZ.AU> wrote:
> > Peter Ross <petdr at cs.mu.OZ.AU> writes:
> > >+/* XXX introducing accumulators for floating point numbers can be bad.
> > 
> > Best mention the reason: the operations are typically *not* associative.
> > There should be some way to locally prevent the order of floating point
> > operations being changed by the compiler.
> > 
> As Fergus said, this should be a language semantics option.
> It would also be nice to control its application on a predicate by
> predicate basis.
> 
> > For that matter, the same applies to ints (because of overflow).  This
> > should at least be XXX documented.
> > 
> This will not be a problem for this transformation because overflow will
> happen no matter what order things are processed.

That's not entirely correct.  For example, consider the following code:

	bigint = X :- int__max_int(X).

	example = -bigint + bigint + bigint.

If this sum is evaluated left-to-right, then there will be no overflow.
If on the other hand the sum is evaluated right-to-left

	example = -bigint + (bigint + bigint).

then the intermediate result (bigint + bigint) will overflow.

However, if the system uses modulo arithmetic, then the end result will
be the same, despite the intermediate result overflowing.
That is, integer addition modulo 2^N is associative, but integer addition
with bounds checking is not.

So treating integer arithmetic as associative is OK given the current
implementation.  But the documentation for the `int' library module
does not say how overflow is treated, and I think it would be quite
reasonable for an implementation to check for overflow.
(Probably we ought to eventually have two different types, one of which
checks for overflow and one of which uses modulo arithmetic.  The
question then is which one gets called `int'.  I think it should be
the one that checks for overflow.)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list