-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
API,BUG: Fix copyto (and ufunc) handling of scalar cast safety #27091
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
Conversation
This defines scalar cast safety to be "safe", "equiv", or "unsafe" (for Python int, float, complex). Although, equiv is a bit of an odd one. We define it by using the common DType with the desired one, and assuming that this cast is at least safe. With that, we can create an appropriate array for the scalar (and the rest works fine). This means that any python float can be safely cast to e.g. float32 and any Python integer to any NumPy integer even though the actual assignment may overflow (floats) or fail (integers). `can_cast` itself is not defined here. It could be, but has the disadvantage that it won't error out on assignment later for integers.
Increadibly niche and can really never matter. But did matter for the new tests (equiv)
Previously, NumPy checked whether the 100 fits the ``int8_arr``. | ||
|
||
This aligns ``copyto``, ``full``, and ``full_like`` with the correct NumPy 2 | ||
behavior. |
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.
It is intentional that I don't mention the ufunc changes. They are ridiculously niche IMO, since they require using casting=
and dtype=
(or a weird casting like equiv
).
close/reopen |
The 32 bit windows failure looks legit, I haven't seen it before. |
No, it's gh-27093 EDIT: Well, it's legit, but not related to this PR :). |
I'm going to try to go over this today but maybe @mhvk could also look at this since he has more familiarity with the details here. |
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.
A few comments inline, no blockers that I saw.
Co-authored-by: Nathan Goldbaum <nathan.goldbaum@gmail.com>
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.
Haven't had a chance to look in depth, but it seems all OK. Just a nitpick and one question about an error path.
I guess the docs build failure is fixed in #27102? Looks good to me, feel free to hit the merge button if the docs failure is unrelated to this PR. |
This defines scalar cast safety to be "safe", "equiv", or "unsafe" (for Python int, float, complex).
Although, equiv is a bit of an odd one. We define it by using the common DType with the desired one, and assuming that this cast is at least safe. With that, we can create an appropriate array for the scalar (and the rest works fine).
This means that any python float can be safely cast to e.g. float32 and any Python integer to any NumPy integer even though the actual assignment may overflow (floats) or fail (integers).
can_cast
itself is not defined here. It could be, but has the disadvantage that it won't error out on assignment later for integers.Closes gh-26381, gh-27075
Still needs release notes, but ready for review. Sorry it ended up as one big commit, but besides moving some helper out of ufunc.c looking at it per-file is just as well.