8000 Tracking issue: Add array API standard support to the main namespace · Issue #25076 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

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

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

Closed
23 tasks done
mtsokol opened this issue Nov 6, 2023 · 16 comments
Closed
23 tasks done

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

mtsokol opened this issue Nov 6, 2023 · 16 comments

Comments

@mtsokol
Copy link
Member
mtsokol commented Nov 6, 2023

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

Infra/support/docs

main namespace

linalg namespace

ndarray methods and attributes

miscellaneous

@mtsokol mtsokol converted this from a draft issue Nov 6, 2023
@mtsokol mtsokol changed the title Add array API standard support to the main namespace Tracking issue: Add array API standard support to the main namespace Nov 6, 2023
@mtsokol mtsokol added this to the 2.0.0 release milestone Nov 6, 2023
@asmeurer
Copy link
Member
asmeurer commented Nov 6, 2023

This mailing list thread goes into details for some of the "easy and useful" changes https://mail.python.org/archives/list/numpy-discussion@python.org/thread/TTZEUKXUICDHGTCX5EMR6DQTYOSDGRV7/#YKBWQ2AP76WYWAP6GFRYMPHZCKTC43KM

@seberg seberg added the triage review Issue/PR to be discussed at the next triage meeting label Nov 7, 2023
@seberg
Copy link
Member
seberg commented Nov 7, 2023

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.

@rgommers
Copy link
Member
rgommers commented Nov 8, 2023

__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.

@mtsokol
Copy link
8000
Member Author
mtsokol commented Nov 15, 2023

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?

@rgommers
Copy link
Member

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.

@rgommers rgommers removed the triage review Issue/PR to be discussed at the next triage meeting label Nov 24, 2023
@rgommers
Copy link
Member

We discussed this topic in the community meeting two days ago. Quick summary:

  1. Let's get np.bool and the new CI job with xfails merged now,
  2. For the other PRs, let's go ahead with the ones that are an improvement either way (independent of the array API standard)
  3. For the ones that we would not do without the array API standard exists (e.g., adding device), those are blocked on writing/reviewing the NEP.
  4. @seberg pointed out that it would be helpful to give a thumbs up on PRs from (2) that look fine, with 1-2 thumbs up emojis, it's easier to move ahead and merge them.

@lucascolley
Copy link
Contributor

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

@jakevdp
Copy link
Contributor
jakevdp commented Jan 4, 2024

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.

@rgommers
Copy link
Member
rgommers commented Jan 5, 2024

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.])

@jakevdp
Copy link
Contributor
jakevdp commented Jan 5, 2024

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

rgommers added a commit to rgommers/numpy that referenced this issue Jan 5, 2024
For NumPy 2.0. xref numpygh-25076 as the main tracking issue for this topic.

[skip actions] [skip azp] [skip cirrus]
charris pushed a commit that referenced this issue Feb 28, 2024
* NEP: add NEP 56 on array API standard support in main namespace

For NumPy 2.0. xref gh-25076 as the main tracking issue for this topic.

[skip actions] [skip azp] [skip cirrus]

* DOC: rework for review comments: textual suggestions and easy changes

[skip actions] [skip cirrus] [skip azp]

* DOC: second batch of smaller textual changes

[skip actions] [skip azp] [skip cirrus]

* DOC: adopt suggestions on namespace and alias count/hiding

[skip actions] [skip cirrus] [skip azp]

* DOC: extend abstract with the main rationale and benefits

* add section about which parts of the standard are not adopted

[skip actions] [skip azp] [skip cirrus]

* Add the in-place "no unsafe casting" item to the not adopted section

Also a few smaller textual changes.

[skip actions] [skip cirrus] [skip azp]

* NEP: update content mentioning array scalars

Addresses review feedback. Array scalars aren't actually incompatible
with the design of the standard.

* NEP: improve backwards compatibility section and describe `copy=` better

As requested in PR review, better delineate the different types of
changes in the backwards compatibility section, and add assessments
of what the impact of changes is.

In addition, expect the description of the `copy=` keyword semantics
changes.

[skip cirrus] [skip actions] [skip azp]

* NEP: update description of `fft` changes

[skip actions] [skip cirrus] [skip azp]
@rgommers
Copy link
Member
rgommers commented Mar 4, 2024

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

@rgommers rgommers closed this as completed Mar 4, 2024
@rgommers rgommers moved this from 🏗 In progress to ✅ Done in NumPy 2.0 Roadmap Mar 5, 2024
@mdhaber
Copy link
Contributor
mdhaber commented Dec 1, 2024

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

@rgommers
Copy link
Member
rgommers commented Dec 2, 2024

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)?

@mtsokol
Copy link
Member Author
mtsokol commented Dec 2, 2024

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.

@lucascolley
Copy link
Contributor

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

@rgommers
Copy link
Member
rgommers commented Dec 2, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

No branches or pull requests

7 participants
0