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: <noreply@so...>  20020810 22:30:25

Bugs item #593530, was opened at 20020810 18:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Zeroequiv issues Initial Comment: Zeroequiv gives Dontknow for xatan(x) This function is wellbehaved and numerically nonzero for abs(x)>1.0e8. The following give True: sin(1/1000) !!! (no variable) sin(asin(x)+1/1000)x sin(x+1/1000)sin(x) This gets an internal error (stack overflow): atan(x)^1000  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&group_id=4933 
From: SourceForge.net <noreply@so...>  20060626 17:05:33

Bugs item #593530, was opened at 20020810 16:30 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&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: Zeroequiv issues Initial Comment: Zeroequiv gives Dontknow for xatan(x) This function is wellbehaved and numerically nonzero for abs(x)>1.0e8. The following give True: sin(1/1000) !!! (no variable) sin(asin(x)+1/1000)x sin(x+1/1000)sin(x) This gets an internal error (stack overflow): atan(x)^1000  >Comment By: Robert Dodier (robert_dodier) Date: 20060626 11:05 Message: Logged In: YES user_id=501686 Maxima 5.9.3: Same behavior observed for each example. zeroequiv seems to be a hack. If we don't fix it (which could be a pretty serious investment), maybe we should cut it. Just a thought.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&group_id=4933 
From: SourceForge.net <noreply@so...>  20090102 00:08:51

Bugs item #593530, was opened at 20020811 00:30 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Zeroequiv issues Initial Comment: Zeroequiv gives Dontknow for xatan(x) This function is wellbehaved and numerically nonzero for abs(x)>1.0e8. The following give True: sin(1/1000) !!! (no variable) sin(asin(x)+1/1000)x sin(x+1/1000)sin(x) This gets an internal error (stack overflow): atan(x)^1000  >Comment By: Dieter Kaiser (crategus) Date: 20090102 01:08 Message: These are the actual results for the given examples: (%i16) zeroequiv(xatan(x),x); (%o16) dontknow (%i17) zeroequiv(sin(1/1000),x); (%o17) false (%i18) zeroequiv(sin(asin(x)+1/1000)x,x); (%o18) false (%i19) zeroequiv(sin(x+1/1000)sin(x),x); (%o19) true (%i20) zeroequiv(atan(x)^1000,x); (%o20) false (%i17) and (%i18) now give false, (%i20) no longer gives an internal error but the answer false. I think (%i19) should give the answer false too. Within the Maxima project I have found only two calls to zeroequiv in the file share/calculus/qual.mac. This package does a qualitative analysis of functions. I have not found any reference to the functions of qual.mac in the Maxima documentation and I have not found a call to the functions of qual.mac. zeroequiv does not work perfectly, but this is not expected even by the documentation in the Maxima manual. I think at this time it is not worth to improve the function zeroequiv, because there seems to be no important code which depends on the function. To close the bug report I would like to suggest the following options: (1) Closing the bug report without any change. (2) Cutting out the function from the Maxima manual. (3) Moving the code to share/calculus/qualsp.lisp. Perhaps we should close the related bug report SF[626760] "zeroequiv extremely slow (minor)" too.  Comment By: Robert Dodier (robert_dodier) Date: 20060626 19:05 Message: Logged In: YES user_id=501686 Maxima 5.9.3: Same behavior observed for each example. zeroequiv seems to be a hack. If we don't fix it (which could be a pretty serious investment), maybe we should cut it. Just a thought.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&group_id=4933 
From: SourceForge.net <noreply@so...>  20090117 21:14:54

Bugs item #593530, was opened at 20020811 00:30 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&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: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Zeroequiv issues Initial Comment: Zeroequiv gives Dontknow for xatan(x) This function is wellbehaved and numerically nonzero for abs(x)>1.0e8. The following give True: sin(1/1000) !!! (no variable) sin(asin(x)+1/1000)x sin(x+1/1000)sin(x) This gets an internal error (stack overflow): atan(x)^1000  >Comment By: Dieter Kaiser (crategus) Date: 20090117 22:14 Message: The documentation of zeroequiv says: "zeroequiv has these restrictions: Do not use functions that Maxima does not know how to differentiate and evaluate. If the expression has poles on the real line, there may be errors in the result (but this is unlikely to occur). If the expression contains functions which are not solutions to first order differential equations (e.g. Bessel functions) there may be incorrect results. The algorithm uses evaluation at randomly chosen points for carefully selected subexpressions. This is always a somewhat hazardous business, although the algorithm tries to minimize the potential for error." The documentation takes into account that zeroequiv can have problems. The function is not used for in core functions. Only one application in code which is not documented can be found. Setting resolution to "wont fix" and the status to pending. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090102 01:08 Message: These are the actual results for the given examples: (%i16) zeroequiv(xatan(x),x); (%o16) dontknow (%i17) zeroequiv(sin(1/1000),x); (%o17) false (%i18) zeroequiv(sin(asin(x)+1/1000)x,x); (%o18) false (%i19) zeroequiv(sin(x+1/1000)sin(x),x); (%o19) true (%i20) zeroequiv(atan(x)^1000,x); (%o20) false (%i17) and (%i18) now give false, (%i20) no longer gives an internal error but the answer false. I think (%i19) should give the answer false too. Within the Maxima project I have found only two calls to zeroequiv in the file share/calculus/qual.mac. This package does a qualitative analysis of functions. I have not found any reference to the functions of qual.mac in the Maxima documentation and I have not found a call to the functions of qual.mac. zeroequiv does not work perfectly, but this is not expected even by the documentation in the Maxima manual. I think at this time it is not worth to improve the function zeroequiv, because there seems to be no important code which depends on the function. To close the bug report I would like to suggest the following options: (1) Closing the bug report without any change. (2) Cutting out the function from the Maxima manual. (3) Moving the code to share/calculus/qualsp.lisp. Perhaps we should close the related bug report SF[626760] "zeroequiv extremely slow (minor)" too.  Comment By: Robert Dodier (robert_dodier) Date: 20060626 19:05 Message: Logged In: YES user_id=501686 Maxima 5.9.3: Same behavior observed for each example. zeroequiv seems to be a hack. If we don't fix it (which could be a pretty serious investment), maybe we should cut it. Just a thought.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&group_id=4933 
From: SourceForge.net <noreply@so...>  20090117 22:49:33

Bugs item #593530, was opened at 20020810 18:30 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Zeroequiv issues Initial Comment: Zeroequiv gives Dontknow for xatan(x) This function is wellbehaved and numerically nonzero for abs(x)>1.0e8. The following give True: sin(1/1000) !!! (no variable) sin(asin(x)+1/1000)x sin(x+1/1000)sin(x) This gets an internal error (stack overflow): atan(x)^1000  >Comment By: Stavros Macrakis (macrakis) Date: 20090117 16:56 Message: I don't see the point of quoting the documentation at length. Clearly zeroequiv is approximate and not guaranteed to determine whether the expression is 0 or not in all cases. However, this does not excuse flagrantly bad cases like zeroequiv(xatan(x),x). Also, the fact that zeroequiv is "not used for incore functions" is not relevant. Zeroequiv is a documented part of the system, and is not working as documented, or as a reasonable user would expect it to work. The fact that *you* have decided not to fix it is not relevant. Perhaps someone else will. Reverting to status=open.  Comment By: Dieter Kaiser (crategus) Date: 20090117 16:14 Message: The documentation of zeroequiv says: "zeroequiv has these restrictions: Do not use functions that Maxima does not know how to differentiate and evaluate. If the expression has poles on the real line, there may be errors in the result (but this is unlikely to occur). If the expression contains functions which are not solutions to first order differential equations (e.g. Bessel functions) there may be incorrect results. The algorithm uses evaluation at randomly chosen points for carefully selected subexpressions. This is always a somewhat hazardous business, although the algorithm tries to minimize the potential for error." The documentation takes into account that zeroequiv can have problems. The function is not used for in core functions. Only one application in code which is not documented can be found. Setting resolution to "wont fix" and the status to pending. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090101 19:08 Message: These are the actual results for the given examples: (%i16) zeroequiv(xatan(x),x); (%o16) dontknow (%i17) zeroequiv(sin(1/1000),x); (%o17) false (%i18) zeroequiv(sin(asin(x)+1/1000)x,x); (%o18) false (%i19) zeroequiv(sin(x+1/1000)sin(x),x); (%o19) true (%i20) zeroequiv(atan(x)^1000,x); (%o20) false (%i17) and (%i18) now give false, (%i20) no longer gives an internal error but the answer false. I think (%i19) should give the answer false too. Within the Maxima project I have found only two calls to zeroequiv in the file share/calculus/qual.mac. This package does a qualitative analysis of functions. I have not found any reference to the functions of qual.mac in the Maxima documentation and I have not found a call to the functions of qual.mac. zeroequiv does not work perfectly, but this is not expected even by the documentation in the Maxima manual. I think at this time it is not worth to improve the function zeroequiv, because there seems to be no important code which depends on the function. To close the bug report I would like to suggest the following options: (1) Closing the bug report without any change. (2) Cutting out the function from the Maxima manual. (3) Moving the code to share/calculus/qualsp.lisp. Perhaps we should close the related bug report SF[626760] "zeroequiv extremely slow (minor)" too.  Comment By: Robert Dodier (robert_dodier) Date: 20060626 13:05 Message: Logged In: YES user_id=501686 Maxima 5.9.3: Same behavior observed for each example. zeroequiv seems to be a hack. If we don't fix it (which could be a pretty serious investment), maybe we should cut it. Just a thought.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&group_id=4933 
From: SourceForge.net <noreply@so...>  20090410 16:28:34

Bugs item #593530, was opened at 20020810 23:30 Message generated for change (Comment added) made by rswarbrick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Zeroequiv issues Initial Comment: Zeroequiv gives Dontknow for xatan(x) This function is wellbehaved and numerically nonzero for abs(x)>1.0e8. The following give True: sin(1/1000) !!! (no variable) sin(asin(x)+1/1000)x sin(x+1/1000)sin(x) This gets an internal error (stack overflow): atan(x)^1000  Comment By: Rupert Swarbrick (rswarbrick) Date: 20090410 17:28 Message: Having spent some time looking at this, I noticed that zeroequiv(sin(1/100), x) is *sometimes* zero (!!). This is because of the numerical evaluation code in zeroequiv2 multiplying by r for some reason. It seems that zeroequiv(xatan(x),x) now works correctly. The things that get as far as zeroequiv2 will always be dodgy: if they are numerically less than some threshold (1/100 atm), then they will be considered zero. Thus sin(1/1000). Trying to work on atan(x)^1000, there is indeed a 1000deep nested call in zeroequiv1. It expands the derivative in powers of atan(x) and walks along the terms. Not sure what a fix for that would be.  Comment By: Stavros Macrakis (macrakis) Date: 20090117 21:56 Message: I don't see the point of quoting the documentation at length. Clearly zeroequiv is approximate and not guaranteed to determine whether the expression is 0 or not in all cases. However, this does not excuse flagrantly bad cases like zeroequiv(xatan(x),x). Also, the fact that zeroequiv is "not used for incore functions" is not relevant. Zeroequiv is a documented part of the system, and is not working as documented, or as a reasonable user would expect it to work. The fact that *you* have decided not to fix it is not relevant. Perhaps someone else will. Reverting to status=open.  Comment By: Dieter Kaiser (crategus) Date: 20090117 21:14 Message: The documentation of zeroequiv says: "zeroequiv has these restrictions: Do not use functions that Maxima does not know how to differentiate and evaluate. If the expression has poles on the real line, there may be errors in the result (but this is unlikely to occur). If the expression contains functions which are not solutions to first order differential equations (e.g. Bessel functions) there may be incorrect results. The algorithm uses evaluation at randomly chosen points for carefully selected subexpressions. This is always a somewhat hazardous business, although the algorithm tries to minimize the potential for error." The documentation takes into account that zeroequiv can have problems. The function is not used for in core functions. Only one application in code which is not documented can be found. Setting resolution to "wont fix" and the status to pending. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090102 00:08 Message: These are the actual results for the given examples: (%i16) zeroequiv(xatan(x),x); (%o16) dontknow (%i17) zeroequiv(sin(1/1000),x); (%o17) false (%i18) zeroequiv(sin(asin(x)+1/1000)x,x); (%o18) false (%i19) zeroequiv(sin(x+1/1000)sin(x),x); (%o19) true (%i20) zeroequiv(atan(x)^1000,x); (%o20) false (%i17) and (%i18) now give false, (%i20) no longer gives an internal error but the answer false. I think (%i19) should give the answer false too. Within the Maxima project I have found only two calls to zeroequiv in the file share/calculus/qual.mac. This package does a qualitative analysis of functions. I have not found any reference to the functions of qual.mac in the Maxima documentation and I have not found a call to the functions of qual.mac. zeroequiv does not work perfectly, but this is not expected even by the documentation in the Maxima manual. I think at this time it is not worth to improve the function zeroequiv, because there seems to be no important code which depends on the function. To close the bug report I would like to suggest the following options: (1) Closing the bug report without any change. (2) Cutting out the function from the Maxima manual. (3) Moving the code to share/calculus/qualsp.lisp. Perhaps we should close the related bug report SF[626760] "zeroequiv extremely slow (minor)" too.  Comment By: Robert Dodier (robert_dodier) Date: 20060626 18:05 Message: Logged In: YES user_id=501686 Maxima 5.9.3: Same behavior observed for each example. zeroequiv seems to be a hack. If we don't fix it (which could be a pretty serious investment), maybe we should cut it. Just a thought.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&group_id=4933 