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...>  20080708 17:01:10

Bugs item #2013650, was opened at 20080708 13:01 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=2013650&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: gamma(250.0) returns nonnumber; gamma(1.0) finite Initial Comment: gamma(250.0) and 250.0! return nonnumbers. This causes an error in printing ("Can't print a nonnumber"). It should cause a clean overflow error. The problem is in gammalanczos, which doesn't check that its return value is welldefined (not infinite, not a NaN) before returning it. gammalanczos also does not report an error for negative integer arguments: gamma(1.0) => 2.6e+16 Worse, bfloat(gamma(250.0)) returns a grossly incorrect result  see next error report. Tested on Maxima 5.14.0 GCL Windows  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013650&group_id=4933 
From: SourceForge.net <noreply@so...>  20080712 03:41:40

Bugs item #2013650, was opened at 20080708 11:01 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013650&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: gamma(250.0) returns nonnumber; gamma(1.0) finite Initial Comment: gamma(250.0) and 250.0! return nonnumbers. This causes an error in printing ("Can't print a nonnumber"). It should cause a clean overflow error. The problem is in gammalanczos, which doesn't check that its return value is welldefined (not infinite, not a NaN) before returning it. gammalanczos also does not report an error for negative integer arguments: gamma(1.0) => 2.6e+16 Worse, bfloat(gamma(250.0)) returns a grossly incorrect result  see next error report. Tested on Maxima 5.14.0 GCL Windows  >Comment By: Robert Dodier (robert_dodier) Date: 20080711 21:41 Message: Logged In: YES user_id=501686 Originator: NO I 'm not convinced the problem is in GAMMALANCZOS. If the Lisp implementation permits infinity and NaN as floating point results, then Maxima functions could just pass those along. The only bug that I see here for sure is that GCL cannot display NaN and infinity (although such values can be computed by GCL). For the sake of uniform behavior, I suppose Maxima functions could reject NaN and infinity, no matter which Lisp, or allow them. Probably it is easier to reject NaN and infinity. I'm undecided at this point about having a uniform policy wrt floating point special values, or letting it remain an implementationdependent feature.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013650&group_id=4933 
From: SourceForge.net <noreply@so...>  20080717 13:51:34

Bugs item #2013650, was opened at 20080708 13:01 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013650&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: gamma(250.0) returns nonnumber; gamma(1.0) finite Initial Comment: gamma(250.0) and 250.0! return nonnumbers. This causes an error in printing ("Can't print a nonnumber"). It should cause a clean overflow error. The problem is in gammalanczos, which doesn't check that its return value is welldefined (not infinite, not a NaN) before returning it. gammalanczos also does not report an error for negative integer arguments: gamma(1.0) => 2.6e+16 Worse, bfloat(gamma(250.0)) returns a grossly incorrect result  see next error report. Tested on Maxima 5.14.0 GCL Windows  >Comment By: Stavros Macrakis (macrakis) Date: 20080717 09:51 Message: Logged In: YES user_id=588346 Originator: YES As long as we don't have a welldefined policy for Maxima's handling of IEEE infs and NaNs, it is a bug for any routine to return an IEEE inf or NaN. When/if we define the behavior and update the code to work correctly in the presence of inf/NaN, then it will be fine.  Comment By: Robert Dodier (robert_dodier) Date: 20080711 23:41 Message: Logged In: YES user_id=501686 Originator: NO I 'm not convinced the problem is in GAMMALANCZOS. If the Lisp implementation permits infinity and NaN as floating point results, then Maxima functions could just pass those along. The only bug that I see here for sure is that GCL cannot display NaN and infinity (although such values can be computed by GCL). For the sake of uniform behavior, I suppose Maxima functions could reject NaN and infinity, no matter which Lisp, or allow them. Probably it is easier to reject NaN and infinity. I'm undecided at this point about having a uniform policy wrt floating point special values, or letting it remain an implementationdependent feature.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013650&group_id=4933 
From: SourceForge.net <noreply@so...>  20080914 16:52:30

Bugs item #2013650, was opened at 20080708 19:01 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013650&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: gamma(250.0) returns nonnumber; gamma(1.0) finite Initial Comment: gamma(250.0) and 250.0! return nonnumbers. This causes an error in printing ("Can't print a nonnumber"). It should cause a clean overflow error. The problem is in gammalanczos, which doesn't check that its return value is welldefined (not infinite, not a NaN) before returning it. gammalanczos also does not report an error for negative integer arguments: gamma(1.0) => 2.6e+16 Worse, bfloat(gamma(250.0)) returns a grossly incorrect result  see next error report. Tested on Maxima 5.14.0 GCL Windows  >Comment By: Dieter Kaiser (crategus) Date: 20080914 18:52 Message: After adding code to simpgamma and gammalanczos Maxima get the following results: (%i3) gamma(250.0); Overflow in `gammalanczos'.  an error. To debug this try debugmode(true); (%i4) 250.0!; Overflow in `gammalanczos'.  an error. To debug this try debugmode(true); (%i5) gamma(1.0); gamma(1.0) is undefined.  an error. To debug this try debugmode(true); (%i6) gamma(1.0b0); gamma(1.0b0) is undefined.  an error. To debug this try debugmode(true); (%i7) bfloat(gamma(250.0)); Overflow in `gammalanczos'.  an error. To debug this try debugmode(true); For negative integers the result infinity would be nicer, but Maxima can not do calculations with infinities. Because we get a Maxima Error for negative integers, it is the best to give a Maxima Error for the float and bigfloat representations of a negative integer too. For GCL 2.6.8 and CLISP 2.46 gammalanzcos will detected an overflow for values greater than about 171.6243. When the tests will not give new problems with other compilers, we could close the bug report. Dieter Kaiser  Comment By: Stavros Macrakis (macrakis) Date: 20080717 15:51 Message: Logged In: YES user_id=588346 Originator: YES As long as we don't have a welldefined policy for Maxima's handling of IEEE infs and NaNs, it is a bug for any routine to return an IEEE inf or NaN. When/if we define the behavior and update the code to work correctly in the presence of inf/NaN, then it will be fine.  Comment By: Robert Dodier (robert_dodier) Date: 20080712 05:41 Message: Logged In: YES user_id=501686 Originator: NO I 'm not convinced the problem is in GAMMALANCZOS. If the Lisp implementation permits infinity and NaN as floating point results, then Maxima functions could just pass those along. The only bug that I see here for sure is that GCL cannot display NaN and infinity (although such values can be computed by GCL). For the sake of uniform behavior, I suppose Maxima functions could reject NaN and infinity, no matter which Lisp, or allow them. Probably it is easier to reject NaN and infinity. I'm undecided at this point about having a uniform policy wrt floating point special values, or letting it remain an implementationdependent feature.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013650&group_id=4933 
From: SourceForge.net <noreply@so...>  20080921 22:21:22

Bugs item #2013650, was opened at 20080708 19:01 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013650&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  Floating point Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: gamma(250.0) returns nonnumber; gamma(1.0) finite Initial Comment: gamma(250.0) and 250.0! return nonnumbers. This causes an error in printing ("Can't print a nonnumber"). It should cause a clean overflow error. The problem is in gammalanczos, which doesn't check that its return value is welldefined (not infinite, not a NaN) before returning it. gammalanczos also does not report an error for negative integer arguments: gamma(1.0) => 2.6e+16 Worse, bfloat(gamma(250.0)) returns a grossly incorrect result  see next error report. Tested on Maxima 5.14.0 GCL Windows  >Comment By: Dieter Kaiser (crategus) Date: 20080922 00:21 Message: Closing this bug report. There have been no problems reported to the changes in csimp2.lisp (Rev. 1.22). Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20080914 18:52 Message: After adding code to simpgamma and gammalanczos Maxima get the following results: (%i3) gamma(250.0); Overflow in `gammalanczos'.  an error. To debug this try debugmode(true); (%i4) 250.0!; Overflow in `gammalanczos'.  an error. To debug this try debugmode(true); (%i5) gamma(1.0); gamma(1.0) is undefined.  an error. To debug this try debugmode(true); (%i6) gamma(1.0b0); gamma(1.0b0) is undefined.  an error. To debug this try debugmode(true); (%i7) bfloat(gamma(250.0)); Overflow in `gammalanczos'.  an error. To debug this try debugmode(true); For negative integers the result infinity would be nicer, but Maxima can not do calculations with infinities. Because we get a Maxima Error for negative integers, it is the best to give a Maxima Error for the float and bigfloat representations of a negative integer too. For GCL 2.6.8 and CLISP 2.46 gammalanzcos will detected an overflow for values greater than about 171.6243. When the tests will not give new problems with other compilers, we could close the bug report. Dieter Kaiser  Comment By: Stavros Macrakis (macrakis) Date: 20080717 15:51 Message: Logged In: YES user_id=588346 Originator: YES As long as we don't have a welldefined policy for Maxima's handling of IEEE infs and NaNs, it is a bug for any routine to return an IEEE inf or NaN. When/if we define the behavior and update the code to work correctly in the presence of inf/NaN, then it will be fine.  Comment By: Robert Dodier (robert_dodier) Date: 20080712 05:41 Message: Logged In: YES user_id=501686 Originator: NO I 'm not convinced the problem is in GAMMALANCZOS. If the Lisp implementation permits infinity and NaN as floating point results, then Maxima functions could just pass those along. The only bug that I see here for sure is that GCL cannot display NaN and infinity (although such values can be computed by GCL). For the sake of uniform behavior, I suppose Maxima functions could reject NaN and infinity, no matter which Lisp, or allow them. Probably it is easier to reject NaN and infinity. I'm undecided at this point about having a uniform policy wrt floating point special values, or letting it remain an implementationdependent feature.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013650&group_id=4933 
Sign up for the SourceForge newsletter:
No, thanks