Mailman 3 July 2026 - NumPy-Discussion

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

Sept. 27, 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 15

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

Sept. 20, 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

2 5

ENH: Add np.sinpi et al following CPython core, C23 & IEEE754-2019
by Jeff Epler Sept. 13, 2026

Sept. 13, 2026

In a recently merged PR (https://github.com/python/cpython/pull/150555), CPython has added a family of "*pi" functions to the math module, which take half-turn arguments instead of radians. One reason these functions are advantageous is that it's easy to provide the property that `sinpi(n/2)` is exact for all integers n, while `sin(pi*n)` is never exactly equal to the mathematical ideal except for n=0. These functions are recommended by IEEE754-2019 and standardized in C23 Annex G. (note: I'm reading C23 draft revised 2023-01-24, not the final standard document; and I do not have IEEE754-2019). C23 and CPython only added the real-valued versions of these functions, but C23 "future library directions" notes that identifiers like `csinpi` are "potentially reserved identifiers." Since CPython only requires C11, CPython includes implementations of these functions for when the underling platform library does not provide it. These implementations work by performing special case handling & range reduction, followed by a call to the standard trig function with a scaled argument (in the case of forward functions) or scaling of the result (in the case of inverse/arc functions). I am interested in doing the numpy implementation, however I have never done core numpy work before. If there is interest from the project, I would like to initially offer a PR containing a single function such as `sinpi` and then complete the others following numpy core developer feedback. Thanks, Jeff PS I notice via the archives that there are occasional "New Contributors' Hour" meetings. Is the next one scheduled yet?

8 8

next NumPy New Contributors' Hour - Thursday, May 28th, 2026 at 10 pm UTC
by Inessa Pawson Aug. 17, 2026

Aug. 17, 2026

Our next New Contributors' Hour will be held this Thursday, May 28th 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 2

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