# Just Launched: You can now import projects and releases from Google Code onto SourceForge

We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps.

## maxima-bugs

 [Maxima-bugs] [ maxima-Bugs-740134 ] sum evals first argument inconsistently From: SourceForge.net - 2003-05-19 22:13:42 ```Bugs item #740134, was opened at 2003-05-19 18:13 Message generated for change (Tracker Item Submitted) made by Item Submitter 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 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=740134&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-740134 ] sum evals first argument inconsistently From: SourceForge.net - 2003-07-12 20:05:21 ```Bugs item #740134, was opened at 2003-05-19 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 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: Stavros Macrakis (macrakis) Date: 2003-07-12 16: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 ```
 [Maxima-bugs] [ maxima-Bugs-740134 ] sum evals first argument inconsistently From: SourceForge.net - 2005-06-13 05:54:04 ```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: 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 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-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 ```
 [Maxima-bugs] [ maxima-Bugs-740134 ] sum evals first argument inconsistently From: SourceForge.net - 2005-11-24 08:39:45 ```Bugs item #740134, was opened at 2003-05-19 16:13 Message generated for change (Settings changed) 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-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 ```
 [Maxima-bugs] [ maxima-Bugs-740134 ] sum evals first argument inconsistently From: SourceForge.net - 2005-11-24 08:43:07 ```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 ```