MAINT: remove outdated xp_
functions, xp.asarray
on elementwise function args
#22683
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.
Reference issue
gh-22680
What does this implement/fix?
Now that the 2024.12 standard is out and array-api-compat supports it, I thought it was time for a cleanup of some artifacts from the old days of array API translations.
One of the things we used to have to do was convert arguments to
xp.where
,xp.minimum
, etc., into arrays rather than leaving them as scalars. Even if we were careful to use the correctdtype
, I don't think anyone ensured that the array ended up on the correct device. Use of a Python scalar avoids both of these gotchas.This cleans up most of the now-unnecessary array conversions in the context of
xp.where
,xp.minimum
,xp.clip
, and some other elementwise functions mentioned in data-apis/array-api#807 (comment). I also noticed some old customxp_
functions that we no longer need since they are provided by array-api-compat.Lots of lines and files are changed, but it should be pretty straightforward.
Additional information
Based on gh-22680, I think that anywhere we create an array within a function, we need to pay attention to the device. This only avoids some of those places. To resolve that issue, we really should test with non-default devices (and make the required changes).
There may be some test skips we can remove now. I think we can do that as part of follow-up to gh-22609/gh-22677.
Use of
result_type
needs very special attention; see data-apis/array-api-compat#223 (comment). Now that it's possible, we need to make sure we pass the arguments toresult_type
before they become arrays.