On Mon, Apr 26, 2010 at 9:55 PM, William Stein <wst...@gmail.com> wrote:
> 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 > This is odd. From their names one would expect them to be used in __imul__ and __iadd__ somewhere in the hierarchy, just like _repr_ is used in __repr__, so that they will be used for: sage: a = 1 sage: a*=5 as documented here: http://docs.python.org/reference/datamodel.html. However, this is not the case. It may be a bug (or yet to be implemented feature). > > > >> (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<mpir-devel%2bunsubscr...@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 > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com<sage-devel%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- Tim Joseph Dumol <tim (at) timdumol (dot) com> http://timdumol.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
