From: SourceForge.net <noreply@so...>  20030712 20:05:21

Bugs item #740134, was opened at 20030519 18:13 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=740134&group_id=4933 Category: None Group: None Status: Open 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 upperlimitlowerlimit 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 sideeffects: 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: Stavros Macrakis (macrakis) Date: 20030712 16:05 Message: Logged In: YES user_id=588346 More problems with the interaction between sumevaluation 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 