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
numpy.eye raises TypeError on numpy.uint64 input #9982
Output: TypeError: slice indices must be integers or None or have an __index__ method on line 187 of numpy/lib/twodim_base.py (corresponds to line 188 of master branch)
If it helps, I'm using the latest Anaconda version on macOS High Sierra.
From what I could tell, there was a subtraction, and a cast happening to do that safely which cast it to a floating-point datatype of some kind to be able to support the range. And the float didn't have an __index__ method.
Yes, that makes sense. I suppose the fix would be to convert the arguments to int up front. It is likely that this is not the only place where this problem occurs ...
As a hackish solution it will work, since on all computers if you view it as int64 it will still be the correct numbers (assuming they are not too large). What I mean is using arr.view("int64")
In all cases where we are concerned, that should be fine. That big of an index (one that won't fit in int64 but will fit in uint64) is probably only possible in sparse arrays anyway.
Edit: If we're looking for a bigger range, wouldn't arr.view('int') do the trick?
@hameerabbasi you can view the uint as the appropriate int as long as the uint is not too large. In general if you got a uint64 you have to use an int64 of course. Numpy has nothing larger then (u)int64.
Generally, np.intp (which is an int64 on 64bit systems) is always large enough to hold a valid dimension/index into any array. But if you start of with any uint, of course you cannot in generally "view" it as an int without the risk of negative numbers appearing, and you always have to view it as int of the same size.
(int itself without an undscore, so not int_ in numpy is actually a C long which is 64bits on 64bit linux and otherwise 32bits, so especially for apps that run on windows and linux it is not even a reliable type at all)
(sorry to spam the issue a bit). Well np.int on python3 is, but np.int is int and it is silly (it should rather not exist). If you do np.asarray(..., dtype=int) then it acts like I described.
Activity
charris commentedon Nov 7, 2017
Curious
The
int64type works fine, so it has something to do with unsigned. I think the error message is probably misleading.hameerabbasi commentedon Nov 7, 2017
From what I could tell, there was a subtraction, and a cast happening to do that safely which cast it to a floating-point datatype of some kind to be able to support the range. And the float didn't have an
__index__method.charris commentedon Nov 7, 2017
Yes, that makes sense. I suppose the fix would be to convert the arguments to int up front. It is likely that this is not the only place where this problem occurs ...
hameerabbasi commentedon Nov 7, 2017
That could be problematic in other cases where the argument is a huge array and copying it would require a lot of memory.
seberg commentedon Nov 7, 2017
As a hackish solution it will work, since on all computers if you view it as int64 it will still be the correct numbers (assuming they are not too large). What I mean is using
arr.view("int64")hameerabbasi commentedon Nov 7, 2017
In all cases where we are concerned, that should be fine. That big of an index (one that won't fit in
int64but will fit inuint64) is probably only possible in sparse arrays anyway.Edit: If we're looking for a bigger range, wouldn't arr.view('int') do the trick?
seberg commentedon Nov 7, 2017
@hameerabbasi you can view the uint as the appropriate int as long as the uint is not too large. In general if you got a uint64 you have to use an int64 of course. Numpy has nothing larger then (u)int64.
Generally,
np.intp(which is an int64 on 64bit systems) is always large enough to hold a valid dimension/index into any array. But if you start of with any uint, of course you cannot in generally "view" it as an int without the risk of negative numbers appearing, and you always have to view it as int of the same size.seberg commentedon Nov 7, 2017
(
intitself without an undscore, so notint_in numpy is actually a Clongwhich is 64bits on 64bit linux and otherwise 32bits, so especially for apps that run on windows and linux it is not even a reliable type at all)hameerabbasi commentedon Nov 7, 2017
I assumed that 'int' would be a normal Python 3 big integer, independent of platform. My mistake.
seberg commentedon Nov 7, 2017
(sorry to spam the issue a bit). Well
np.inton python3 is, butnp.int is intand it is silly (it should rather not exist). If you donp.asarray(..., dtype=int)then it acts like I described.eric-wieser commentedon Nov 13, 2017
An easy fix would be to do
N, M = m.shape, which handles the conversion tointfor us.Of course, we still need to convert
k, which we could do withoperator.indexBUG: lib: Allow type uint64 for eye() arguments.
BUG: lib: Allow type uint64 for eye() arguments.
BUG: lib: Allow type uint64 for eye() arguments.