On Wed, May 5, 2010 at 1:53 AM, Tim Joseph Dumol <t...@timdumol.com> wrote: > > > 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).
That is not a bug -- it is done on purpose. The reason is because integers are meant to be *immutable*, since they have a hash method. If _imul_ were used by __imul__, then people would be mutating integers left and right by accident, and vast amounts of code would consequently have subtle bugs all over the place. There might have been a time (maybe a few weeks in 2006) when __imul__ did indeed call _imul_ in Sage, so the name might be a historical remnant. Personally, I think the best thing would be: (1) Rename _imul_ and _iadd_ to something like _unsafe_inplace_mul_, _unsafe_inplace_add_ (2) Document them. William > >> >> >> (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 >> >> -- >> 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 > > > > -- > 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 > -- 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 For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
