Mailman 3 April 2026 - NumPy-Discussion

next NumPy community meeting - Wednesday, April 9th, 2025 at 5 pm UTC - now meeting ONE HOUR EARLIER
by Inessa Pawson May 16, 2026

May 16, 2026

The next NumPy community meeting will be held this Wednesday, April 9th at 17:00 (5 pm) UTC. Please note the TIME CHANGE! Join us via Zoom: https://numfocus-org.zoom.us/j/83278611437?pwd=ekhoLzlHRjdWc0NOY2FQM0NPemdk… Everyone is welcome and encouraged to attend. To add to the meeting agenda the topics you’d like to discuss, follow the link: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both For the notes from the previous meetings, visit: https://github.com/numpy/archive/tree/main/community_meetings -- Cheers, Inessa Inessa Pawson GitHub: inessapawson

1 29

next NumPy Optimization Team meeting - Monday, January 20th, 2025 at 5 pm UTC
by Inessa Pawson May 14, 2026

May 14, 2026

Hi, all! The next NumPy Optimization Team meeting will be held on Monday, January 20th at 17:00 UTC. Join us via Zoom: https://numfocus-org.zoom.us/j/81261288210?pwd=iwV99tGSjR61RTGEERKM4QKxe46g… Everyone is welcome and encouraged to attend. To add to the meeting agenda the topics you’d like to discuss, follow the link: https://hackmd.io/dVdSlQ0TThWkOk0OkmGsmw?both For the notes from the previous meetings, visit: https://github.com/numpy/archive/tree/main/optim_team_meetings -- Cheers, Inessa Inessa Pawson GitHub: inessapawson

1 22

next NumPy triage meeting - Wednesday, February 18th, 2026 at 18:00 UTC
by Inessa Pawson May 12, 2026

May 12, 2026

Our next triage meeting will be held this Wednesday, February 18th at 18:00 (6 pm) UTC. This is a meeting where we synchronously triage prioritized PRs and issues. Everyone is welcome to attend and contribute to a conversation. Join us via Zoom: https://numfocus-org.zoom.us/j/82096749952?pwd=MW9oUmtKQ1c3a2gydGk1RTdYUUVX… If there are PRs or issues you’d like us to review, please add GitHub links to them to the meeting agenda: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg -- Cheers, Inessa Inessa Pawson GitHub: inessapawson

1 6

Proposed feature: add custom lags parameters to correlate/convolve
by Honi Sanders May 7, 2026

May 7, 2026

Your message to the NumPy-Discussion mailing-list was rejected for the following reasons: The message is not from a list member The original message as received by Mailman is attached. From: Honi Sanders <sandersh6000(a)gmail.com <mailto:sandersh6000@gmail.com>> Subject: Proposed feature: add custom lags parameters to correlate/convolve Date: April 20, 2026 at 3:16:43 PM EDT To: numpy-discussion(a)python.org <mailto:numpy-discussion@python.org> Hello all, I'd like to solve a missing feature in np.correlate and np.convolve. Sometimes when computing a cross-correlation or convolution you are only interested in the result at a small number of lags. For example: Cross-correlating two long time series and wanting only the correlation within a bounded window around lag 0. Having millisecond-precision time series but only wanting convolution outputs at minute-scale lags. The current implementation computes every lag unconditionally — an expensive operation — even when most of the output is discarded. I wrote PR #31261 to address this: https://github.com/numpy/numpy/pull/31261 This PR revives an attempt from ten years ago (PR #5978 <https://github.com/numpy/numpy/pull/5978>) that attracted significant interest but I couldn't get it to Numpy’s high implementation standards. The feature was also raised as issues on NumPy (#5954 <https://github.com/numpy/numpy/issues/5954>) and SciPy (scipy/scipy#4940 <https://github.com/scipy/scipy/issues/4940>), discussed on the scipy-dev list <http://mail.scipy.org/pipermail/scipy-dev/2015-June/020757.html>, and got attention on Stack Overflow <https://stackoverflow.com/questions/30677241/how-to-limit-cross-correlation…> at the time. The current open issue it resolves is #17286 <https://github.com/numpy/numpy/issues/17286>. Proposed API np.correlate(a, v, mode=..., *, maxlag=None, lags=None) np.convolve(a, v, mode=..., *, maxlag=None, lags=None) np.correlate_lags(a_len, v_len, mode=..., *, maxlag=None, lags=None) Parameter design maxlag=M (int): symmetric inclusive window [-M, M] (2M+1 lags total). Matches MATLAB's xcorr(x, y, M) convention. lags=: a range, a slice with explicit start/stop, or a 1-D integer array-like containing an arithmetic progression. np.correlate_lags(a_len, v_len, ...): a companion function (modeled on scipy.signal.correlation_lags) that returns the array of lag indices corresponding to a given correlate or convolve call, without requiring the arrays themselves. Related library notes Matplotlib already has a maxlags argument on Axes.xcorr: https://github.com/matplotlib/matplotlib/blob/dde076379dad6a51374625dbaa729… Its current implementation calls numpy.correlate(..., 'full') and discards the unwanted entries — wasting a lot of calculations. NumPy implementing this feature would allow Matplotlib to immediately benefit in performance without changing their existing API by just updating the numpy correlate call. Neural network libraries like Pytorch and and mxnet rely on a stride parameter for their convolution functions to avoid calculating convolutions at every lag (e.g. https://docs.pytorch.org/docs/stable/generated/torch.nn.modules.conv.Conv1d…), similar to the stride entry in the range construction for the lags parameter proposed here. Previous discussions on this list https://mail.python.org/archives/list/numpy-discussion@python.org/thread/JM… https://mail.python.org/archives/list/numpy-discussion@python.org/thread/6F… (several people chimed in with interest in the feature) Open question: C API The PR also adds PyArray_CorrelateLags to the C API. I am not sure who the intended users of the C API are and whether they would be interested in this functionality as long as we are building it. Feedback welcome. Companion function The companion function that returns the matching lagvector is based on the scipy companion function that is called correlate_lags(). A name like generate_lagvector() would be more descriptive but inconsistent with scipy’s naming. Any thoughts on that? Thanks for your time, Honi

2 1

next NumPy New Contributors' Hour - Thursday, January 8th, 2026 at 10 pm UTC
by Inessa Pawson April 26, 2026

April 26, 2026

Our first New Contributors' Hour in 2026 will be held this Thursday, January 8th at 10 pm UTC. Stop by to ask questions, share your progress, or just to say hi. To add to the meeting agenda the topics you’d like to discuss, follow the link: https://hackmd.io/3f3otyyuTte3FU9y3QzsLg?both Join the meeting via Zoom: https://us06web.zoom.us/j/82563808729?pwd=ZFU3Z2dMcXBGb05YemRsaGE1OW5nQT09 -- Cheers, Inessa Inessa Pawson GitHub: inessapawson

1 3

"Backport" new DType API use to old DTypes
by Sebastian Berg April 24, 2026

April 24, 2026

Hi all, I would like a project like `ml_dtypes` to be able to transition to the new DType API, I believe that is vital to make easy. If anyone has concerns around this, please chime in. IMO, we need to just do this to move forward. I.e. provide an API that allows using the new DType API all the way back with NumPy 2.0 (by compiling with NumPy 2.5 or vendoring some code). [1] The trick being that we can use the new DType API, so long the DType still is "legacy" and thus uses all the old code paths (unless the new API clearly replaced them). Without such "backport" there is a problem that any regression/bug means that we can't use the new API until the buggy NumPy version is dropped and since nothing is bug-free that can be years of waiting... The path is the following PR https://github.com/numpy/numpy/pull/31302 * Create a new DType registration slot, where the old defining struct is passed in. (We'll use less and less of it over time.) * We have a `static inline` function in NumPy 2.5 (which downstream can vendor to compile with older NumPy versions!). This static inline function does a bit of a crazy dance, but the end result is a working "old but new" DType (`ml_dtypes` tests pass). This gives a path, and a path mean we can actually start deprecating things soon. Even if some things are baked in slightly more after this (I think this is rather little in practice), having a path now is still better than not. Now is also a great time, because it is a good time to drop NumPy <2. Testing is a bit hard. The truly exhaustive tests is probably just indirectly `ml_dtypes` (which google tests exhaustively). (The `ml_dtypes` pass completely with this approach.) Cheers, Sebastian [1] There is exactly one corner-case I saw, and that is that we print: `np.array(..., dtype=repr(dtype))` for these DTypes, while legacy ones printed `dtype=dtype.name`, which is a bit shorter. (We can change that in NumPy 2.5+, but not on old versions.)

2 2

Split docscrape out from numpydoc
by Lucas Colley April 21, 2026

April 21, 2026

Hi all, A while ago I proposed splitting docscrape out from the numpydoc repo: https://github.com/numpy/numpydoc/issues/619. Why? SciPy has a copy of the docscrape source which is used to generate some docstrings for the public API. Copying source code like this is never great given that the two copies can fall out of sync. Vendoring the entire numpydoc repo in SciPy, however, or adding numpydoc as a runtime dependency, seem off the table, making the situation worse rather than better. A better solution seems to be to have docscrape be a standalone project, which SciPy can vendor more easily, and which numpydoc can either depend on or vendor. From a modularity perspective at least this seems ideal — there are use-cases where you want docscrape, but not numpydoc, available at runtime. Joren suggested that I float this idea on the mailing list, given that he just submitted a patch to the copy in SciPy without realising that it was vendored code 😄. What I don't know is whether this would negatively impact maintenance burden etc.? I assume there will be a bit of upfront cost in restructuring the repos, and a little more if we decide to distribute docscrape as a standalone project, but my hope would be that this wouldn't cause any problems long-term? An alternative solution would be to extract the docscrape source from the numpydoc repo in a vendoring script in SciPy. While okay, that still leaves us having to track commits by hand instead of using e.g. a git submodule, and isn't robust to upstream changes of directory structure. Feedback appreciated! Eric Larson responded on the PR asking whether SciPy can introduce a dependency on numpydoc, but that is all so far. Cheers, Lucas

2 4

memory-efficient `np.cov` for `n_samples >> n_features`
by Bru April 21, 2026

April 21, 2026

Proposed new feature or change: `np.cov` centers its input by allocating `m - mean(m)`, a copy the size of `m`. When observations vastly outnumber variables, that copy dominates peak memory and wall time; the covariance matrix itself is tiny. I and potentially scikit-learn (cc. @ogrisel) would like to add an opt-in keyword that uses the algebraically equivalent post-hoc formula: cov = (m @ m.conj().T) / fact - (N / fact) * avg @ avg.conj().T It is already implemented here on scikit-learn: https://github.com/scikit-learn/scikit-learn/blob/94af1dff678e8a7a6fc627b85… I think this optimization should be put here, and we have many historical examples of this type of optimization on numpy. From the historical perspective: 1. In the PR #6403 (merged 2015), already halved `np.cov` memory; the ' m-mean` copy is what's left. 2. #13199 tracks the same class of problem for `np.var` and `np.std` (open). 3. #6231 proposes Welford's algorithm; that's orthogonal, because post-hoc pairs with BLAS `gemm`/`syrk` and Welford does not. #1696, #9631, #4694 cover the stability/memory tradeoff for variance-like reductions. Scikit-learn reimplements this locally and already shows strong benchmark results with this. `PCA(svd_solver="covariance_eigh")` does `C = X.T @ X - N * mean mean.T; C /= (N - 1)` ([source][sklearn-pca]) to avoid the copy. [scikit-learn#33573][] ([review comment][grisel-comment]) asks for this to move upstream. The small trade-off is that the post-hoc formula loses precision when `|avg|^2 / var(m)` is large; the reference that discusses this is Chan, T. F., Golub, G. H., & LeVeque, R. J. (1983). So the default stays safe. Callers who know their data is well-conditioned opt in. ## Proposal np.cov(m, ..., *, method="pre-center") # or "post-hoc" Weighted (`fweights`, `aweights`) and complex cases generalize without structural change. `corrcoef` could follow, but not in the first PR. Chan, T. F., Golub, G. H., & LeVeque, R. J. (1983). Algorithms for computing the sample variance: Analysis and recommendations. The American Statistician, 37(3), 242-247. [#6403]: https://github.com/numpy/numpy/pull/6403 [#13199]: https://github.com/numpy/numpy/issues/13199 [#6231]: https://github.com/numpy/numpy/issues/6231 [#1696]: https://github.com/numpy/numpy/issues/1696 [#9631]: https://github.com/numpy/numpy/issues/9631 [#4694]: https://github.com/numpy/numpy/issues/4694 [sklearn-pca]: https://github.com/scikit-learn/scikit-learn/blob/94af1dff678e8a7a6fc627b85… [scikit-learn#33573]: https://github.com/scikit-learn/scikit-learn/pull/33573 [grisel-comment]: https://github.com/scikit-learn/scikit-learn/pull/33573#discussion_r3101245… cc. @thomasjpfan, @ogrisel, @qbarthelemy, @betatim, @rgommers, @lucascolley. and FYI: @seberg and @eric-wieser

1 0

Fwd: Optional control over 0D array return behavior in PyArray_Return
by Breno Augusto Favaretto April 12, 2026

April 12, 2026

Hello NumPy developers, I would like to propose an optional mechanism to control the behavior of 0-dimensional array return conversion in PyArray_Return. Currently, 0D NumPy arrays are automatically converted into Python scalars in many operations. In some workflows, it is desirable to preserve the ndarray object instead. Proposed idea: - Introduce an opt-in mechanism (initially implemented as a global flag) to control whether 0D arrays are converted to scalars or preserved as ndarray objects. - Default behavior remains unchanged for full backward compatibility. Motivation: In certain array-centric workflows, implicit scalar conversion of 0D arrays can lead to loss of consistency when uniform ndarray behavior is desired. I have implemented a prototype PR here: <https://github.com/numpy/numpy/pull/31221> However, I was informed that this kind of change requires prior discussion on the mailing list before proceeding further. I would appreciate feedback on: - whether this direction is acceptable - whether a global flag is appropriate - or if an alternative design (context-local, function-level, etc.) would be preferred Thank you for your time.

4 3

SPy: a new companion static language for Python; thoughts?
by PIERRE AUGIER April 8, 2026

April 8, 2026

Hello, Do any of you follow SPy (https://github.com/spylang/spy), the new statically compiled variant of Python created by Antonio Cuni? I have been looking into it recently and became convinced it could have a significant impact on the Python ecosystem, including for numerical computing and libraries like NumPy. I wrote up my thoughts in a post entitled "SPy: a vision for its impact on the Python community": https://fluiddyn.pages.heptapod.net/spy-book/impact-on-python/ I would be very interested to hear what this community thinks, both about SPy itself and about the ideas in the post. Best, Pierre Augier (CNRS researcher in fluid mechanics, Grenoble)

3 2