MAINT: copy, array-api compatible utility function #19014
Conversation
|
Agreed that this seems useful, #19005 would make use of this twice but there will probably be other submodules which would use it more. |
scipy/_lib/_array_api.py
Outdated
| @@ -136,3 +136,26 @@ def atleast_nd(x, *, ndim, xp): | |||
| x = xp.expand_dims(x, axis=0) | |||
| x = atleast_nd(x, ndim=ndim, xp=xp) | |||
| return x | |||
|
|
|||
|
|
|||
| def copy(x): | |||
There was a problem hiding this comment.
Typically copy would not be the only operation that depends on the underlying array library. Do we want every utility function like this separately calling array_namespace to detect the namespace, or should xp be passed in?
(It might be fast enough that it doesn't matter, but I haven't checked.)
There was a problem hiding this comment.
Yes, we probably should pass it in to save effort. I think we should pass it in as a keyword:
def copy(x, *, xp=None):
if xp is None:
xp = array_namespace(x)
...
There was a problem hiding this comment.
It's arguable that we don't need a one-line wrapper of as_xparray, but I think it makes the intent ("copy this thing", not "make this an array") more clear, so it seems fine.
I checked out the other array_api_compatible tests and this looks consistent with those, so presumably it is actually being tested with a non-regular-NumPy backend (maybe numpy.array_api) on CI.
[skip ci]
That is correct. You can see from these failed CI tests that various backends are used. The CI configuration indicates that pytorch, numpy, numpy.array_api are examined. |
[skip cirrus] [skip circle]
MAINT: use `copy` utility from #19014 in `cluster`
It seems to me that having an array-api compatible
copyfunction would be quite useful. I have attempted to create one in this PR. Sorry, probably should've sent an item to scipy-dev, but I didn't think it would be controversial.