andyvand / gmpy

Automatically exported from code.google.com/p/gmpy
GNU Lesser General Public License v3.0
0 stars 0 forks source link

Python 3.3 64: there is no analog for GMP mpz_mul_2exp #80

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
At least in Python 3.3 64 with gmpy2-3.3-64: there is no analog for GMP 
mpz_mul_2exp

What steps will reproduce the problem?
at Python prompt (>>>) type:
import gmpy2; from gmpy2 import mpz
a = mpz(4096); gmpy2.mpz_mul_2exp(a, 4)

Expected output is mpz(65536)
Instead of that I got mpfr('1.6069380442589903e+60')

I.e. I intend to work with integers but suddenly got fractional. Should I use 
standart Python << operator? Will there be a significant time penalty? (This 
left shift function will be in an inner cycle of very computationally loaded 
algorythm with integer numbers of magnitude between thousands to millions bits)

Win7 64 amd Phenom 64 4 cores Python 3.3 64 amd-win

Original issue reported on code.google.com by albert.k...@gmail.com on 25 Oct 2013 at 4:28

GoogleCodeExporter commented 9 years ago
erroit in reproduction of yhe issue: use
gmpy2.mul_2exp(a, 4)

Original comment by albert.k...@gmail.com on 25 Oct 2013 at 4:30

GoogleCodeExporter commented 9 years ago
Actually, I need not at all shifts. As I think, GMP does some like pointer 
rearrangement if the sgift value alighs byte border. So that instead of >> 1024 
times we can just copy byte sequense started from (byrt pointer + 1024/8)
Sincerely, Albert

Original comment by albert.k...@gmail.com on 25 Oct 2013 at 4:35

GoogleCodeExporter commented 9 years ago
The << and >> operators call mpz_mul_2exp and mpz_fdiv_q_2exp so they work 
efficiently. The overhead is less for using <</>> versus calling a function. 
The difference is probably not relevant for such large numbers. You can also 
use f_div_2exp for division by a power of 2. The leading f_ implies floor 
division. There are also ceiling division (c_) and truncating division (t_).

If your calculations primarily use in-place operators (+=, <<=, etc.), the xmpz 
type may e slightly faster. The xmpz type is mutable (the value can change 
without creating a new object). In some circumstances they are faster but they 
can't be used as a key in a dictionary. If you use an xmpz type with normal 
operations (=, <<, etc.), the result will be an mpz. xmpz type also supports 
inplace bit manipulation using the standard slice notation.

Original comment by casevh on 26 Oct 2013 at 12:31

GoogleCodeExporter commented 9 years ago
Closing.

Original comment by casevh on 4 Nov 2013 at 4:52