New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sympy.limit yields incorrect result #9075

Closed
cstoudt opened this Issue Feb 28, 2015 · 5 comments

Comments

Projects
None yet
5 participants
@cstoudt
Copy link
Contributor

cstoudt commented Feb 28, 2015

Python 2.7.9; SymPy 0.7.6

Consider the function g=(6**(n+1)+n+1)/(6**n+n) where x is real and n is an integer

It is easy to show that the limit of g as n->oo is 6

Yet, look at the output of the following code:

from sympy import symbols, limit, oo, Pow
n=symbols('n',integer=True)
x=symbols('x',real=True)
g=(Pow(6,n+1)+n+1)/(Pow(6,n)+n)
limit(g,n,oo)

out[4]: 1

@smichr

This comment has been minimized.

Copy link
Member

smichr commented Mar 1, 2015

Interestingly, if you make n positive

>>> n=symbols('n',integer=True,positive=True)
>>> limit(g,n,oo)
(6**(n + 1) + n + 1)/(6**n + n)
@raoulb

This comment has been minimized.

Copy link
Contributor

raoulb commented Mar 1, 2015

@cstoudt

This comment has been minimized.

Copy link
Contributor

cstoudt commented Mar 1, 2015

According to the documentation, limit uses some heuristics to solve the "easy" cases for speed, and uses the Gruntz algorithm for all other cases. So something is failing in the heuristics.

Interestingly, gruntz also fails for the case that smichr pointed out:

>>> from sympy.series import gruntz
>>> n=symbols('n',integer=True,positive=True)
>>> gruntz(g, n, oo)
(6**(n + 1) + n + 1)/(6**n + n)
@zanzibar7

This comment has been minimized.

Copy link
Contributor

zanzibar7 commented Mar 3, 2015

Bug traces back to atleast 0.7.2. Also in a reduced version...

In [3]: limit( (6**(n+1)+1)/(6**n+1), n, oo)
Out[3]: 1

Looks like the heuristic is equating n+1 and n when n is large.

@leosartaj

This comment has been minimized.

Copy link
Member

leosartaj commented Mar 20, 2015

On some debugging,
This is due to incorrect result by inve.as_leading_term(). It returns 1 rather than 6.
This is because in general

>>> (6**(n+1))._eval_leading_term(n)
1 # incorrect
>>>(6*6**n)._eval_leading_term(n)
6 # correct

This ultimately boils down to _eval_leading_term method in Pow.
I am working on this and will send a pull request shortly.

leosartaj added a commit to leosartaj/sympy that referenced this issue Mar 20, 2015

@cstoudt cstoudt closed this Jul 7, 2015

skirpichev added a commit to diofant/diofant that referenced this issue Feb 20, 2016

Removed is_Mul heuristics in Limit.doit()
This patch introduces a performance regression (very
non-trivial to fix), but given the number of bugs fixed and
that old heuristics was completely wrong - I believe this
is a fair trade.

Closes sympy/sympy#10610
Closes sympy/sympy#9075
(I don't think this is all, but who cares.)

Upabjojr added a commit to Upabjojr/sympy that referenced this issue Oct 3, 2017

Removed is_Mul heuristics in Limit.doit()
This patch introduces a performance regression (very
non-trivial to fix), but given the number of bugs fixed and
that old heuristics was completely wrong - I believe this
is a fair trade.

Closes sympy#10610
Closes sympy#9075
(I don't think this is all, but who cares.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment