Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: SourceForge.net <noreply@so...>  20030519 22:13:42

Bugs item #740134, was opened at 20030519 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 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.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=740134&group_id=4933 
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 
From: SourceForge.net <noreply@so...>  20050613 05:54:04

Bugs item #740134, was opened at 20030519 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 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: Robert Dodier (robert_dodier) Date: 20050612 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: 20030712 14: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 
From: SourceForge.net <noreply@so...>  20051124 08:39:45

Bugs item #740134, was opened at 20030519 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 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: Robert Dodier (robert_dodier) Date: 20050612 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: 20030712 14: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 
From: SourceForge.net <noreply@so...>  20051124 08:43:07

Bugs item #740134, was opened at 20030519 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 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: Robert Dodier (robert_dodier) Date: 20051124 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: 20050612 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: 20030712 14: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 
Sign up for the SourceForge newsletter:
No, thanks