BUG: Fix searchsorted and CheckFromAny byte-swapping logic#28418
Merged
mhvk merged 2 commits intonumpy:mainfrom Mar 5, 2025
Merged
BUG: Fix searchsorted and CheckFromAny byte-swapping logic#28418mhvk merged 2 commits intonumpy:mainfrom
mhvk merged 2 commits intonumpy:mainfrom
Conversation
This closes numpygh-28190 and fixes another issue in the initial code that triggered the regression. Note that we may still want to avoid this, since this does lead to constructing (view compatible) structured dtypes unnecessarily here. It would also compactify the dtype. For building unnecessary dtypes, the better solution may be to just introduce a "canonical" flag to the dtypes (now that we have the space).
ngoldbaum
reviewed
Mar 3, 2025
mhvk
reviewed
Mar 3, 2025
Contributor
mhvk
left a comment
There was a problem hiding this comment.
Wow. The simplification in item_selection is worth it even if there hadn't been a bug!
Inline some suggestions that may help clarity.
| /* refs to dtype we own = 1 */ | ||
| Py_INCREF(dtype); | ||
| /* refs to dtype we own = 2 */ | ||
| /* need ap2 as contiguous array and of right dtype (steals and may be replace it) */ |
Contributor
There was a problem hiding this comment.
replace it -> replace dtype (since "it" could also refer to ap2, the array).
Actually, with my comment below, I think this can just be
/* need ap2 as contiguous array and of right dtype (note: steals dtype reference) */
| /* refs to dtype we own = 0 */ | ||
| return NULL; | ||
| } | ||
| /* dtype was stolen, replace it in case the array creation replaced it. */ |
Contributor
There was a problem hiding this comment.
Combine with l.2162? And write there,
/*
* The dtype reference we had was used for creating ap2, which may have
* replaced it with another. So here we copy the dtype of ap2 and use it for `ap1`.
*/
dtype = (PyArray_Descr *)Py_NewRef(PyArray_DESCR(ap2));
mhvk
approved these changes
Mar 5, 2025
Contributor
mhvk
left a comment
There was a problem hiding this comment.
Looks all good to me, although still a small query of the just-in-case variety.
Contributor
|
Might as well get this in, I think! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This closes gh-28190 and fixes another issue in the initial code that triggered the regression.
Note that we may still want to avoid this, since this does lead to constructing (view compatible) structured dtypes unnecessarily here.
It would also compactify the dtype. For building unnecessary dtypes, the better solution may be to just introduce a "canonical" flag to the dtypes (now that we have the space).
Actually, the bug may be going back to when the
_intversion was added (and started using borrowed references rather than stealing). Somehow, it seems we got away with that for a suprisingly long time.