8000 numpy.take fails with int64 dtype on i386 architecture · Issue #11696 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

numpy.take fails with int64 dtype on i386 architecture #11696

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
rth opened this issue Aug 9, 2018 · 2 comments
Closed

numpy.take fails with int64 dtype on i386 architecture #11696

rth opened this issue Aug 9, 2018 · 2 comments

Comments

@rth
Copy link
Contributor
rth commented Aug 9, 2018

numpy.take fails with int64 dtype on i386 architecture

Reproducing code example:

import numpy as np
x = np.arange(10, dtype='int64')
index = np.arange(3, dtype='int64')
x.take(index)

Expected output:

array([0, 1, 2])

is obtained on 64 bit architecture

Error message:

On 32 bit Debian Linux, I get,

>>> x.take(index)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Cannot cast array data from dtype('int64') to dtype('int32') according to the rule 'safe'

On 32 bit windows, the same result was indirectly illustrated in scikit-learn/scikit-learn#11295 (comment)

Numpy/Python version information:

>>> import sys, numpy; print(numpy.__version__, sys.version)
1.14.5 3.6.6 (default, Jun 27 2018, 14:44:17) 
[GCC 8.1.0]

Generally this was run in the debian unstable i386 Docker image, with the following setup,

Dockerfile 
FROM i386/debian:unstable

RUN apt-get update && apt-get install -y build-essential git make

RUN apt-get install -y python3 python3-scipy python3-numpy python3-setuptools python3-pkg-resources python3-pip
@rth rth mentioned this issue Aug 9, 2018
Merged
@eric-wieser
Copy link
Member
eric-wieser commented Aug 9, 2018 •
edited
Loading

Arguably this is by design. If you're indexing with a type bigger than np.intp, then it's possible to overflow, and you don't want that.

From that, it follows that you should really just use np.intp to store indices. Internally, this may save a bunch of copies in numpy anyway

@rth
Copy link
Contributor Author
rth commented Aug 9, 2018

OK, makes sense. Thanks @eric-wieser !

@rth rth closed this as completed Aug 9, 2018
@toddrme2178 toddrme2178 mentioned this issue Feb 5, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@eric-wieser @rth
0