Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Close
From: SourceForge.net <noreply@so...>  20051219 15:29:25

Bugs item #1384860, was opened at 20051218 20:26 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1384860&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) >Summary: GosperSum / nusum(x^k,k,1,inf) > unsimplified Initial Comment: (%i43) nusum(x^k,k,1,inf); (%o43) x^(inf+1)/(x1)x/(x1) A user has to clean this up with limit: (%i44) limit(%); Is abs(x)  1 positive, negative, or zero? neg; Is x positive, negative, or zero? pos; Is x  1 positive or negative? neg; (%o44) x/(x1) Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20051219 08:29 Message: Logged In: YES user_id=501686 nusum is superseded by the more recent and extensive Zeilberger package (share/contrib/Zeilberger) which includes Gosper's algorithm as a special case. Be that as it may, it turns out GosperSum in the Zeilberger package has exactly the same defect ... load ("Zeilberger/LOADZeilberger.mac"); GosperSum (x^k, k, 1, inf); => x^(inf+1)/(x1)x/(x1) I am guessing that the algorithm is phrased in terms of "n" and there is no check to ensure that n is finite. If I'm not mistaken the Zeilberger/Gosper stuff is advertised generally as "indefinite summation" so that's understandable, but if so then the Maxima fcns should make an effort to rule out inapplicable cases. I don't think it's worthwhile to fix nusum  I think any effort on this problem should be directed to the Zeilberger package. best, Robert Dodier  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1384860&group_id=4933 
From: SourceForge.net <noreply@so...>  20051219 16:30:55

Bugs item #1384860, was opened at 20051218 22:26 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1384860&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: GosperSum / nusum(x^k,k,1,inf) > unsimplified Initial Comment: (%i43) nusum(x^k,k,1,inf); (%o43) x^(inf+1)/(x1)x/(x1) A user has to clean this up with limit: (%i44) limit(%); Is abs(x)  1 positive, negative, or zero? neg; Is x positive, negative, or zero? pos; Is x  1 positive or negative? neg; (%o44) x/(x1) Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20051219 11:30 Message: Logged In: YES user_id=588346 It is easy enough for the top level of GosperSum to convert GS(...,v,a,inf) to limit(GS(...,v,a,GENSYM),GENSYM,inf) In some cases (probably not for the output of GS), this will return a noun form, but there's nothing wrong with that.  Comment By: Robert Dodier (robert_dodier) Date: 20051219 10:29 Message: Logged In: YES user_id=501686 nusum is superseded by the more recent and extensive Zeilberger package (share/contrib/Zeilberger) which includes Gosper's algorithm as a special case. Be that as it may, it turns out GosperSum in the Zeilberger package has exactly the same defect ... load ("Zeilberger/LOADZeilberger.mac"); GosperSum (x^k, k, 1, inf); => x^(inf+1)/(x1)x/(x1) I am guessing that the algorithm is phrased in terms of "n" and there is no check to ensure that n is finite. If I'm not mistaken the Zeilberger/Gosper stuff is advertised generally as "indefinite summation" so that's understandable, but if so then the Maxima fcns should make an effort to rule out inapplicable cases. I don't think it's worthwhile to fix nusum  I think any effort on this problem should be directed to the Zeilberger package. best, Robert Dodier  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1384860&group_id=4933 
From: SourceForge.net <noreply@so...>  20051219 18:18:26

Bugs item #1384860, was opened at 20051218 22:26 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1384860&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: GosperSum / nusum(x^k,k,1,inf) > unsimplified Initial Comment: (%i43) nusum(x^k,k,1,inf); (%o43) x^(inf+1)/(x1)x/(x1) A user has to clean this up with limit: (%i44) limit(%); Is abs(x)  1 positive, negative, or zero? neg; Is x positive, negative, or zero? pos; Is x  1 positive or negative? neg; (%o44) x/(x1) Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20051219 11:37 Message: Logged In: YES user_id=588346 PS I do NOT recommend leaving in the INF and using the 1argument form of Limit for cleaning up, partly because expressions involving multiple INFs are problematic (though Limit supposedly treats them as though they're all the same variable) and partly because Limit is buggy: assume(a>1)$ limit(a*infinf) => minf  Comment By: Stavros Macrakis (macrakis) Date: 20051219 11:30 Message: Logged In: YES user_id=588346 It is easy enough for the top level of GosperSum to convert GS(...,v,a,inf) to limit(GS(...,v,a,GENSYM),GENSYM,inf) In some cases (probably not for the output of GS), this will return a noun form, but there's nothing wrong with that.  Comment By: Robert Dodier (robert_dodier) Date: 20051219 10:29 Message: Logged In: YES user_id=501686 nusum is superseded by the more recent and extensive Zeilberger package (share/contrib/Zeilberger) which includes Gosper's algorithm as a special case. Be that as it may, it turns out GosperSum in the Zeilberger package has exactly the same defect ... load ("Zeilberger/LOADZeilberger.mac"); GosperSum (x^k, k, 1, inf); => x^(inf+1)/(x1)x/(x1) I am guessing that the algorithm is phrased in terms of "n" and there is no check to ensure that n is finite. If I'm not mistaken the Zeilberger/Gosper stuff is advertised generally as "indefinite summation" so that's understandable, but if so then the Maxima fcns should make an effort to rule out inapplicable cases. I don't think it's worthwhile to fix nusum  I think any effort on this problem should be directed to the Zeilberger package. best, Robert Dodier  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1384860&group_id=4933 