testing limit of n*tan(pi/n) results in incorrect answer in 1.7rc1+

[chrisjohgorman]

from future import division
from sympy import *
x, y, z, t = symbols('x y z t')
k, m, n = symbols('k m n', integer=True)
f, g, h = symbols('f g h', cls=Function)
init_printing()
A_n = n*tan(pi/n)
limit(A_n, n, oo)

The result should be pi, but sympy returns 0 in versions later than 1.6.2. I used maxima and live.sympy.org to confirm the correct answer.

A git bisect between 1.6.2 and 1.7rc1 returns '[267a4fd] Using is_meromorphic() for limit evaluations' as the commit which causes the break.

Let me know if you need more information on this.

[anutosh491]

Is it happening that way , I get the correct result through current master

>>> limit(x*tan(pi/x) , x, oo)
pi

[dhananjaypai08]

When integer set to true it does give us 0 else it doesn't

[anutosh491]

When integer set to true it does give us 0 else it doesn't

Okay I'll look into the error here , thanks for mentioning this !
EDIT1: What goes wrong here is some intermediate evaluations are taking place . Consider this

>>> n = Symbol('n', integer=True)
>>> n*tan(pi/n)
n*tan(pi/n)
>>> _.subs(n, 1/n)
0

The error happening here is that tan(pi*n) evaluates to 0 when n is integer , hence what is being computed is n*0 , giving us back 0.
This intermediate evaluation on line 277 of limits.py should be taken care of !!

[jksuom]

It seems that discrete (integer) variables like n should be replaced by continuous (preferably real) variables when computing limits. Maybe something like this:

--- a/sympy/series/limits.py
+++ b/sympy/series/limits.py
@@ -216,6 +216,12 @@ def doit(self, **hints):
             raise NotImplementedError("Limits at complex "
                                     "infinity are not implemented")
 
+        if z.is_integer:
+            from sympy.core import Dummy
+            x = Dummy('x', real=True)
+            e = e.subs(z, x)
+            z = x
+
         if hints.get('deep', True):
             e = e.doit(**hints)
             z = z.doit(**hints)

[anutosh491]

It seems that discrete (integer) variables like n should be replaced by continuous (preferably real) variables when computing limits. Maybe something like this:

True , I agree with this logic, someone should run the series tests to confirm this . Maybe we could find some failing tests specially in test_limitseq.py as that mainly deals with limits where we use integer variables or something like n = Symbol('n', integer=True)

[chrisjohgorman]

Sorry for the delay in replying. Thank you for the clarification on the reason for the error. This could be seen as an error in my use of integer variables with limits. I now know not to use integers with limits. Thanks.

…

On Wed, Apr 6, 2022 at 3:11 AM Anutosh Bhat ***@***.***> wrote: It seems that discrete (integer) variables like n should be replaced by continuous (preferably real) variables when computing limits. Maybe something like this: True , I agree with this logic, someone should run the series tests to confirm this . Maybe we could find some failing tests specially in test_limitseq.py as that mainly deals with limits where we use integer variables or something like n = Symbol('n', integer=True) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>