# [Maxima] Re: sum evals first argument inconsistently

Martin RUBEY rubey@labri.fr
Tue, 20 May 2003 16:01:26 +0200 (CEST)

```Summary: I like the evaluation rules of integrate better than those of
sum, and I certainly want to have them consistent. I believe that
integrate simply evaluates all its arguments before proceeding.

Dear Stavros and all the others interested in evaluation rules:

This reminds me a lot of our old discussion on evaluation rules...
http://www.ma.utexas.edu/pipermail/maxima/2002/003101.html
http://www.ma.utexas.edu/pipermail/maxima/2002/003107.html
http://www.ma.utexas.edu/pipermail/maxima/2002/003108.html
and some other things in the same thread

Consider the following:

(C3) [sum(2^x,x,0,3),sum(2^x,x,0,inf)],x:3;
(D3) [15,'SUM(2^x,x,0,INF)]

seems consistent to me.

(C4) [sum(z,z,0,3),sum(z,z,0,inf)],z:y^k;
(D4) [6,'SUM(z,z,0,INF)]

OK.

(C5) [sum(z,k,0,3),sum(z,k,0,inf)],z:y^k;
(D5) [4*y^k,'SUM(y^k,k,0,INF)]

With your proposal, this would become
(D5') [1+y+y^2+y^3,...]

But is D4 and D5' consistent? To me, D3 and D4 suggest that the first arg
is *not* evaluated, however, in this case I'd rather expect sum(z,k,0,inf)
to give INF.

After some more testing, it seems that - at the moment - the first
argument is evaluated only *after* simplification of the sum took place!
Probably we want to change this.

So what I'm saying is that not sum(z,k,0,3),z:y^k is inconsistent with the
rest of sum but rather sum(z,k,0,inf),z:y^k.

I find it interesting that integrate behaves differently with respect to
the second arg also - maybe this behaviour is not so bad, because it makes
it clearer what's happening:

(C6) integrate(x,x,0,5),x:1;

Variable of integration not a variable: 1

(C7) integrate(z,z,0,3),z:y^k;

Improper variable of integration: y^k

(C8) (x:2,integrate('x,'x,0,2));

(D8) 2
(C9) (x:2,integrate(x,'x,0,2));

(D9) 4

What I didn't expect, though:

(C10) integrate(x,'x,0,2),x:2;
Variable of integration not a variable: 2

Apart of the error resulting from (C10), this makes situations as (C3) and
(C4) impossible. Am I right that integrate simply evaluates all arguments
before doing anything else? (tracing seems to confirm this)

I cannot see a reason for evaluating the first arg >> with the summation
variable bound to itself <<, it seems to me that this makes the evaluation
rules unnessecarily complicated!

Martin

> Consider
>
>   foo: i^2;
>
>   sum('foo,i,0,2) => 3*foo  (correct)
>   sum(foo,i,0,2) => 3*i^2   WRONG
>   sum(foo,i,0,n) => 'sum(i^2,i,0,n) (correct)
>
> In the case where upperlimit-lowerlimit is a known
> integer, simpsum is checking whether foo is free of i
> *before* evaluating foo.
>
> I believe the correct way to handle this case is as
> follows: First evaluate foo with i bound to itself, and
> check if that result is free of i.  If so, return the product.
> If not, *substitute* (don't evaluate) i=lowerlimit,
> i=lowerlimit+1, etc.
>
> This means that sum(print(i),i,1,2) would print "i", and
> not "1 2".  That makes it consistent with Integrate:
>
>   integrate('foo,i,0,2) => 2*foo  (correct)
>   integrate(foo,i,0,2) => 8/3  (correct)
>   integrate(foo,i,0,n) => n^3/3 (correct)
>
> It also makes it consistent with Integrate in the
> presence of side-effects:
>
>   integrate(print(i),i,0,1)  prints i
>   sum(print(i),i,0,1)
>        currently prints 0 1
>        but in this proposal would print i
>
> It is true that it would also create some funny situations.
>
> Currently,
>
>      sum(integrate(x^i,x),i,0,2)
>
> evaluates correctly to x+x^2/2+x^3/3.  Under this
> proposal, it would also evaluate *correctly*, but would
> first ask whether i+1 is zero or nonzero.  Unless, that is,
> simpsum binds i to be an integer and to have a value
> >=lowerlimit and <=upperlimit (which is a sensible thing
> to do anyway).
>
> Now consider
>
>      sum(integrate(1/(x^i+1),i),i,0,1)
>
> This currently correctly evaluates to x/2+log(x+1).
> Under the proposal, however, it would evaluate to a sum
> of noun forms, since the integral does not exist in
> closed form.  I think we can live with that; an ev
> (...,integrate) takes care of it.
>
> But I still like the proposal.  After all, if you set the result
> of the integration expression above to a temporary
> variable (which seems like a sensible thing to do), you
> will run into the original bad behavior.

```