On Wed, May 5, 2010 at 7:49 AM, Tim Joseph Dumol <t...@timdumol.com> wrote: > > > 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 disagree with that convention. There are thousands of places in Sage where we use a method with a leading _ outside of the class where the method is defined, and I think it makes good sense the way we use them. I would rather think of a leading _ as meaning "this method is meant to be used primarily internally in the Sage library and it has an API that is subject to change; if you want to use it in external code, do so at your own risk." > I'm not sure about the unsafe in the function name either. Should > this be relegated to the documentation? No, definitely, definitely not. When you read any code that uses these methods, it should be immediately clear that you're entering dangerous territory. The only way to do that reliably is by signaling this in the method name. Again, the use of unsafe in this way is something we've been doing in Sage for years. William > >> >> (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. >> >> > 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 > > > > -- > 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
