[m-dev.] Re: diff: test cases for accumulator introduction.

Peter Ross petdr at cs.mu.OZ.AU
Mon Jun 21 14:49:37 AEST 1999


On 18-Jun-1999, Lee Naish <lee at cs.mu.OZ.AU> wrote:
> Peter Ross <petdr at cs.mu.OZ.AU> writes:
> 
> >+p([], L, L).
> >+p([H|T], _, L) :-
> >+	p(T, H, L0),
> >+	L is L0 + 1.
> 
> This example (and some other similar simple ones) is lacking comments.

These cases have comments at the top of the files which explain what the
test case is.

I put comments above each individual predicate only if there was more
then one in the module.

> Also at least one example with multiplication (and any other known
> associative operations) would be nice.
> 
> I suggest an example or two illustrating rounding/overflow potential
> problems also.  Eg, summing [1, maxint, -maxint] and (something like)
> [0.000000001, 0.000000001, 0.000000001,..., 1.0].  For the integer example
> I think its fair enough to say the "correct" answer is 1 (rather than
> overflow - assumes mod arithmetic).  The floating point case is more
> tricky, figuring out what the precision should be and what the correct
> answer is.  One possibility would be to include a commented out test
> case which could be used/adapted once the desired semantics is sorted
> out.  It might also be possible to use the floating point case to test
> if accumulators really are being introduced (so correct introduction of
> accumulators is not invisible wrt computed answers).
> 
I will look into this.

> 
> 
> >+	% We have two calls to append with dynamic variables in them
>                                ^^^^^^
> >+	% that don't require rearrangement.  Hence we CAN introduce
> >+	% accumulator recursion.
> >+	%
> >+:- pred pc(list(int)::in, int::out) is det.
> >+
> >+pc([], 0).
> >+pc(X, Y) :-
> >+	X = [H | T],
> >+	pc(T, Y0),
> >+	Tmp is Y0 + (2*H),
> >+	Y is Tmp + H.
> 
> Looks like you copied but forgot to change the comment.
> 
Thanks.

> >+	% We CANNOT introduce accumulators because the chain of calls
> >+	% are to different predicates.
> >+	%
> >+:- pred pd(list(int)::in, int::out) is det.
> >+
> >+pd([], 0).
> >+pd(X, Y) :-
> >+	X = [H | T],
> >+	pd(T, Y0),
> >+	Tmp is 2*Y0,
> >+	Y is Tmp + H.
> 
> Clarify the two preds are times and plus (rather than is/2 and is/2)?
> 
> >+	% Highoder functions cannot use accumulator recursion because we
> >+	% don't know anything about the assocativity of P.
> 
> The typo is a bit on the nose:-)
> 
> Also, depending on the relative order of accumulator introduction and
> inlining + specialisation of higher order calls, this may be incorrect.
> I suggest a test case where highorder__foldr is called with a pred which
> is definitely known to be associative (ie, not your minus/3) so that if
> things are appropriately specialised before accumulator introduction
> then an accumulator will be introduced (I don't know what order things
> are currently done in the compiler but whatever it is it might change
> and potentially break things).
> 
Good idea.

> >+	{ highorder__foldr(minus, [1,10,100], 0, ListA) },
> >+	io__write(ListA),
> >+	io__nl.
> >+	
> >+:- pred minus(int::in, int::in, int::out) is det.
> >+ 
> >+minus(A, B, C) :-
> >+	C is A - B.
> 
> 
> 
> >+	% This is an interleaved version of reverse and length.
> >+	% Tests if we can introduce more then one accumulator.
> 
> Nice one.  How about another where a potential acc pred calls another
> potential acc pred?  Does this test anything useful?  Maybe not.
> 
It should make no difference since the head of the
predicate never changes, just the body.

> 
> Finally(?), how about some cases with functions (or combinations of
> functions and predicates).
> 
Yes I should do that.  To keep things simple my test cases were all
valid prolog code as well.

Thanks for the comments,
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
--------------------------------------------------------------------------



More information about the developers mailing list