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? > (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... > (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? 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). 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. -- 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.