On Wed, May 5, 2010 at 8:31 PM, William Stein <wst...@gmail.com> wrote:
> 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_ > > I'm not sure it's Pythonic to have underscores in the function name. Having underscores means that it's a private function, to be only used within the class [1]. I'm not sure about the unsafe in the function name either. Should this be relegated to the documentation? [1] http://www.python.org/dev/peps/pep-0008/ > (2) Document them. > > +1 > 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<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<sage-devel%2bunsubscr...@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<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
