It is not difficult to see that the value of the following limit is 4*m + 1. However, maxima says the value is 0:
(%i1) declare(m, integer)$
(%i2) assume(equal(cos((4 * %pi * m + %pi)/2), 0))$
(%i3) limit(cos((4*m + 1) * asin(1/sqrt(x^2 + 1)))/abs(x), x, 0);
(%o3) 0
This is from sagemath trac ticket #34140.
Maxima version: "5.43.0"
Maxima build date: "2019-06-05 13:14:43"
Host type: "x86_64-apple-darwin13.4.0"
Lisp implementation type: "SBCL"
Lisp implementation version: "1.5.3"
Observed in current version from Git.
build_inforeports in part:Looks like the result is coming out of TAYLIM (Lisp function for Taylor limit).
tayloris returning something that looks likestuff/x + constant + (more stuff times powers of x)wherestuffis the term whichasksignwas asking about. If you answerzero, then TAYLIM seems to forget about the constant, which, at this point, I believe is the part which gives the correct result.For the record, I didn't investigate whether TAYLIM does the right thing if you respond something other than
zerotoasksign.Here's what I'm seeing. Current Git version as noted above.
limitseems to call TAYLIM twice, dunno why it decided it needed to do that.Last edit: Robert Dodier 2022-07-10
A somewhat simpler example. I've substituted
nfor4*m + 1. I callratdisrepin betweentaylorandlimitbecause that's what TAYLIM does.Thanks for looking at this. Based on your last message, I found a much simpler example:
Dave, thanks a lot for that example. I see that
limit(a*x + 1, x, inf)has the same bug -- the result is 0 if you respondzto "Is a positive, negative or zero?".Looks like the bug is in RATLIM (src/limit.lisp), which appears to be for computing limits for rational functions. A glance seems to show RATLIM has cases for less than zero and greater than zero, but assumes the result is 0 in the case that the sign is zero -- look for the calls to GETSIGNL and the code after those.
Thanks! I know very little lisp, but I am able to understand the gist of the
RATLIMfunction: to calculate a limitx -> 0(orx ->zeroa) of a rational function, we just need to know the coefficient of the lowest-order term in the numerator and denominator.I think the best option would be to modify the
locoeffunction to check whether the result is actually nonzero, and continue looking if it is not.Another alternative would be for
RATLIMto check whether(locoef n g)and(locoef d g)are zero. If one of them is 0, then the corresponding term can be deleted frome, andRATLIMcan be applied (recursively) to the modified expression.Or
RATLIMcould search through the numerator (and denominator) for a term that is not 0, but I think that such a search should be delegated tolocoef.PS: It seems to me that there is another (unrelated) bug in
RATLIM. Look at lines 3-4:This is supposed to convert a limit approaching
-infto a limit approaching 0 from the right. The transformation for this is-1/x, so I thinkm^t -1should be changed tom-. If this is indeed wrong, then I don't know why nobody has reported errors or incorrect results.I think I've made progress on the original problem by substituting 0 for the expression which was asked about, and then calling RATLIM on the result. That gives correct results for the cases mentioned in this bug report (although for the original problem,
limitneeds a hint in the form of a directionplusorminus, since otherwise it can't tell the right and left limits are the same; need to look at that more closely). I'll post more later.About the buggy code at lines 3 and 4, I agree that looks to be incorrect -- I think that should be
(m* -1 (m^t 'x -1)). However, it appears that's never executed, so it should either be corrected or expunged. I'll open a separate ticket about that.I don't think it's sufficient to try to fix the problem at the point where
RATLIMcurrently thinks the limit is 0 (although it would certainly be an improvement). For example, this limit should be 2 whenais 0, butRATLIMcurrently says that the limit is 1, whether there is an assumption or not (and will not ask any questions if you omit theassume):So it seems to me that it would be better to fix
locoef.I've filed that example as https://sourceforge.net/p/maxima/bugs/4006/
Dave, excellent observation about LOCOEF. You're right, the substitution approach doesn't get the right result for the example you showed above. I'll take another look at it -- @macrakis can I ask you to look at LOCOEF as Dave M. was suggesting yesterday (July 13)?
We need to follow through on several observations in this thread.
But at the risk of derailing following through, a simple way to make this bug disappear is to insert
trigexpandintogruntz1just before it callslimitinf.There might be a few more tweaks: insert code into
gruntz1for assumptions about the limit variable, for one. The gruntz code changes the limit point, so the limit code that does assumptions on the limit variable are out of date.Here I've pasted in a call to
trigexpandintogruntz1:After inserting
trigexpandintogruntz1, the functiongruntzis not able to compute this limit, but it does allowgruntz1to find some other limit that allowslimitto correctly return4m + 1.Inserting
trigexpandintogruntz1does not fix other bugs mentioned in this thread:Last edit: Barton Willis 2022-08-08