Skip to content

npy_format_descriptor may not be accurate for platform-dependent lengths of short, long, and long long #1328

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.

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

Closed
EricCousineau-TRI opened this issue Mar 20, 2018 · 1 comment · Fixed by #1329

Comments

@EricCousineau-TRI
Copy link
Collaborator

Ran into this via an esoteric route: When tinkering with user-defined dtypes, it seems that implementation of np.ones uses np.copyto(dst, 1, casting='unsafe'), where the 1 gets interpreted as np.array(1, dtype=np.int64) (at least, on my platform).

When I tried registered a caster using npy_descriptor_format<int64_t>::dtype() using the type_num field, I realized its value was for NPY_LONGLONG, whereas NPY_INT64 corresponds to NPY_LONG.

Will try to see if I can create a failing test, and then submit a tentative fix PR based on that.

@EricCousineau-TRI
Copy link
Collaborator Author

EricCousineau-TRI commented Mar 20, 2018

Yup, could reproduce the issue, using the latest master (6d0b470):
EricCousineau-TRI/repro@de9c086#diff-9885f7c92e2882fb9307118ce30b0aa7

Output on my machine:

9   <-- What pybind11 reports as the dtype for `int64`
9
7
7
7   <-- What NumPy says is the dtype for the `NPY_INT64` alias

NumPy info (using it from Ubuntu 16.04):

>>> import numpy as np
>>> np.version.full_version
'1.11.0'
>>> np.version.git_revision
'4092a9e160cc247a4a45724579a0c829733688ca'

TBH, it'd have been nicer if NumPy had anchored the typedefs according to concrete sizes, and not platform-dependent types :/ Oh well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant