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
{{ message }}
Repository navigation
Elements of int64 array made from converting Python 2.x longs not int64 even though ndarray dtype is int64 #5801
This is in Python 2.x only since int and long got unified in 3.x.
I tested it in numpy 1.9.2 on CPython 2.6.6 and in numpy 1.8.2 on CPython 2.7.8.
It seems Numpy has a builtin ability to convert longs to ints and then to int64, which was a bit of a surprise really. But, it was after that that the real surprise came, which seems to be a Numpy bug.
If I make an ndarray from longs that are small enough to fit into int64 (none are larger than ``264), the array's dtype is int64, but if I extract an element from it and see if it is an int64, it fails.
The issue seems to be that PyLong objects are always converted to NPY_LONGLONG, even when it is the same size as NPY_LONG. You can check that with your example:
>>> import numpy as np
>>> a = np.array([2L])
>>> a.dtype.num
9
>>> np.dtype(np.int64).num
7
>>> np.dtype(np.longlong).num
9
I have fixed it in #5890, and it doesn't break anything in the tests. It's a scary change, though: hard to know what users may be expecting to happen. Lets see what other devs think of this.
I just checked the example and got that. That difference could be useful for some. For my code, I had another work around. For longs that are small enough (satisfy data <= 2**63 and data >= -(2**63 - 1) ), I convert to int explicitly first. For the longs that are too big or the Python 3.x ints, I convert to the string representation and store that (doing data storage stuff). Even though I had the work around, I figured I would mention this problem because someone else may stumble into it.
Thanks by the way for figuring out the problem. Looking at the pull request, it sure does look like it changes quite a few things.
Activity
jaimefrio commentedon May 18, 2015
The issue seems to be that
PyLongobjects are always converted toNPY_LONGLONG, even when it is the same size asNPY_LONG. You can check that with your example:I have fixed it in #5890, and it doesn't break anything in the tests. It's a scary change, though: hard to know what users may be expecting to happen. Lets see what other devs think of this.
frejanordsiek commentedon May 18, 2015
I just checked the example and got that. That difference could be useful for some. For my code, I had another work around. For longs that are small enough (satisfy
data <= 2**63 and data >= -(2**63 - 1)), I convert tointexplicitly first. For the longs that are too big or the Python 3.x ints, I convert to the string representation and store that (doing data storage stuff). Even though I had the work around, I figured I would mention this problem because someone else may stumble into it.Thanks by the way for figuring out the problem. Looking at the pull request, it sure does look like it changes quite a few things.
OmerJog commentedon Nov 12, 2019
Python 2 is EOL in a few months. I'm not sure this worth the time to try fixing it.
eric-wieser commentedon Dec 16, 2020
Note that this report does not apply to windows, wheresizeof long == sizeof interic-wieser commentedon Dec 16, 2020
Since we no longer support Python 2, this can be closed.