On Jun 3, 9:12 am, casevh <[email protected]> wrote: > Other than bug-fixes for gmpy, should we move all future development > to a Cython-based wrapper?
+1 > I do not like the GMP mpf type. Should gmpy try to support MPFR? (You could use the future mpmath Cython mpf type, which will provide correct rounding without MPFR's limitations.) How would you feel about extending gmpy a bit to not just wrap GMP/ MPIR? SymPy is getting a Cython core (if Ondrej finds time to work on this). Also, mpmath is getting a Cython backend (I'm working on this). Both will need fast integers, rationals, and arbitrary-precision floats. One option would be to do a single core library for the number types, extending (rather rewriting, if it's going to be done in Cython) gmpy. Done right, mpmath and SymPy should be able to subclass directly from the basic types (and/or use them with appropriately chosen context objects). For example, mpq(2,3) ** mpq(1,2) could be implemented to call mpq._irrational_exponentiation(x,y) which by default would raise NotImplementedError; mpmath would override this to return a numerical approximation, and SymPy would override it to return a symbolic object. We could provide both a pure Python reference implementation (based on mpmath and SymPy cores, and my module libarith.py), for default use by mpmath and SymPy, and a fast Cython version wrapping MPIR/GMP. This could potentially avoid duplication of features (and the need for multi-way coercion code between libraries). Fredrik --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sympy?hl=en -~----------~----~----~----~------~----~------~--~---
