-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
NumPy scalars #2060
base: master
Are you sure you want to change the base?
NumPy scalars #2060
Conversation
This was most obviously a typo. Reference: https://github.com/numpy/numpy /blob/v1.17.0/numpy/core/code_generators/numpy_api.py#L139
I think this is not the most efficient way of doing it as it creates dtypes etc... but at least it's fully strict and correct. I guess instead of messing with dtypes you could extract Python types for all require numpy scalar types and cache them somewhere, and then do a simple (non-numpy) type equivalence check or something of the sort. Edit: on a second glance, |
eed0775
to
9d2d073
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, thanks!
Would it be possible to provide a type to match all py::numpy_scalar
types, similar to py::buffer
, as well? This would reduce the number of overloads needed in user code.
I'm not sure it's possible the way it's currently done since it just matches typenums in a very strict way.. you mean something like |
9d2d073
to
6fce3b9
Compare
Ok, tried to improve type caster a little, using a basic isinstance check, hopefully it's sufficient? (the arithmetic types and dtypes are now also cached statically) A little check: m.def("f32_in", [](py::numpy_scalar<float>) { return 0; });
m.def("f32_out", []() { return py::numpy_scalar<float>(0.); }) Before: >>> %timeit f32_in(f)
430 ns ± 8.79 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
>>> %timeit f32_out()
162 ns ± 0.424 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each) After: >>> %timeit f32_in(f)
355 ns ± 2.64 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
>>> %timeit f32_out()
149 ns ± 0.819 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each) |
6fce3b9
to
5d8a1f3
Compare
@ax3l Note that the current type names in type signatures are actually only correct on a standard 64-bit platform, so they need to be changed to avoid confusion. I.e., float is not float32 in general and double is not float64. While we can surely just map Also, I guess we want to bind Update: ok, apparently a related thing already exists ( |
Ok, added long doubles and all three types of complex numbers + updated the tests. |
0e15fe7
to
e88307b
Compare
Looks green now. (damn all those msvc tests, that took a bit...) |
e88307b
to
fedf9af
Compare
And now with native int mappings, here are the test failures due to overlaps :) Hmm... |
So... why do the tests fail? Hm.. |
Native C types are mapped to NumPy types in a platform specific way: for | ||
instance, ``char`` may be mapped to either ``np.int8`` or ``np.uint8`` | ||
depending on the platform. If you want to ensure specific NumPy types, | ||
it is recommended to use fixed-width aliases from ``<cstdint>>``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo:
it is recommended to use fixed-width aliases from ``<cstdint>>``. | |
it is recommended to use fixed-width aliases from ``<cstdint>``. |
Have been using pybind11 for a project and it works really well, great work on getting here. I don't know enough about the @aldanor: Thanks for working on this. |
Closes #2036, #1512
py::numpy_scalar<>
andpy::make_scalar()
as strict type casters between C and NumPy arithmetic types + tests + docsPyArray_DescrNewType
API code was wrong (although it's not really used at the moment, but still)