[Maxima-bugs] [ maxima-Bugs-740134 ] sum evals first argument inconsistently

[SourceForge.net <no...@so...>]

Bugs item #740134, was opened at 2003-05-19 16:13
Message generated for change (Comment added) made by robert_dodier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=740134&group_id=4933

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Lisp Core
Group: None
Status: Closed
Resolution: None
Priority: 5
Submitted By: Stavros Macrakis (macrakis)
Assigned to: Nobody/Anonymous (nobody)
Summary: sum evals first argument inconsistently

Initial Comment:
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.

----------------------------------------------------------------------

Comment By: Robert Dodier (robert_dodier)
Date: 2005-11-24 01:43

Message:
Logged In: YES 
user_id=501686

The reported bug is not present in the current cvs version of
Maxima. 

Thank you for your report. If you see this bug in a later version
of Maxima, please submit a new bug report.


----------------------------------------------------------------------

Comment By: Robert Dodier (robert_dodier)
Date: 2005-06-12 23:54

Message:
Logged In: YES 
user_id=501686

The analysis presented in the original comments seems a
little off the mark.  In this example,

   foo: i^2;
   sum (foo, i, 0, 2);

As shown by :lisp (trace meval), $sum is indeed evaluating
the summand for each value of the index. Each of 3
evaluations (meval '$foo) yields ((MEXPT SIMP) $I 2), so the
sum simplifies to 3 i^2. 

The problem here is that (meval '$foo) yields an expression
with $i in it, and the expression isn't evaluated any
farther. Replacing (meval exp) with (meval (meval exp)) in
DOSUM yields the expected result, although I don't know if
that's optimal.

About the 'SUM(LAMBDA([x],x^i)(x),i,0,n) noted in the 2nd
comment, this comes from $sum calling MEVALATOMS
(eventually) to evaluate the summand. Calling MEVAL instead
yields x^i as expected. $sum goes down the path to
MEVALATOMS if the sum is something other than a finite sum;
the lambda goes away if n is assigned a value e.g. 3 or
something, since MEVAL is called instead of MEVALATOMS.

----------------------------------------------------------------------

Comment By: Stavros Macrakis (macrakis)
Date: 2003-07-12 14:05

Message:
Logged In: YES 
user_id=588346

More problems with the interaction between sum-evaluation 
and hash arrays:

(C1) f[i](x):=x^i$
(C2) g[i](x):=x^i$
(C3) h[i](x):=x^i$
(C4) f[i];
(D4) LAMBDA([x],x^i)
(C5) g[i](t);
(D5) t^i

/* fine so far */

(C6) sum(f[i](x),i,0,n);
(D6) 'SUM(LAMBDA([x],x^i)(x),i,0,n)

/* oops, why are we seeing the lambda form here? This is 
some sort of partial evaluation.... */

(C7) sum(g[i](x),i,0,n);
(D7) 'SUM(LAMBDA([x],x^i)(x),i,0,n)

/* and here */

(C8) sum(h[i](x),i,0,n);
(D8) 'SUM(h[i](x),i,0,n)

/* but here we're not getting h[i] to evaluate at all, which
is consistent with  other cases, e.g.: */

(C9) sum(integrate(x^i,x),i,0,n);
(D9) 'SUM(INTEGRATE(x^i,x),i,0,n);


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=740134&group_id=4933