Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Fix changed return type dtype for array API #29488

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 3 commits into from
Jul 15, 2024

Conversation

betatim
Copy link
Member

@betatim betatim commented Jul 15, 2024

This (attempts to) fixes the failure in #29373 (comment)

The failing test shows that the returned array has a different dtype from the input.

Copy link

github-actions bot commented Jul 15, 2024

βœ”οΈ Linting Passed

All linting checks passed. Your pull request is in excellent shape! β˜€οΈ

Generated for commit: 569ab2b. Link to the linter CI: here

@OmarManzoor
Copy link
Contributor

@betatim I think the CUDA CI is currently failing because the array-api-strict is not updated to the latest version in the CUDA CI. Either we need to update the version or change how we handle maximum as its available in the latest version but not in prior ones.

Copy link
Contributor

@OmarManzoor OmarManzoor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks @betatim

@betatim
Copy link
Member Author

betatim commented Jul 15, 2024

@betatim I think the CUDA CI is currently failing because the array-api-strict is not updated to the latest version in the CUDA CI. Either we need to update the version or change how we handle maximum as its available in the latest version but not in prior ones.

I thought that updating the lockfile (as I did in this PR) would not fix it, but it seems like it did?

I think supporting more than the latest version of array-api-strict is not wort the effort. The reason for that is that it isn't meant to be used by humans (like Numpy or cupy) but only for testing how compliant your use of the array API is. So I think if there are no errors in the latest version, we are good. What do you think?

The unsovled mystery for me is why the array-api-strict related error went away in this PR? What change did I make that lead to a newer version of it being installed?

@OmarManzoor
Copy link
Contributor

OmarManzoor commented Jul 15, 2024

I think supporting more than the latest version of array-api-strict is not wort the effort. The reason for that is that it isn't meant to be used by humans (like Numpy or cupy) but only for testing how compliant your use of the array API is. So I think if there are no errors in the latest version, we are good. What do you think?

The unsovled mystery for me is why the array-api-strict related error went away in this PR? What change did I make that lead to a newer version of it being installed?

I agree with you and I think we went with the implementation based on considering the latest version of the api. I think the error is now fixed because the lock file is updated and the supported version in the lock file is now == 2.0.1. Previously array-api-strict was == 1.1.1 in the lock file and that version does not support the maximum function.

@betatim
Copy link
Member Author

betatim commented Jul 15, 2024

Ergh. I looked at the lockfile diff twice and couldn't spot array-api-strict. Thanks for finding it for me.

@lesteve should we merge this or #29373 (comment) and then this. Or something else completely?

@lesteve lesteve merged commit bed36b2 into scikit-learn:main Jul 15, 2024
33 checks passed
@lesteve
Copy link
Member

lesteve commented Jul 15, 2024

Let's merge this and close #29373.

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.

3 participants