On Fri, Apr 23, 2010 at 8:30 AM, Case Vanhorsen <[email protected]> wrote: > 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. >> >> >
BTW, the current home for GMPY is http://code.google.com/p/gmpy/ The old source forge site is obsolete. -- 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.
