Bug#805264: What I expected to to happen with gmpy2.mpz/gmpy2.xmpz

2015-11-16 Thread David George Henderson III
What I'm attempting to do is perform a dot product of an int32 array 
with a list of mpz integers.


z=np.zeros(10,np.int32)
y=[gmpy.mpz[1] *10 ]

summation = gmp.xmpz(0)
for i in range(0,10):
product = gmpy2.xmpz(z[i])
product *= y[i]
summation += product

The bug prevents this from running.

My workaround defeats the purpose of using gmpy2.xmpz typed variables :

for i in range(0,10):
product = gmpy2.xmpz(int(z[i]))



Bug#805264: What I expected to to happen with gmpy2.mpz/gmpy2.xmpz

2015-11-16 Thread Martin Kelly
On Mon, 16 Nov 2015 10:36:21 -0800 David George Henderson III
 wrote:
> What I'm attempting to do is perform a dot product of an int32 array 
> with a list of mpz integers.
> 
> z=np.zeros(10,np.int32)
> y=[gmpy.mpz[1] *10 ]
> 
> summation = gmp.xmpz(0)
> for i in range(0,10):
>  product = gmpy2.xmpz(z[i])
>  product *= y[i]
>  summation += product
> 
> The bug prevents this from running.
> 
> My workaround defeats the purpose of using gmpy2.xmpz typed variables :
> 
> for i in range(0,10):
>  product = gmpy2.xmpz(int(z[i]))
> 
> 
> 
> 

Hi,

Thanks for your bug report. I'm not surprised that gmpy2.[x]mpz doesn't
have a constructor for handling the numpy int32 type; to do so would
likely require gmpy to link against numpy, introducing an undesired
dependency into the library. I'm guessing that exporting the int32 to
standard Python int will be your best bet, as int32 and mpz are
different objects. Is this causing a performance bottleneck?

This issue is present in current versions of gmpy (2.0.7) as well as the
2.0.3 version you reported against. You may consider raising it with
upstream gmpy on github:

https://github.com/aleaxit/gmpy

Regards,
Martin