Re: sum evals first argument inconsistently

The method of evaluation for the arguments to SUM have
been hashed over repeatedly both in Macsyma (circa 1969?)
and its competitors.  It does not help to have the
"right" answer if the users expect you to have a
different answer.

I havent read / re-read the arguments recently, and I
can't follow the link from Stavros' mail  (it says
ERROR - No group_id was chosen. )

But an argument can be made to require that the first
argument must be a function of one argument,
  lambda([index], expression).

For what it is worth, I have been experimenting with
Matlab (with symbolic toolbox), and it is really weird,
with TWO value spaces and ONE namespace.
e.g.
command          result

pi                3.14159..
x=3               sets x to 3
simplify(pi+sym(0))    pi
simplify(x+sym(0))      3

simplify(x)         error

RJF



Martin RUBEY wrote:
> 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.
> 
> 
> 
> 
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima