- labels: --> Lisp Core
Zeroequiv gives Dontknow for
x-atan(x)
This function is well-behaved and numerically nonzero for
abs(x)>1.0e-8.
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
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.
These are the actual results for the given examples:
(%i16) zeroequiv(x-atan(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.
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
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(x-atan(x),x).
Also, the fact that zeroequiv is "not used for in-core 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.
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(x-atan(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 1000-deep 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.
Log in to post a comment.