DOC: Update roadmap a bit more #26722
Conversation
Just some thoughts, I didn't include ufunc chaining, although I think it would also be valid to mention it (even if I doubt anyone will work on it). All others are things that have been discussed multiple times at least, so I think they are fine to add, even if I don't know if anyone will work on it: That is true for practically everything. I also always play with the idea that labeled axes might not be all that bad to think about. But it may need a quite a lot of dedication. (It might not be that bad, but its a pretty broad thing.)
| @@ -29,8 +29,6 @@ needed based on real-world experience and needs. | |||
|
|
|||
| In addition, the ``__array_ufunc__`` and ``__array_function__`` protocols | |||
| fulfill a role here - they are stable and used by several downstream projects. | |||
| They do not cover the whole API, so use of the array API standard is preferred | |||
| for new code. | |||
There was a problem hiding this comment.
The "They don't cover the whole API" seemed wrong to me and I didn't have thought on how to rephrase so just delete it.
The correct spin should probably be that the Array API may be preferred for new library code, while array-function/array-ufunc is definitely still relevant for array object authors who like to integrate deeply with NumPy.
| @@ -97,6 +97,9 @@ first, and that could potentially be upstreamed into NumPy later, include: | |||
| ``latin1``) | |||
| - A unit dtype | |||
|
|
|||
| We further plan to extend the new API around ufuncs as the needs arise. | |||
| One possibility here is creating a new, more powerful, API to allow hooking | |||
| into existing NumPy ufunc implementations. | |||
There was a problem hiding this comment.
Note sure anyone can understand it, but I don't mind :). I am talking about pnumpy here, we should have a better story for it (or decide to not have a story at all).
There was a problem hiding this comment.
Change "new API around ufuncs" to "ufunc C API"?
There was a problem hiding this comment.
I had never heard of pnumpy, but it seems interesting. Maybe add at end "... implementations, e.g., to allow parallel execution as done by pnumpy"
There was a problem hiding this comment.
Not sure how maintained it still is (or quite how well it worked in practice), but if others think it is stable enough to link, sure.
(Also, parallel execution belongs on a different level IMO, but that is part of the potential things here.)
There was a problem hiding this comment.
It's not maintained. It was an experiment, it worked and yielded interesting performance gains, but it wasn't interesting enough to pursue further at that point. I think it is an example of the types of things people would like to be able to do though, so it can serve as an example use case I'd say. @mattip may have more thoughts on it.
There was a problem hiding this comment.
If it is not pursued anymore then linking to it is perhaps not such a good idea... But it helps to give some example of why linking into the implementations might be useful.
There was a problem hiding this comment.
pnumpy is unmaintained. I wouldn't want to draw more attention to it.
| @@ -29,8 +29,6 @@ needed based on real-world experience and needs. | |||
|
|
|||
| In addition, the ``__array_ufunc__`` and ``__array_function__`` protocols | |||
| fulfill a role here - they are stable and used by several downstream projects. | |||
| They do not cover the whole API, so use of the array API standard is preferred | |||
| for new code. | |||
doc/neps/roadmap.rst
Outdated
| @@ -51,6 +49,8 @@ Other performance improvement ideas include: | |||
|
|
|||
| - A better story around parallel execution (related is support for free-threaded | |||
| CPython, see further down). | |||
| - Using recent improvements in our ufunc context to allow users for example to | |||
There was a problem hiding this comment.
Can you rephrase this slightly, removing "our" and perhaps pointing the API that is meant here?
There was a problem hiding this comment.
I added errstate in brackets, which is what I mean (mostly). Since I think that is a path towards switching ufunc loops, but of course I also mean the new C API which allows us to actually propagate that information.
There was a problem hiding this comment.
Updated to:
- Enable the ability to allow NumPy to use faster, but less precise,
implementations for ufuncs.
Until now, the only state modifying ufunc behavior has been ``np.errstate``.
But, with NumPy 2.0 improvements in the ``np.errstate`` and the ufunc C
implementation make this type of addition easier.
since I realized it is actually both the behind the scenes implementation and the not quite behind the scenes errstate improvements that are (at least likel) helpful.
| @@ -97,6 +97,9 @@ first, and that could potentially be upstreamed into NumPy later, include: | |||
| ``latin1``) | |||
| - A unit dtype | |||
|
|
|||
| We further plan to extend the new API around ufuncs as the needs arise. | |||
| One possibility here is creating a new, more powerful, API to allow hooking | |||
| into existing NumPy ufunc implementations. | |||
There was a problem hiding this comment.
Change "new API around ufuncs" to "ufunc C API"?
doc/neps/roadmap.rst
Outdated
| @@ -122,6 +125,13 @@ We intend to write a NEP covering the support levels we provide and what is | |||
| required for a platform to move to a higher tier of support, similar to | |||
| `PEP 11 <https://peps.python.org/pep-0011/>`__. | |||
|
|
|||
| Further consistency fixes to promotion and scalar logic | |||
| ``````````````````````````````````````````````````````` | |||
| NumPy 2 fixed many issues around promotion especially with respect to scalars. | |||
There was a problem hiding this comment.
| NumPy 2 fixed many issues around promotion especially with respect to scalars. | |
| NumPy 2.0 fixed many issues around promotion especially with respect to scalars. |
doc/neps/roadmap.rst
Outdated
| Further consistency fixes to promotion and scalar logic | ||
| ``````````````````````````````````````````````````````` | ||
| NumPy 2 fixed many issues around promotion especially with respect to scalars. | ||
| We plan to continue slowly fixing remaining inconsistencies. |
There was a problem hiding this comment.
| We plan to continue slowly fixing remaining inconsistencies. | |
| We plan to continue fixing remaining inconsistencies. |
doc/neps/roadmap.rst
Outdated
| ``````````````````````````````````````````````````````` | ||
| NumPy 2 fixed many issues around promotion especially with respect to scalars. | ||
| We plan to continue slowly fixing remaining inconsistencies. | ||
| For example, NumPy converts 0-D objects to scalars and some promotions |
There was a problem hiding this comment.
| For example, NumPy converts 0-D objects to scalars and some promotions | |
| For example, NumPy converts 0-D objects to scalars, and some promotions |
There was a problem hiding this comment.
Do we (you, or anyone else) actually plan to do anything about 0-D arrays vs. scalars? If not, we shouldn't mention it here.
There was a problem hiding this comment.
Not promising to do this right now, but that is true for most points on the list.
So yes, I think this is much more concrete than most points. In fact, it is even mostly done, since I did most (maybe all) of the foundational work in NumPy 2! (and one of that was another small compat break ;).)
| @@ -97,6 +97,9 @@ first, and that could potentially be upstreamed into NumPy later, include: | |||
| ``latin1``) | |||
| - A unit dtype | |||
|
|
|||
| We further plan to extend the new API around ufuncs as the needs arise. | |||
| One possibility here is creating a new, more powerful, API to allow hooking | |||
| into existing NumPy ufunc implementations. | |||
There was a problem hiding this comment.
I had never heard of pnumpy, but it seems interesting. Maybe add at end "... implementations, e.g., to allow parallel execution as done by pnumpy"
|
Link issue #26157 to Support for free-threaded CPython? (Since there's only one tracking issue, I assume that the roadmap isn't to release incremental upgrades toward full compatibility with Python 3.13.) |
|
Let's put this in, we can continue to iterate on it in future PRs. |
|
Thanks @seberg and reviewers |
Just some thoughts, I didn't include ufunc chaining, although I think it would also be valid to mention it (even if I doubt anyone will work on it). All others are things that have been discussed multiple times at least, so I think they are fine to add, even if I don't know if anyone will work on it: That is true for practically everything.
I also always play with the idea that labeled axes might not be all that bad to think about. But it may need a quite a lot of dedication. (It might not be that bad, but its a pretty broad thing.)