Repository navigation
shift operator does not work with numpy arrays with dtype=uint64 #5668
Description
I have tested the following python code on 64 bit Windows 7:
import sys
print "python version is:\n", sys.version
import numpy as np
print "numpy version is:\n", np.version.version
a = np.array([1,3], dtype = np.int64)
print "a[1] is:", a[1]
print "type of a[1] is", type(a[1])
print "a[1] << 1 is:", a[1] << 1 # works fine for dtype = int64
u = np.array([1,3], dtype = np.uint64)
print "u[1] is:",u[1]
print "type of u[1] is", type(u[1])
print "u[1] << 1 is:", u[1] << 1 # but for dtype = uint64 there is a problem
This script produces the following output:
python version is:
2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]
numpy version is:
1.8.1
a[1] is: 3
type of a[1] is <type 'numpy.int64'>
a[1] << 1 is: 6
u[1] is: 3
type of u[1] is <type 'numpy.uint64'>
u[1] << 1 is:
Traceback (most recent call last):
File "test_uint64_array.py", line 12, in
print "u[1] << 1 is:", u[1] << 1
TypeError: ufunc 'left_shift' not supported for the input types, and the inputs
could not be safely coerced to any supported types according to the casting rule ''safe''
I can do my job with int64 instead of uint64. I just want to report this problem.
Activity
jaimefrio commentedon Mar 11, 2015
It seems to be an issue with array scalar, not ndarrays:
mcara commentedon Mar 24, 2017
@jaimefrio wrote:
I disagree... Here are a couple of counter examples:
Even more interesting:
mhvk commentedon Mar 24, 2017
@mcara, - I think your examples confirm what @jaimefrio stated: only for
uint64scalars is this a problem, and only if you use as a the shift something that could have a sign. This probably implies that it tries to promote theuint64number to something signed (which would befloat64), and, since this doesn't happen for arrays, that the casting rules for arrays and scalars must have gone out of sync.eric-wieser commentedon Mar 24, 2017
Sounds like #8809 to me
The killer combination seems to be
uint64 (scalar) << inthere.mcara commentedon Mar 24, 2017
@mhvk I missed that the title already restricted the problem to
uint64. Sorry.mcara commentedon Mar 24, 2017
I see quite a few issues with
uint64and all of them seem to be "related":#5745, #7126, #4151, #2955, #2524 (since 2012!), #8002 - all open.
mcara commentedon Mar 24, 2017
The following example shows that the vice versa holds true:
mhvk commentedon Mar 24, 2017
I think the problem in all cases is the promotion to
float64(which looks at both arguments and is independent of the actual function; for other functions, though, the float operation is defined). What I don't understand is why it doesn't happen for arrays...Actually, this is not quite true:
So I suspect the difference is that for the array case, the
1gets translated into an array with dtypenp.uint64, while for the scalar case it is not. Indeed, when for the array case I select a negative integer, which cannot be represented asuint64, aTypeErrorensues.Anyway, the conclusion seems to be that for the array scalar case, the cast from python int is done differently than for the array case.
seberg commentedon Jan 28, 2024
This is related to NEP 50, which is/will fixed in main/NumPy 2.0, so closing.