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

[Peter Ross]

On 07-Jun-1999, Lee Naish <lee at cs.mu.OZ.AU> wrote:
> Peter Ross <petdr at cs.mu.OZ.AU> writes:
> 
> >+% The constraint on the transformation is that the compose goal must
> >+% obey the following law
> >+%      
> >+%	compose(I, B, C, BC), compose(I, A, BC, ABC)
> >+%		<=> compose(I, A, B, AB), compose(I, AB, C, ABC)
> 
> Best add quantifiers: some [BC] (...) <=> some [AB] (...)
> to avoid confusion (see much earlier discussion) and mention
> "associative".
> 
Will do.

> Also worth mentioning which direction the transformation uses (perhaps
> swap sides of the <=> to make it more intuitive?), how the compiler
> knows/can be told the equivalence holds, and what the efficiency
> pitfalls are and how they are avoided (and should be avoided in the
> future).  These things are somewhat subtle so its definitely worth
> putting a decent effort into the high level documentation.
> 
Will do.

> >+	% XXX this fact table is only a temporary solution to whether or
> >+	% not a particular procedure is associative.  In the long term
> >+	% the user should be able to annotate their code to indicate
> >+	% which predicates are associative.
> >+	%
> >+	% The set is simply the set of vars that must be static.  It is
> >+	% a simple heuristic to ensure that the O() behaviour only
> >+	% improves.  ie for append after swapping the arguments the
> >+	% static variable must be in the first location.
> 
> Add more extensive documentation here(?), with example of append going
> wrong?
> 
Will do.

> >+/* 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.

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