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_info
reports in part:Looks like the result is coming out of TAYLIM (Lisp function for Taylor limit).
taylor
is returning something that looks likestuff/x + constant + (more stuff times powers of x)
wherestuff
is the term whichasksign
was 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
zero
toasksign
.Here's what I'm seeing. Current Git version as noted above.
limit
seems 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
n
for4*m + 1
. I callratdisrep
in betweentaylor
andlimit
because 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 respondz
to "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
RATLIM
function: 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
locoef
function to check whether the result is actually nonzero, and continue looking if it is not.Another alternative would be for
RATLIM
to 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
, andRATLIM
can be applied (recursively) to the modified expression.Or
RATLIM
could 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
-inf
to a limit approaching 0 from the right. The transformation for this is-1/x
, so I thinkm^t -1
should 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,
limit
needs a hint in the form of a directionplus
orminus
, 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
RATLIM
currently thinks the limit is 0 (although it would certainly be an improvement). For example, this limit should be 2 whena
is 0, butRATLIM
currently 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
trigexpand
intogruntz1
just before it callslimitinf.
There might be a few more tweaks: insert code into
gruntz1
for 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
trigexpand
intogruntz1
:After inserting
trigexpand
intogruntz1
, the functiongruntz
is not able to compute this limit, but it does allowgruntz1
to find some other limit that allowslimit
to correctly return4m + 1.
Inserting
trigexpand
intogruntz1
does not fix other bugs mentioned in this thread:Last edit: Barton Willis 2022-08-08