Comment #4 on issue 1946 by asmeurer: Recursion error with
SYMPY_GROUND_TYPES=sympy (caching problem)
http://code.google.com/p/sympy/issues/detail?id=1946
The problem could also be because of the logic in Integer.__eq__():
def __eq__(a, b):
if type(b) is int:
return (a.p == b)
elif isinstance(b, Integer):
return (a.p == b.p)
return Rational.__eq__(a, b)
The last line is being called in the traceback. The problem is that this
doesn't take into account that b could be a
long (which a print statement reveals it is for this particular error).
For example, the following also fixes the
bug:
diff --git a/sympy/core/numbers.py b/sympy/core/numbers.py
index 34502eb..610acd5 100644
--- a/sympy/core/numbers.py
+++ b/sympy/core/numbers.py
@@ -897,7 +897,7 @@ def __rmul__(a, b):
# def __cmp__(a, b):
def __eq__(a, b):
- if type(b) is int:
+ if type(b) in (int, long):
return (a.p == b)
elif isinstance(b, Integer):
return (a.p == b.p)
Also, for the second conditional, it doesn't consider S.One, S.NegativeOne,
or S.Zero, which are sympified
integers but not Integer's. Probably this turned up in the polys because
it is one of the few places in the test
suite that uses enough sympified long integers to overflow the cache when
it uses
SYMPY_GROUND_TYPES=sympy. Also, it looks like this only fails in 32-bit
(which is probably how it slipped by),
because smaller integers like 27948966042 (the problem integer in this
case) are not long in 64-bit.
I am +1 on Mateusz's patch. We should push that in regardless of other
fixes.
--
You received this message because you are subscribed to the Google Groups
"sympy-issues" group.
To post to this group, send email to sympy-iss...@googlegroups.com.
To unsubscribe from this group, send email to
sympy-issues+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy-issues?hl=en.
