[Maxima] Re: sum evals first argument inconsistently
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...
and some other things in the same thread
Consider the following:
seems consistent to me.
With your proposal, this would become
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:
Variable of integration not a variable: 1
Improper variable of integration: y^k
What I didn't expect, though:
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!
> 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
> currently prints 0 1
> but in this proposal would print i
> It is true that it would also create some funny situations.
> 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
> 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.