-
Notifications
You must be signed in to change notification settings - Fork 34
ENH: add fallback_namespace #39
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -26,6 +26,32 @@ def test_array_namespace_multiple(): | |
assert array_namespace(x, x) == array_namespace((x, x)) == \ | ||
array_namespace((x, x), x) == array_api_compat.numpy | ||
|
||
def test_fallback_namespace(): | ||
import numpy as np | ||
import numpy.array_api | ||
import array_api_compat.numpy | ||
|
||
xp = array_api_compat.numpy | ||
xp_ = array_namespace([1, 2], fallback_namespace=xp) | ||
assert xp_ == xp | ||
|
||
xp_ = array_namespace([1, 2], np.asarray([1, 2]), fallback_namespace=xp) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we add a test to make sure the fallback namespace only applies when it's ambiguous. Something like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not sure how this would work. To me that's the purpose of the fallback. With
I would expect
Shall this also simplify to (Due to the recursions it's also getting tricky to follow the logic.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe I'm missing the point of this then. In general I'd say you shouldn't mix different array libraries with the array API. Some libraries might support it (like NumPy being able to convert other arrays), and in some cases with a performance penalty (like moving from GPU to CPU). So So to me the only point of this is to allow this function to also accept non-array inputs, like Python scalars and/or lists of Python scalars. You can convert those to arrays with I also tend to agree that the best way to handle this is to simply not allow non-array inputs to functions that use the array API. That forces the users to resolve the ambiguity of what array library the want to use by calling asarray themselves. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. By the way, this function automatically denests lists of arrays. This was to internally support functions like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah the main purpose of the proposal was to assume a namespace for things that would otherwise be marked as non compatible or unknown (list, scalar, tuples, else). Then yes it's on the user to call
Yeah this is making the logic difficult IMHO. I was having trouble to find a way to address your comment with that in place. If that can be removed, I am happy to do so (here or another PR, let me know.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I think that should live in SciPy, because it's orthogonal to array API support. Use of lists and other "array-likes" is specific to NumPy, and is by and large considered a design mistake. The array API standard does not allow array-likes, and neither do other libraries like PyTorch and CuPy. So there's no reason for this package to care about array-likes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
If you can do that it would be great. I'm still unclear what the changes here are (do we actually want this or not?), so maybe a separate PR is appropriate. You'll need to fix the functions like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I agree. For functions that are wrapped functions from NumPy (or any other library), we should support whatever the wrapped function supports to maintain maximal compatibility. But for new functions, we can be a little more strict. And generally speaking There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok then it looks like we could close this PR and I could try to propose a PR to only accept Array API compatible arrays. Is that correct? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes that sounds good. |
||
assert xp_ == xp | ||
|
||
# convert to Array API compatible namespace | ||
xp = array_api_compat.numpy | ||
xp_ = array_namespace([1, 2], np.asarray([1, 2]), fallback_namespace=np) | ||
assert xp_ == xp | ||
|
||
msg = 'Multiple namespaces' | ||
with pytest.raises(TypeError, match=msg): | ||
array_namespace([1, 2], numpy.array_api.asarray([1, 2]), fallback_namespace=np) | ||
|
||
msg = "'fallback_namespace' must be an Array API" | ||
with pytest.raises(TypeError, match=msg): | ||
array_namespace([1, 2], np.asarray([1, 2]), fallback_namespace="hop") | ||
|
||
|
||
def test_array_namespace_errors(): | ||
pytest.raises(TypeError, lambda: array_namespace([1])) | ||
pytest.raises(TypeError, lambda: array_namespace()) | ||
|
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.
The fallback namespace should still be an array API compatible namespace. So if someone does
fallback_namespace=numpy
instead offallback_namespace=array_api_compat.numpy
, we might want to automatically convert for them.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.
I added some logic to try to convert the namespace. I did not see a function to do that but I suppose this could be made into it's own function if there are more needs.