ENH: add fast path for str(scalar_int)#23746
Conversation
| break; | ||
| default: | ||
| item = gentype_generic_method(self, NULL, NULL, "item"); | ||
| break; |
There was a problem hiding this comment.
A fallback for some as-yet-unknown user defined int dtype
There was a problem hiding this comment.
We need to generate a function for each type anyway. I don't think that str(self.item()) is a good default to begin with.
That said, I don't mind just doing this, I will just delete it again on main in the next 2 months hopefully. (The work should already be in the repr PR, and its time to push that after branching.)
|
|
||
|
|
||
| def test_structure_format(self): | ||
| def test_structure_format_mixed(self): |
There was a problem hiding this comment.
I split this test into 3, since the other test functions were not related to this one. I hit this by accident when I was trying out a different version of the code and printing was failing.
seberg
left a comment
There was a problem hiding this comment.
Not sure I wouldn't prefer a type specific path (just because its the pattern used I think). But, this will generate a merge conflict with larger changes anyway, so I don't care.
So, lets put it in for 1.25.x.
| break; | ||
| default: | ||
| item = gentype_generic_method(self, NULL, NULL, "item"); | ||
| break; |
There was a problem hiding this comment.
We need to generate a function for each type anyway. I don't think that str(self.item()) is a good default to begin with.
That said, I don't mind just doing this, I will just delete it again on main in the next 2 months hopefully. (The work should already be in the repr PR, and its time to push that after branching.)
|
Ahh, type-specific |
You could define a dtype with a scalar that isn’t convertible to a string, but basic things like array printing wouldn’t work. We could probably add a check to the dtype registration that makes sure the scalar has a |
|
Thanks Matti. |
numpy#23746 introduced a fast path for scalar int conversions, but the map between Python types and C types was subtly wrong. This fixes tests on at least ppc32 (big-endian). Many thanks to Sebastian Berg for debugging this with me and pointing out what needed to be fixed. Bug: numpy#24239 Fixes: 81caed6
numpy#23746 introduced a fast path for scalar int conversions, but the map between Python types and C types was subtly wrong. This fixes tests on at least ppc32 (big-endian). Many thanks to Sebastian Berg for debugging this with me and pointing out what needed to be fixed. Closes numpy#24239. Fixes: 81caed6
numpy#23746 introduced a fast path for scalar int conversions, but the map between Python types and C types was subtly wrong. This fixes tests on at least ppc32 (big-endian). Many thanks to Sebastian Berg for debugging this with me and pointing out what needed to be fixed. Closes numpy#24239. Fixes: 81caed6
numpy#23746 introduced a fast path for scalar int conversions, but the map between Python types and C types was subtly wrong. This fixes tests on at least ppc32 (big-endian). Many thanks to Sebastian Berg for debugging this with me and pointing out what needed to be fixed. Closes numpy#24239. Fixes: 81caed6
Create a fast path for
str(scalar_int). The call tostr(x)whenxis anintscalar goes togenint_type_str, which callsPyObject_Str(gentype_generic_method(self, NULL, NULL, "item")). Thegentype_generic_methodcreates a 0d array of the scalar (allocating a PyArrayObject with 1 data item), copies the item into the new 0d array, then calls arr.item() to get the int value, then wraps that in aPyLongObject.It is faster to avoid all that and use
scalar_valueto get thevoid *value, then cast that to the properinttype before wrapping it in aPyLongObject.I also added a benchmark to prove there is a speedup.
This was motivated by a user who noticed that
[str(int(x)) for x in numpy.arange(10000)]is much faster than[str(x) for x in numpy.arange(10000)]