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
Adopt the numpy.array_api
module as cupy.array_api
#5698
Conversation
This is based on the function stubs from the array API test suite, and is currently based on the assumption that NumPy already follows the array API standard. Now it needs to be modified to fix it in the places where NumPy deviates (for example, different function names for inverse trigonometric functions).
…ult numpy namespace
…dual files The specific submodule organization is an implementation detail and should not be used. Only the top-level numpy._array_api namespace should be used.
This avoids importing everything inside the individual functions, but still is preferred over importing the functions used explicitly, as most of them clash with the wrapper function names.
The docstrings just point back to the functions they wrap for now. More thought may need to be put into this for the future. Most functions can actually perhaps inherit the docstring of the function they wrap directly, but there are some functions that have differences (e.g., different names, different keyword arguments, fewer keyword arguments, etc.). There's also the question of how to handle cross-references/see alsos that point to functions not in the API spec and behavior shown in docstring examples that isn't required in the spec.
This is mostly aimed at any potential reviewers of the module for now.
Some stubs still need to be modified to properly pass mypy type checking. Also, 'device' is just left as a TypeVar() for now.
…eturn a scalar This is needed to pass mypy type checks for the given type annotations.
…bmodule That way they only work on actual ndarray inputs, not array-like, which is more inline with the spec.
So far, it just is a wrapper with all the methods defined in the spec, which all pass through. The next step is to make it so that the methods that behave differently actually work as the spec describes. We also still need to modify all the array_api functions to return this wrapper object instead of np.ndarray.
…ndarray class These methods aren't required by the spec, but without them, the array object is harder to use interactively.
Adding a test axis for array api tests in CuPy is great, it should be as simple as
My understanding is that cirun.io itself is free, but to launch a self-hosted test runner AWS/GCP/Cloudocean account is needed which is pay-as-you-go? |
Right, I keep forgetting... 🤦🏻♂️ |
OK I've identified all the issues that led to the test failures (#5698 (comment)). Note: NumPy and CuPy suffer from the same linespace issue (numpy/numpy#18881), so unless NumPy has a fix out we should just skip the test as Aaron suggested. Tomorrow, I'll add some simple docs explaining the current status, pointing users to the API spec, etc. I'll also try to inspect again the test suite and the NumPy code adopted in this PR. @kmaehashi let me know if there is any test related change I should address; otherwise, feel free to take a look anytime 🙂 |
Great. Yes you can add me to the bot for the array-api label.
It should be
I saw some of the cross-referenced issues. What is the test_eye error? I can't tell from the summary what the issue is (an unfortunate feature of the test suite, which I don't know how to improve), but from the exception it's possible I have the wrong strategy input to the hypothesis test. |
@asmeurer all failures I discovered are CuPy's fault. I haven't found any misbehavior from the test suite, though I haven't dug hard either 🙂 |
The PR overall looks good to me. 👍
|
OK, I'll move
I was hoping to make diff easy too. Keeping
Yes PY37 will fail, but not because of the tests, but because of the use of position-only arguments in the function signatures, which is a PY38+ thing. The module-level skip is already added in |
I don't know how much cupy's testing framework diverges from NumPy's, but we never found a good way to make the tests for the numpy.array_api submodule work in Python 3.7. NumPy ended up just dropping 3.7 support before merging my PR, in part because of this issue. Just a heads up that you may run into the same issue. |
numpy.array_api
module as cupyx.array_api
numpy.array_api
module as cupyx.array_api
Hi @kmaehashi this is ready. I've moved the module to under |
numpy.array_api
module as cupyx.array_api
numpy.array_api
module as cupy.array_api
Jenkins, test this please |
Jenkins CI test (for commit 7e8191c, target branch master) succeeded! |
Compared diff with numpy/numpy@098f874 and looks good to me! |
Very experimental attempt to see how far we can reach. DO NOT MERGE.Close #4789.
This PR has two components:
git am
failures were those related to NumPy specifics, such assetup.py
and_pytesttester.py
; the relevant diffs were carefully removed from the patch to enable a simplegit am 18585.patch
call.cc: @rgommers @asmeurer (feel free to tag more interested people)