Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

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

Merged
merged 7 commits into from
Aug 5, 2024

Conversation

seberg
Copy link
Member

@seberg seberg commented Aug 1, 2024

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.

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.
@seberg seberg added 00 - Bug 56 - Needs Release Note. Needs an entry in doc/release/upcoming_changes 30 - API labels Aug 1, 2024
@seberg seberg requested a review from ngoldbaum August 1, 2024 20:21
@seberg seberg added this to the 2.1.0 release milestone Aug 1, 2024
@seberg seberg removed the 56 - Needs Release Note. Needs an entry in doc/release/upcoming_changes label Aug 2, 2024
Previously, NumPy checked whether the 100 fits the ``int8_arr``.

This aligns ``copyto``, ``full``, and ``full_like`` with the correct NumPy 2
behavior.
Copy link
Member Author

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).

@charris
Copy link
Member

charris commented Aug 2, 2024

close/reopen

@charris charris closed this Aug 2, 2024
@charris charris reopened this Aug 2, 2024
@charris
Copy link
Member

charris commented Aug 2, 2024

The 32 bit windows failure looks legit, I haven't seen it before.

@seberg
Copy link
Member Author

seberg commented Aug 2, 2024

No, it's gh-27093

EDIT: Well, it's legit, but not related to this PR :).

@ngoldbaum
Copy link
Member

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.

Copy link
Member

@ngoldbaum ngoldbaum left a 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.

numpy/_core/src/multiarray/multiarraymodule.c Outdated Show resolved Hide resolved
numpy/_core/src/multiarray/multiarraymodule.c Show resolved Hide resolved
numpy/_core/src/multiarray/multiarraymodule.c Show resolved Hide resolved
numpy/_core/tests/test_api.py Show resolved Hide resolved
numpy/_core/tests/test_api.py Outdated Show resolved Hide resolved
numpy/_core/tests/test_ufunc.py Outdated Show resolved Hide resolved
numpy/_core/tests/test_ufunc.py Outdated Show resolved Hide resolved
seberg and others added 2 commits August 2, 2024 20:46
Copy link
Contributor

@mhvk mhvk left a 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.

numpy/_core/src/multiarray/multiarraymodule.c Show resolved Hide resolved
numpy/_core/src/umath/ufunc_object.c Show resolved Hide resolved
numpy/_core/src/umath/ufunc_object.c Outdated Show resolved Hide resolved
@ngoldbaum
Copy link
Member

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.

@seberg seberg merged commit b9d07ab into numpy:main Aug 5, 2024
64 of 66 checks passed
@seberg seberg deleted the copyto-safety branch August 5, 2024 07:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BUG: NEP 50 inconsistency in copyto
4 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.