RFC: 2022 Standardization Priorities

[kgryte]

The purpose of this issue is to identify focus areas for the 2022 revision of the array API specification.

The following is not authoritative and is subject to change based on member (and community) feedback. The primary intent is to kickstart conversations around how the consortium should prioritize time and resources to continue advancing the array API specification over the course of the next year (2022).

Based on the issue tracker, consortium meetings, and discussions, the following focus areas seem to enjoy broad consensus on moving forward:

• complex numbers: adding complex number support has been discussed in consortium meetings and has consensus. Adding support for complex numbers to the specification is a prerequisite for FFTs and certain additional linear algebra APIs.
• FFTs: fast Fourier transforms have been proposed as an extension to the specification (see gh-189), have been discussed in consortium meetings, and have consensus.
• linear algebra APIs: expanding the linear algebra extension surface area to include APIs requiring complex number support (e.g., eig et al). Additionally, adding einsum.
• additional APIs: expanding the surface area of the specification to include additional common APIs (see gh-187). Notable APIs include take and put (see gh-177).

Additional focus areas necessary for ensuring the continued success of the specification include the following:

• compliance tooling: developing and expanding specification compliance tooling. The array API test suite is still being actively developed and continues to co-evolve alongside the specification. Further, developing a mechanism for reporting and making publicly available specification compliance is important for downstream consumer adoption.
• RST migration: migrating the specification from Markdown to RST (see gh-283) and aiding machine readability (see gh-49).

A 2022 milestone tracker has been created to help track progress as we enter the new year.

Feedback

If you have additional feedback and would like to propose additional focus areas or would like to amend the ones above, feel free to comment on this thread.

Cheers!

[rgommers]

The "additional APIs" topic will be mostly driven by pain points identified during adoption of the v2021 API by array-consuming libraries (which is already ongoing).

There is a lot of interest in a common PRNG API. It looks like the new numpy.random.Generator API is suitable and other libraries are further with adopting either that or something similar to it than I was expecting. So that should be a priority I think, it's the most obvious thing that's heavily used and we left out for v2021.

[rgommers]

Looking at this issue 11.5 months later, most of it was done:

• complex number support will be completed soon,
• fft extension is complete,
• linalg extension: some extensions, not einsum though, and there's still a WIP PR for eig and eigvals that needs finishing up,
• additional APIs: take and some other ones were added, plus missing keywords that implementors ran into,
• compliance tooling: still in progress, some work left here (probably for early next year),
• RST migration: this was done. the "machine readable format" was mostly about function signatures, those are now in .py files so that is also done (even if the issue is still open).

So we should be on track for closing this issue in a couple of weeks.

[rgommers]

Now that complex number support is complete and all that is left for v2022 is content refactoring for maintainability, it's time to close this issue.