You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The bit-wise & operator works fine with all Numpy integer types, except uint64:
In [13]: np.int64(123) & 0xffff
Out[13]: 123
In [14]: np.uint64(123) & 0xffff
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
/Volumes/Raptor/<ipython-input-14-42f055b9f958> in <module>()
----> 1 np.uint64(123) & 0xffff
TypeError: ufunc 'bitwise_and' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule 'safe'
Even Python long integers can be used, so is there a reason why np.uint64 cannot be used, or is it a bug?
Looks like 0xffff is treated as signed and the ufunc machinery is looking for a larger signed type the will hold uint64. This isn't easy to fix without a major rework of some of numpy's internals. There is a work around
In [2]: np.uint64(123) & np.uint64(0xffff)
Out[2]: 123
I think this should work also, so perhaps there is something that needs a fix.
In [4]: np.bitwise_and(np.uint64(123), 0xffff, casting='unsafe')
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
/home/charris/<ipython-input-4-33ccdd6698ae> in <module>()
----> 1 np.bitwise_and(np.uint64(123), 0xffff, casting='unsafe')
TypeError: ufunc 'bitwise_and' not supported for the input types, and the
inputs could not be safely coerced to any supported types according to the casting rule ''safe''
importnumpyasnpa=np.ones(2, dtype=np.uint64)
# this worksa&1# but thisa[0]&1# gives this error#---------------------------------------------------------------------------#TypeError Traceback (most recent call last)#<ipython-input-43-e0a82b0140e0> in <module>()#----> 1 a[0]&1##TypeError: ufunc 'bitwise_and' not supported for the input types, and the#inputs could not be safely coerced to any supported types according to the#casting rule ''safe''## but this worksa=np.ones(2, dtype=np.uint32)
a[0]&1
Activity
charris commentedon Feb 1, 2013
Looks like 0xffff is treated as signed and the ufunc machinery is looking for a larger signed type the will hold uint64. This isn't easy to fix without a major rework of some of numpy's internals. There is a work around
I think this should work also, so perhaps there is something that needs a fix.
jrmlhermitte commentedon Nov 15, 2017
Same problem. Broadcasting to array also works
workaround also works for me.
Is there a PR for this yet?
seberg commentedon Nov 19, 2022
Closing as duplicate of gh-22624