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