Mailman 3 February 2026 - NumPy-Discussion

next NumPy triage meeting - Wednesday, February 18th, 2026 at 18:00 UTC
by Inessa Pawson Aug. 1, 2026

Aug. 1, 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 11

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

July 17, 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 25

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

July 11, 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 32

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

Current policy on AI-generated code in NumPy
by David Cournapeau March 4, 2026

March 4, 2026

Hi, I know there has been discussions in the past on AI-generated contributions. Is there a current policy for NumPy ? E.g. do we request that contributors are the "sole contributor" to the written code, or do we allow code written by AI as long as it follows the usual quality requirements ? Context of my question: ~18 months ago I started in some spare time writing an ARPACK-replacement in numpy/scipy during scipy sprint. At that time, I used ChatGPT for the "research part" only: literature review, explain to me some existing BSD implementation in Julia for points I could not understand. I implemented the python code myself. There is still quite a bit of work needed to be a viable replacement for ARPACK. Seeing the progress of the AI tooling in my team at work, and how I myself use those tools for other hobby projects, I believe I could finish that replacement very quickly with those tools today. But I don't want to "taint" the work if this would risk the chances of integration into scipy proper. Thanks, David

24 120

Fixing definition of reduceat for Numpy 2.0?
by Martin Ling Feb. 27, 2026

Feb. 27, 2026

Hi folks, I don't follow numpy development in much detail these days but I see that there is a 2.0 release planned soon. Would this be an opportunity to change the behaviour of 'reduceat'? This issue has been open in some form since 2006! https://github.com/numpy/numpy/issues/834 The current behaviour was originally inherited from Numeric, and makes reduceat often unusable in practice, even where it should be the perfect, concise, efficient solution. But it has been impossible to change it without breaking compatibіlity with existing code. As a result, horrible hacks are needed instead, e.g. my answer here: https://stackoverflow.com/questions/57694003 Is this something that could finally be fixed in 2.0? Martin

6 12

Polyvalnd, a new function to evaluate multivariate polynomials in any number of variables?
by Singer, Leo P. (GSFC-6610) Feb. 24, 2026

Feb. 24, 2026

Hi, Maintainer ngoldbaum suggested that I ping the list to open a discussion about the suitability of this feature request to add polyvalnd, a function for evaluating multivariate polynomials in any number of variables. The proposed interface is derived from polyval, polyval2, and polyval3d. https://github.com/numpy/numpy/issues/30857 Thanks, Leo [cid:D393E7F1-35AA-48E4-8167-7EE15BD0C51F]<https://www.nasa.gov/> Dr. Leo P. Singer Research Astrophysicist Astroparticle Physics Laboratory NASA Goddard Space Flight Center, Code 661 8801 Greenbelt Rd., Greenbelt, MD 20771 leo.p.singer(a)nasa.gov

1 0

Re: Current policy on AI-generated code in NumPy
by Matthew Brett Feb. 21, 2026

Feb. 21, 2026

Hi, On Sat, Feb 21, 2026 at 2:02 PM Ilhan Polat <ilhanpolat(a)gmail.com> wrote: > > I think we will not convince each other in this subject. My position is still the same; > > Ignoring the actual stealing done by these companies and then holding each other accountable for copyright is a no-go for me, using it further to resolve copyright issues, and thus washing it clean, is doubly so. I will not entertain that option and that's my personal position. I don't expect others to take this position. Defending copyright protection and ignoring the largest copyrighted elephant in the room does not seem a sound argument to me. Moreover, arguing over the tool as if it is oblivious and neutral is just factually incorrect, there are companies behind these tools. The technology is undoubtedly impressive and very useful, however the current arrangement of it is built upon legally unsound basis with very shady practices. Therefore I refuse to philosophize over it as a free-agent with shortcomings. In my opinion, the possible thing we can do is at least be defensive and if we feel like it, take advantage of LLMs to use it for automating mundane tasks to save time that FOSS maintainers definitely lack which is what I have been doing with LAPACK translation as I mentioned above. I still go over them line by line which takes insane amount of time though much shorter than writing it myself. > > So "No AI contribution is allowed" is a valid take for me if that would be the policy. Or "we will use common sense and make opinionated decisions, for trivial and otherwise laborious tasks we don't care but for involved bits, we won't touch it". It is also fine. I'm not sure we are really disagreeing here - I think you're pointing out something that you've made clear from the work you're doing - that for mechanical tasks, where an expert can check the results carefully, AI is a sensible use, and we have less concern about copyright. So I agree, either policy would be fine with me. And I agree, either would be preferable to the compromise that I'm suggesting for not-trivial / mechanical AI-generated code, where we try to work out some procedure whereby the contributor can screen for copyright violations. Cheers, Matthew

1 0

[RFC] SIMD sin/cos for NumPy 2.5.0 (PR #29699)
by Sayed Adel Feb. 21, 2026

Feb. 21, 2026

Hi all, Some context on PR #29699: https://github.com/numpy/numpy/pull/29699 It integrates numpy-simd-routines (https://github.com/numpy/numpy-simd-routines), a cross-platform SIMD math library built on top of Google Highway — similar to Intel SVML but supporting a wide range of architectures and independent from libm to guarantee symmetric numeric behavior. It is still a WIP with more kernels on the way. Floating-point behavior is configurable at compile time per function. Current defaults target ~1 ULP for double and ~4 ULP for single. Build-time configuration will be exposed soon, and we may add limited runtime control — likely just ULP tolerance — though that would require extending NEP-54 or a new one. Thanks! -- Cheers, Sayed Sayed Awad GitHub: seiko2plus

1 0

[ANN] PyData/Sparse 0.18.0 released
by Hameer Abbasi Feb. 19, 2026

Feb. 19, 2026

PyData/Sparse is a library providing N-dimensional sparse arrays for the PyData ecosystem. This release focuses on expanded array API compatibility, developer experience, and QoL fixes. Repo: https://github.com/pydata/sparse Docs: https://sparse.pydata.org/en/0.18.0/ Issue Tracker: https://github.com/pydata/sparse/issues Changelog What's Changed * Implementing `repeat` function by @prady0t in https://github.com/pydata/sparse/pull/875 * Adding `tile` function by @prady0t in https://github.com/pydata/sparse/pull/880 * Setting `boolean indexing` flag to False by @prady0t in https://github.com/pydata/sparse/pull/884 * Adding `unstack` function by @prady0t in https://github.com/pydata/sparse/pull/883 * Fixing `check_zero_fill_value` by @prady0t in https://github.com/pydata/sparse/pull/886 * Running codecov only when tests pass by @prady0t in https://github.com/pydata/sparse/pull/887 * Adding `diff` function by @prady0t in https://github.com/pydata/sparse/pull/888 * Making benchmarking tests deterministic by @prady0t in https://github.com/pydata/sparse/pull/891 * Migration guide by @hameerabbasi in https://github.com/pydata/sparse/pull/898 * Lock mlir to python <3.14 by @prady0t in https://github.com/pydata/sparse/pull/906 * feat: Add sparse.interp function for numba backend by @peanutfun in https://github.com/pydata/sparse/pull/903 * Update Finch notebook by @mtsokol in https://github.com/pydata/sparse/pull/911 * BUG: asarray: fix default format for `SparseArray` input by @lucascolley in https://github.com/pydata/sparse/pull/918 * [pre-commit.ci] pre-commit autoupdate by @pre-commit-ci[bot] in https://github.com/pydata/sparse/pull/916 * BLD/DEV/CI: better Pixi setup by @lucascolley in https://github.com/pydata/sparse/pull/920 * ENH: transition to SciPy sparse arrays from matrices by @lucascolley in https://github.com/pydata/sparse/pull/919 * DEV/CI: use Pixi for examples, notebooks, and xp-tests by @lucascolley in https://github.com/pydata/sparse/pull/922 New Contributors * @peanutfun made their first contribution in https://github.com/pydata/sparse/pull/903 * @lucascolley made their first contribution in https://github.com/pydata/sparse/pull/918 Full Changelog: https://github.com/pydata/sparse/compare/0.17.0...0.18.0

1 0