On Fri, Apr 23, 2010 at 6:47 AM, Sergey Bochkanov <[email protected]> wrote: > Hello, Antony. > > You wrote 23 апреля 2010 г., 16:18:02: > >> I think Java and Python bindings would be >> a very popular addition - python is used a lot in scientific >> computing. I believe there's already a wrapper for gmp? Gmpy? > > Yes, GMPY. I've never studied it deeply yet, but they pursue slightly > different goal: more Python-oriented interface, GMP (MPIR) itself is > hidden deep in the library's core. > > Af far as I understand their ideas, they want bignum library which > relies either on native Python bignum capabilities (=portability) or > on some hardware-optimized external library (+performance, > -portability). > > X-MPIR, from the other side, adds nothing to interface (in fact, it > drops several "hard" functions), but focuses on portability issues and > on "easy-to-install/use" approach. > > Can't decide what would be better - to implement "yet another Python > wrapper" with totally different interface and approach, or just to > help GMPY devs to solve portability issues. Or may be it is better to > do both :) > Hello,
I'm the current GMPY maintainer. GMPY provides a very Python-like interface to either GMP and MPIR. A gmpy.mpz should behave as closely as possible to a native Python bignum (i.e "long" in Python 2.x and the only integer type in Python 3.x). I've slowly been adding additional GMP/MPIR specific capabilites gmpy.mpz. A couple years ago, I experimented with a very thin Python wrapper that exposed the GMP API directly. There were a few issues: (1) Python numeric values are assumed to be immutable. If not, they cannot be used as dictionary keys. This forces all results to be new objects, hence source/destination operands cannot overlap, etc. (2) Python has a native bignum type and does not have the concept of a restricted range (i.e. C long) integer type. Anytime you accept a Python integer, you either need to just convert it to an mpz or test if it will fit in the _si/_ui range and call the appropriate function. (GMPY uses the later approach.) (3) It wasn't any faster. :( The current version of GMPY is 1.11 and it supports Python 2.4 and later, GMP 4.2.4 and later, and MPIR 0.9 and later. I will be releasing 1.12 soon to fix some minor issues. The current svn trunk has been renamed to gmpy2 and will only support Python 2.6 and later, GMP 5 and later, and MPIR 2 and later. There will be some API changes, especially to support for random numbers, and that motivated the name change. Most users will be able to use "import gmpy2 as gmpy" without any changes to their code. I do think a low-level wrapper would make it easier to test or prototype code before converting the code to C. Feel free to ask me any questions you might have. casevh > > -- > With best regards, > Sergey mailto:[email protected] > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" 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/mpir-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" 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/mpir-devel?hl=en.
