Mailman 3 July 2026 - NumPy-Discussion

next NumPy community meeting - Wednesday, July 29th, 2026 at 18:00 UTC
by Inessa Pawson Aug. 9, 2026

Aug. 9, 2026

The next NumPy community meeting will be held this Wednesday, July 29th at 18:00 (6 pm) UTC. 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 1

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

NumPy 2.5.2 release schedule
by Charles R Harris July 31, 2026

July 31, 2026

Hi All, I had originally planned to release 2.5.2 this weekend. Because Python 3.15.0rc1 is scheduled for next Tuesday (8/5/2026) I have decided to delay until after that release and the expected release of a matching cibuildwheel. That should allow a bit more time for some of the pending backports. Chuck

1 0

Adding axis/axes argument on np.searchsorted
by Iason Krommydas July 30, 2026

July 30, 2026

Hi all, There is an open request regarding adding axis support on np.searchsorted: https://github.com/numpy/numpy/issues/4224 I was going to take that task as part of my current internship but this seems like it needs a good API design decision. The idea was to turn the searchsorted internals into a gufunc. In the past week I've posted some thoughts regarding the gufunc signature on that thread at the bottom and a few people have chimed in and are sharing thoughts on what the signature and the high-level API should be. The jax team have also shared their API for a searchsorted implementation that is currently private in jax. I am sending this message to just share that thoughts and help are needed here so please chime in the numpy issue if you have any opinions. Cheers, Iason.

1 0

C99 Annex G recoveries for complex multiplication and division
by Iason Krommydas July 29, 2026

July 29, 2026

Hi all, I would like to briefly talk about https://github.com/numpy/numpy/pull/30806 which adds C99 Annex G recoveries for complex multiplication and division that would otherwise result in nan + nanj. CPython has already implemented this and I attempted bringing this into numpy. However, after all the investigation that you can see in the PR thread (and a short discussion with Nathan Goldbaum), we're leaning towards not doing this. If you look a the latest benchmarks at the bottom of the PR thread, this adds a small but noticeable overhead even in the cases where there are no recoveries to be done. Another thing is that no other array libraries like jax or cupy do this so this would lead to different results among them. I'm bringing this up in the mailing list to see if any other people have thoughts and agree or disagree with NOT doing this. I'm looking for arguments on why we should do this too if you have any. Keep in mind that this closes at least 4 issues listed in the PR description that should probably be closed as "won't do" if the decision is to not have this feature in. Please share any thoughts you might have. Kind regards, Iason.

1 0

Feature proposal: linear-domain averaging for logarithmic values (e.g. dB/dBm)
by Martijn Hiemstra July 28, 2026

July 28, 2026

Hello NumPy developers, I would like to propose adding a helper function for averaging values that are represented in logarithmic units. A common situation in signal processing and related fields is that values are stored as logarithms (for example dB or dBm), but the physically meaningful average is the arithmetic mean in the linear domain. The result then needs to be converted back to logarithmic units. For dB-like quantities this operation is: log_mean = 10 * log10(mean(10 ** (x / 10))) where x contains logarithmic values. For x = [-30, -20] the function would yield -21.19 (and not -25). Currently this requires users to manually write the conversion, which is easy to get wrong because taking the arithmetic mean directly in dB space is not equivalent. Another motivation for providing this as a dedicated NumPy feature is performance. While the operation can currently be expressed using existing NumPy primitives, the expression requires multiple passes and intermediate arrays A possible API could be something like: np.logmean(x, base=10, factor=10, axis=-1) The function would be analogous to other reduction operations such as mean, but would perform the averaging in the corresponding linear domain. I understand NumPy generally avoids domain-specific functions, so I am interested in feedback on whether this belongs in NumPy or whether it would be better suited for another package. I mainly wanted to raise the question because this operation appears frequently in RF, acoustics, and signal-processing workflows and has a clear mathematical definition. Thanks for your thoughts. Best regards, Martijn Hiemstra

2 1

numpy.unwrap changes targeting 2.6.0 (new _unwrap gufunc)
by Iason Krommydas July 22, 2026

July 22, 2026

Hi all, In gh-31848 <https://github.com/numpy/numpy/pull/31848>, numpy.unwrap has been reimplemented as a generalized ufunc, targeting the 2.6.0 release. Below is a summary of what's changing. The core of unwrap is now a generalized ufunc written in C++. That is a new private ufunc _unwrap with signature (n),(),()->(n), covering the floating point and signed integer dtypes, computed in a single pass without the intermediate arrays the previous python implementation had to allocate. We've seen that this offers a 2x-3x speedup and lower memory usage. As a result, unwrap now preserves ndarray subclasses instead of always returning a base ndarray. The one exception is masked arrays. A mask-aware unwrap is genuinely ill-defined for this algorithm, so masked arrays (and their subclasses) get unmasked and the operation runs on a plain ndarray instead, same as before. I will open a separate issue and have put a TODO in the codebase to perhaps get a proper mask-aware unwrap in the np.ma module. Two edge-case behavior changes: - An explicitly typed discont argument wider than the result dtype used to get promoted. It's now compared at the result dtype instead. This can change the result by up to ~1 ULP in that specific case. - Calling unwrap with an unsigned integer period that can't represent the values needed internally used to raise OverflowError (from an internal mod call). it now raises TypeError (a "no loop found" ufunc error reporting the mismatched dtypes) instead. If you maintain an array library that implements __array_ufunc__ and tries to stay compatible with all of numpy, you'll now see a call to _unwrap where unwrap previously dispatched through a sequence of familiar public ufuncs (subtract, remainder, cumsum, etc.). If your override doesn't recognize _unwrap but still handles those underlying ops, unwrap falls back to a pure Python path built from them, so things should keep working. If it declines everything unconditionally, unwrap will now raise instead of silently doing the wrong thing. Astropy is the library we know of that might care here, flagging in case others maintain something similar. Kind regards, Iason.

1 0

ANN: numexpr 2.14.2 is out
by Francesc Alted July 18, 2026

July 18, 2026

========================= Announcing NumExpr 2.14.2 ========================= Hi everyone, NumExpr 2.14.2 is a maintenance release with several bug fixes, a new ``disable_cache`` option for ``evaluate()``, and updated build/CI support (Windows ARM64 wheels, dropped Python 3.10, no more free-threaded 3.13 wheels). Project documentation is available at: https://numexpr.readthedocs.io/ Changes from 2.14.1 to 2.14.2 ----------------------------- * Added a ``disable_cache`` parameter to ``evaluate()`` to bypass the internal expression cache. Thanks to 27rabbitlt. * Added Windows ARM64 wheel builds. * Dropped support for Python 3.10. * No longer build free-threaded Python 3.13 wheels, matching NumPy's own support. * Avoid keeping arrays passed as ``out=`` alive in the ``re_evaluate`` cache (#558). * Guarded out-of-range shift counts (shift amount >= bit width) in the integer ``<<``/``>>`` opcodes, which was undefined behavior in C and could return garbage results. Thanks to uwezkhan (#559). * Fixed ``run_interpreter()`` unconditionally returning success even when the VM engine failed, so execution errors are now correctly raised instead of silently discarded (#557). * Fixed a reference leak of ``constsig`` on the allocation-failure path in ``NumExpr_init()`` (#561). What's Numexpr? --------------- Numexpr is a fast numerical expression evaluator for NumPy. With it, expressions that operate on arrays (like "3*a+4*b") are accelerated and use less memory than doing the same calculation in Python. It has multi-threaded capabilities, as well as support for Intel's MKL (Math Kernel Library), which allows an extremely fast evaluation of transcendental functions (sin, cos, tan, exp, log...) while squeezing the last drop of performance out of your multi-core processors. Look here for a some benchmarks of numexpr using MKL: https://github.com/pydata/numexpr/wiki/NumexprMKL Its only dependency is NumPy (MKL is optional), so it works well as an easy-to-deploy, easy-to-use, computational engine for projects that don't want to adopt other solutions requiring more heavy dependencies. Where I can find Numexpr? ------------------------- The project is hosted at GitHub in: https://github.com/pydata/numexpr You can get the packages from PyPI as well (but not for RC releases): http://pypi.python.org/pypi/numexpr Documentation is hosted at: http://numexpr.readthedocs.io/en/latest/ Share your experience --------------------- Let us know of any bugs, suggestions, gripes, kudos, etc. you may have. Enjoy data!

1 0

Android and iOS promoted to Tier 3 platforms
by Ralf Gommers July 18, 2026

July 18, 2026

Hi all, We just had two very long-running PRs merged to add source-level support and CI jobs for Android and iOS. Kudos to Malcolm Smith and Russell Keith-Magee for getting those PRs, and all the work needed for it in CPython, PyPI, cibuildwheel, auditwheel, Meson, meson-python, pip, uv and perhaps more tools in good shape. The NumPy PRs themselves are now pretty straightforward, mostly test suite skips because these platforms don't support subprocesses (just like Pyodide). For those who are interested in the details: https://github.com/numpy/numpy/pull/28759 https://github.com/numpy/numpy/pull/30412 I just opened a PR to document the Tier 3 promotion in NEP 57: https://github.com/numpy/numpy/pull/32032. Both platforms should support the Limited C API and Stable ABI just fine. Experimental work in NumPy is ongoing to figure out if we can support that at the source level (see https://github.com/numpy/numpy/issues/31913); for mainstream platforms it's likely not okay performance-wise to ship only Stable ABI wheels, but for newer/niche/legacy platforms, that could be a solution to keep the wheel build load manageable. So when the people supporting these platforms come asking for Tier 2 status after running in CI without problems for a couple of months, we have a potential solution that doesn't explode our wheel build matrix (the queue for these requests is long: RISC-V, Pyodide, Android, iOS, ppc64le). For right now, it's now straightforward to build numpy wheels from source (or grab them off of a regular CI job as artifact), so if anyone is interested in trying out NumPy on their phone, now is a good time to do so. Cheers, Ralf

2 1

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