array-api-extra requirements brainstorming
#842
Replies: 5 comments 3 replies
-
|
I think this is great! And actually |
Beta Was this translation helpful? Give feedback.
-
Why do they need to take an |
Beta Was this translation helpful? Give feedback.
-
|
In SciPy we currently do both - try to pass If we were to just always call |
Beta Was this translation helpful? Give feedback.
-
Indeed. We should also make it vendorable. And I agree we should make each function isolated so people can easily just copy the functions directly. |
Beta Was this translation helpful? Give feedback.
-
|
My biggest concern with the package is making sure we have good quality assurance, so that we know the function implementations are correct. That means good tests (we can test against known implementations like NumPy), and also ideally, we can get enough people who are familiar with the various array functions to help review, or even maintain, the package. I would also add that specifically in-scope is implementations or branches in implementations that are specific to a given array library or set of array libraries. For instance, if some libraries already have some fast versions of a given function, we should just dispatch to those, or if some function can be implemented faster for libraries that have access to stride tricks, we should use those when we can. This is of particular importance when it has an impact on performance. |
Beta Was this translation helpful? Give feedback.
-
Hmm, I was actually thinking of declaring that out of scope, at least to start with. I think that really broadens the scope a lot - not necessarily a bad thing, but I think it is more than we need to commit to right now. This delegation to existing libraries could still be done downstream for now. My fear is that this potentially moves in the direction of making the package a one-stop-shop for delegation to existing libraries, which could result in chasing lots of moving targets.
I think downstream libraries should be responsible for which array types (if any) they would like to optimise for. Then they can copy the agnostic implementations to customise to their needs. |
Beta Was this translation helpful? Give feedback.
-
restricting the scope as I suggest would make this part easier too |
Beta Was this translation helpful? Give feedback.
-
|
@lucascolley I went ahead and created an array-api-extra repo and gave you write access. https://github.com/data-apis/array-api-extra Feel free to start prototyping stuff there. If it's helpful, you can copy stuff over from array-api-strict or array-api-compat. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The idea of a package named something like
array-api-extra(xpx?) has been floated in various places. In a sentence, the purpose would be to house array-agnostic implementations of functions which are likely to be useful in a variety of domains (in this sense, the functions belong on or close to the array library level), but are not a part of the standard.Proposed functions so far include
kron,atleast_nd,cov,moveaxis_to_end,vector_norm,ravel, just from SciPy alone. Some of them can be relatively trivial to implement for end-users, but there is still value in having drop-in replacements for existing non-standard functions, especially when converting large codebases. Forming a collection of functions that are needed as consumer libraries convert to array-agnostic implementations should help inform potential additions to the standard, too.These functions would take an
xpkwarg and perform all computation with that namespace, assuming that it is compatible with the standard.In scope
meanOut of scope
General package requirements
Design choices
cc @asmeurer @rgommers @izaid, x-ref gh-837, scipy/scipy#21054
Beta Was this translation helpful? Give feedback.
All reactions