On Mon, Apr 26, 2010 at 6:55 AM, 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 > > >>> (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. I'm using this code already (Thanks Gonzalo!). I normally use the PyLong_AsLongAndOverflow to check if a PyLong can be converted to a C-long. If it fails, it doesn't generate an exception, it just sets a variable. It is quicker than letting an exception occur. I provided a PyLong_AsLongLongAndOverflow back to Python and it will be added to Python 2.7 and 3.2. That will make support for Windows x64 a lot easier. > >> >>> (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. > >
casevh -- 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.
