On Sun, Feb 3, 2013 at 1:10 PM, Aaron Meurer <[email protected]> wrote: > On Feb 3, 2013, at 1:31 PM, Case Van Horsen <[email protected]> wrote: > >> On Tue, Jan 29, 2013 at 12:16 AM, Aaron Meurer <[email protected]> wrote: >>> On Mon, Jan 28, 2013 at 10:26 PM, Case Van Horsen <[email protected]> wrote: >>>> On Mon, Jan 28, 2013 at 8:45 PM, Aaron Meurer <[email protected]> wrote: >>>>> On Jan 28, 2013, at 8:54 PM, casevh <[email protected]> wrote: >>>>> >>>>> Hello, >>>>> >>>>> I maintain GMPY and GMPY2 and I'd like to provide a patch to resolve >>>>> compatibility issues with GMPY2. >>>>> >>>>> The most significant difference is that support for mpq.numerator and >>>>> mpq.denominator was added in GMPY 1.13 and is available in GMPY2 (and in >>>>> Python's standard Fraction type). The code in polys uses the old >>>>> mpq.numer() >>>>> and mpq.denom() functions that were removed in GMPY2. Would it be >>>>> acceptable >>>>> to change the minimum version of GMPY to 1.13 from 1.03? Then the >>>>> mpq.numer() calls could be changed to mpq.numerator, etc. >>>>> >>>>> >>>>> Absolutely. Gmpy is an optional dependency, so supporting only the latest >>>>> version is fine. And unlike supporting old versions of Python or IPython, >>>>> old versions of gmpy are likely to lead to wrong result errors >>>>> (assumedly). >>>> >>>> GMPY 1.13 was released in 2010 and was one of the first versions that >>>> supported Python 3.x well. There have only been a few bug fixes since >>>> then to the 1.x series. >>>> >>>>> >>>>> What is the difference between numerator and numer? >>>> >>>> numer() is a function that lives in both the "gmpy" namespace and is >>>> also available as a method of an mpq instance. numerator was >>>> introduced as an attribute of Python's Fraction and integer types in >>>> 2.5 (IIRC) as part of the abc numerical tower. I added >>>> numerator/denominater as mpq attributes in 1.13. In the 2.x series, I >>>> removed numer() and denom() as methods on an mpq instance and made >>>> sure the attribute lookups were present. The numer() and denom() >>>> functions are still present. The attribute lookups are slightly >>>> faster, too. >>> >>> I believe it was actually 2.6. But don't worry if gmpy can't work in >>> Python 2.5. Neither does IPython, and we will probably drop 2.5 >>> support either in the next release or the one after it (depending on >>> how soon we release again). >>> >>>> >>>>> >>>>> By the way, I was planning in applying your patch fixing the version >>>>> check, >>>>> but I haven't gotten around to it. So if you want to do that as well, go >>>>> ahead. >>>> >>>> The patch is correct for mpmath, but it breaks code in the polys >>>> module. I'll work on a complete patch. >>> >>> Great. By the way, what is the status of gmpy2? Should be looking to >>> support that as well (or instead of gmpy1)? >> >> For integer and rational support, gmpy2 is stable. gmpy2 also wraps >> the MPFR and MPC libraries but the API may change. Since sympy uses >> mpmath for real and complex arithmetic, I don't sympy needs gmpy2's >> new features. I'm confident I can make any version >= 1.13 work. >> >> Here is an update on my progress. >> >> I found gmpy imported twice in sympy code and either gmpy2 or gmpy >> imported in mpmath. As an experiment, I imported gmpy2 or gmpy in >> sympy.core.compatibility and then tweaked the other import locations. >> This did work, but I think I'll follow a different approach (see >> below). >> >> The majority of the remaining changes were (1) replacing mpq.numer() & >> mpq.denom() with mpq.numerator and mpq.denominator and (2) replacing >> changing the qdiv() method calls to gmpy.qdiv() function calls. (gmpy >> duplicated almost all function calls with method calls; gmpy2 removes >> most of duplicate method calls). >> >> There are still a few subtle issues. 'bitcount' is directly imported >> from mpmath. The pure Python version of bitcount works with a sympy >> Integer, but the gmpy version does not. I created a simple wrapper >> function that returns mpmath_bitcount(int(a)). Is that the recommended >> way to force an Integer to an int or is there a different strategy I >> should follow? > > That should work. If you know it's always an Integer, a.p is probably > a little faster. > >> >> I've also found code in scaled_zero that does "type(mag) is int". This >> fails when gmpy is used since the type is actually an mpz. This could >> also fail if mag is a long on Python 2.x. mpmath uses a tuple call >> int_types that contains all the low-level integer types - the >> appropriate combination of int, long, and mpz. I just imported >> int_types from mpmath and changed the code to "type(mag) in int_types" >> in the various places I found an "is int:" fragment. I made this >> change aggressively and didn't check that is caused an issue with gmpy >> since it could also trigger a bug with Python 2.x. > > These "type is" calls should actually use isinstance. And we've been > hit before with bugs from not checking for long.
I'll change the ones encounter to use isinstance. > >> >> core/numbers.py also uses isinstance(n, (int, long, Rational)) which I >> changed. >> >> I'm down to one failed test to resolve. >> >> Given the dependencies on mpmath's int_types, I think I'll change my >> approach to use mpmath's version of gmpy throughout. This will require >> that (1) mpmath gets imported before anything else that uses gmpy (I >> think that is true) and (2) the minimum version check in mpmath needs >> to be changed. > > Ok, but make sure that setting the ground types to Python still > disables gmpy in the polys, and conversely, disabling gmpy in mpmath > (I think there's some environment variable) doesn't disable it in the > polys. Just curious: why wouldn't you use a common base integer type in both polys and mpmath? I would be concerned with accidentally leaking base types between polys and mpmath. Do you consistently convert to a Python type when interfacing between the two (or does interfacing the base types rarely happen)? casevh > > Aaron Meurer > >> >> Regards, >> casevh >> >>> >>> Aaron Meurer >>> >>>> >>>>> >>>>> Aaron Meurer >>>>> >>>>> >>>>> I've resolved most of the other remaining issues but there are a couple >>>>> that >>>>> I'm still tracking down. I just want to verify that upgrading the minimum >>>>> version to 1.13 is acceptable. >>>>> >>>>> Regards, >>>>> casevh >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "sympy" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send an >>>>> email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at http://groups.google.com/group/sympy?hl=en. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "sympy" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send an >>>>> email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at http://groups.google.com/group/sympy?hl=en. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "sympy" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/sympy?hl=en. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sympy" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/sympy?hl=en. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/sympy?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
