On Mon, Apr 26, 2010 at 1:08 AM, Sergey Bochkanov <sergey.bochka...@alglib.net> wrote: > Hello, Case. > > You wrote 23 апреля 2010 г., 19:30:20: > >> (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. > > It is problem only when you want mpz/mpq to be value type. However, > they can be reference types too. > > I know that it may be considered non-Pythonic, but such approach is > much more efficient. And I think that output from high performance > library like GPM/MPIR will very rarely be used as dictionary key. > > What do you think about such data model - reference mpz/mpq types?
+1 Sage contains a Cython-based wrapper for GMP/MPIR, which has nothing to do with GMPY (i.e., it is separate code). The lack of support for mutable operations in GMPY is a drawback for it is a library, since nobody uses MPIR unless they seriously care about speed. In Sage we do not have any explicit methods that mutate integers. We do have two underscore methods, though, _iadd_ and _imul_, which mutate self, since it is necessary to have such things to write really fast code, though of course one must be very careful when using them: sage: a = 2010 sage: a._imul_(19) sage: a 38190 I noticed that in Sage these are sadly undocumented, so opened a ticket: http://trac.sagemath.org/sage_trac/ticket/8766 >> (2) ..... 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.) > > Very serious problem. And what should we do if we have Python-long > which doesn't fit into 32 bits? > > We can't transparently convert it into the mpz and call another > function because: a) it is hard to implement such semantics, > especially within automatic code generation framework, and b) > sometimes xxx_ui functions have slight differences from their mpz/mpq > counterparts. > > I think that the only thing possible is to raise an exception in such > cases. But it may be non-Pythonic too... In Sage we (=mostly Gonzalo Tornaria) spent an enormous amount of time writing two very efficient C functions, one to convert from mpz to Python ints, and one to convert back. Yes, writing this code is a lot of work. But no, the resulting code is not slow. Just because something is hard doesn't mean "we can't do it". If you want this code, I bet Gonzalo would be OK with letting you have it under another license (it's GPL v2+ right now); it's not long, just tricky to write. > >> (3) It wasn't any faster. :( > > What kind of tests you made? Have you tested it with relatively small > integers (up to 128 bits) or with really large ones? GMP/MPIR blow native python ints out of the water for asymptotically large input. Already with 4 words the difference starts to get noticeable. > > I think that low speed may be caused mostly by creation of new objects > after each operation (1) and (to a lesser extent) by conversion > penalty (2). Yes. > However, when you work with really large numbers > (thousands of bits) MPIR should be significantly faster than Python > native implementation of long. I've found mpmath benchmark at > http://mpmath.googlecode.com/svn/bench/mpbench.html which confirms > this opinion. +1 > > > > -- > With best regards, > Sergey mailto:sergey.bochka...@alglib.net > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to mpir-de...@googlegroups.com. > To unsubscribe from this group, send email to > mpir-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
