Re: sum evals first argument inconsistently

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.