Tracking issue: Add array API standard support to the main namespace

See the slides from the NumPy 2.0 developer meeting in the numpy archive for an initial overview. That content has to be expanded into a NEP.

Backlog

I would be very happy to hear any opinion here around adding aliases for functions or kwargs that do the exact same thing as existing ones. I don't dislike at least most of them.
But we do have a choice: __array_namespace__ definitions can differ from the normal definitions without making the transition story for libraries really harder, there is a certain symmetry to doing it maybe, but I still cannot see it as a necessity, so I think we should do whatever we think is best for users.

__array_namespace__ definitions can differ from the normal definitions without making the transition story for libraries really harder

It looks to me like that would require adding a whole new hidden namespace, rather then a simple return numpy, potentially confusing, a lot of extra work, and the potential for extra bugs. Plus it would mean that the main namespace would actually not be compatible, which has other side effects. So that does not sound all that appealing. I'll add it to the NEP draft (ETA within a week; hard to keep up with Mateusz:)) as a design alternative though.

Hi! I'm finalizing the last np.linalg Array API PR and I realized that although vecdot (vector dot) is available only in np.array_api:

# Note: vecdot is not in NumPy
def vecdot(x1: Array, x2: Array, /, *, axis: int = -1) -> Array:

there's np.vdot that also claims to be a vector dot, but with completely different semantics (it ravels input to 1-D arrays, doesn't have axis keyword and it's Complex-conjugating dot product). I find it a bit confusing to have np.vdot and np.vecdot.
What do you think about renaming vdot to something else, like conj_vecdot?

vdot is a bit unfortunate indeed, but on the other hand we already have a lot of similar functions so adding yet another name perhaps does not help. The four array API functions should be orthogonal and complete, so I'd suggest applying the new .. legacy:: admonition to vdot and de-emphasizing it when we reorganize the docs.

also, numpy.fft.{fftfreq, rfftfreq} need the device parameter.

Another TODO to add here: np.sort() and np.argsort() need a descending argument: https://data-apis.org/array-api/2022.12/API_specification/generated/array_api.sort.html

I'm interested in what choice NumPy will make regarding the treatment of NaN entries when sorted in descending order, as this is not specified by the array API, but we'd like to make jax.numpy follow the numpy implementation in this respect.

I'm interested in what choice NumPy will make regarding the treatment of NaN entries when sorted in descending order, as this is not specified by the array API, but we'd like to make jax.numpy follow the numpy implementation in this respect.

Good question. Whether nans go at the beginning or the end for sort output is undefined on purpose, and in numpy they go at the end. For consistency, I'd expect for descending=False the whole array to be reversed, so then nans go at the beginning:

>>> x = np.asarray([1.0, 2.0, np.nan, 3.0, 4.0, np.nan, 5.0])
>>> np.sort(x)
array([ 1.,  2.,  3.,  4.,  5., nan, nan])
>>> np.sort(x)[::-1]
array([nan, nan,  5.,  4.,  3.,  2.,  1.])

Great, thanks! That's exactly how I ended up implementing it here: jax-ml/jax#19201

NEP: add NEP 56 on array API standard support in main namespace

NEP: add NEP 56 on array API standard support in main namespace (#25542)

This is all done, so let's close this tracking issue. Thanks all!

@rgommers

@rgommers Re: #25076 (comment), was closing this without sort/argsort having a descending keyword intentional? Crossref gh-14728.

@mtsokol

Yes, intentional to close this tracking issue as "declaring victory for 2.0.0". For several of the loose ends we decided that individual issues could be used - tracking issues shouldn't stay open indefinitely.

IIRC descending was investigated and determined that it was a lot of work (because of nan sorting, as noted in gh-14728) and hence we punted on that for 2.0. @mtsokol you may be able to add some extra color here (I thought there was discussion elsewhere aside from gh-14728, but can't remember where)?

Apart from that issue I had one attempt to implement it, here: mtsokol#5 but it turned out to be too much to bite at once. I also found another attempt here: #14989.

shall we open a new issue to track it? Or are there other array API standard compatibility things tracked somewhere?

shall we open a new issue to track it? Or are there other array API standard compatibility things tracked somewhere?

Please use gh-14728 for this descending one, adding content as needed.

I'm not in favor of a permanent array API compatibility issue if that's what you meant, it'd be better to use the existing label for it.

Navigation Menu

Tracking issue: Add array API standard support to the main namespace #25076

Backlog

Infra/support/docs

main namespace

`linalg` namespace

`ndarray` methods and attributes

miscellaneous

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue: Add array API standard support to the main namespace #25076

Description

Backlog

Infra/support/docs

main namespace

linalg namespace

ndarray methods and attributes

miscellaneous

Activity

asmeurer commented on Nov 6, 2023

seberg commented on Nov 7, 2023

rgommers commented on Nov 8, 2023

mtsokol commented on Nov 15, 2023

rgommers commented on Nov 16, 2023

2 remaining items

lucascolley commented on Dec 16, 2023

jakevdp commented on Jan 4, 2024

rgommers commented on Jan 5, 2024

jakevdp commented on Jan 5, 2024

rgommers commented on Mar 4, 2024

mdhaber commented on Dec 1, 2024

rgommers commented on Dec 2, 2024

mtsokol commented on Dec 2, 2024

lucascolley commented on Dec 2, 2024

rgommers commented on Dec 2, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`linalg` namespace

`ndarray` methods and attributes