Mailman 3 May 2026 - NumPy-Discussion

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

June 7, 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 8

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

June 5, 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 23

A numerical issue related to fp limitations
by Friedrich Romstedt May 29, 2026

May 29, 2026

Hi, This is about an fp issue I stumbled upon while determining the order of magnitude of some fp number. It occured to me while determining the appropriate *prefix* of a unit, given some *numerical value* carrying the unit. The prefix to determine (denoted by an underscore '_') can arise in the unit (based on e.g. 'm' for meter) in any arbitrary power. In the most simple case, as in '_m', the power of the prefix is 1, but e.g. in '1 / _m^2', the power is -2. I am explaining the problem here as it occurs with: - A prefix "u" (micro), carrying 1000 ** -2 as the coefficient; - A power of the prefix of -2; - A numerical value of 10 ** 12, for which the prefix shall be determined. I am comparing the numerical value with the prefix coefficient, raised to the prefix power. The power of the prefix coefficient is called the "prefix value". For *negative* prefix powers, the correct prefix is the *smallest* one, where it holds: numerical value >= prefix value Here, for a prefix power of -2, and the prefix 'u' (1000 ** -2 = 10 ** -6), mathematically the prefix value is (10 ** -6) ** -2 = 10 ** 12, which is just the numerical value, so the abovementioned comparison should be fulfilled as numerical value == prefix value. Technically I am obtaining: 1. The numerical value (10 ** 12) is 1000000000000. 2. The prefix value however, (10 ** -6) ** -2, is 10000000000.0001. Here, where the numerical value and the prefix value should coincide, the numerical value is smaller than the prefix value: numerical value - prefix value = -0.000122... so the 'u' prefix is mistakenly rejected, as "numerical value >= prefix value" is not fulfilled. I kind-of-fixed it utilising numpy.nextafter: stepnumerical = numericalvalue - numpy.nextafter(numericalvalue, 0) stepprefix = prefixvalue - numpy.nextafter(prefixvalue, 0) and replacing the condition "numerical value >= prefix value" by: numerical value - prefix value >= -(stepnumerical + stepprefix) In the singleton example discussed here, this remedies the flaw. It *seems*, that the error of the final figures "numerical value" and "prefix value" is not larger than the error resulting from their limited number of fp digits. However, I am unsure if this can be used *always* as the decisive threshold. I could speculate that the fp uncertainty of intermediate numbers might carry through, so that the overall error margin is even larger than the one implied by the limitedness of the *final* number of binary digits. This suspection applies most prominently to the "prefix value". One idea would be to use a multiple of the numpy.nextafter result. However, 2x (2 bits), 4x (3 bits), ...? I think that the approach using numpy.nextafter is valid, but my use is currently a little heuristic. Any idea, comment or pointer would be welcome very much. I'd like to sort this problem thoroughly. Best, Friedrich

1 1

Change return type of Histogramdd and Histogram
by Joseph Mehdiyev May 26, 2026

May 26, 2026

Currently histogramdd (and histogram2d) converts the histogram to floats to preserve a behavior seen a decade ago. This is of course inconsistent with the np.histogram and I think it should be changed at this point. The fix is quite trivial, just wanted to discuss this with someone before I open a PR. Best, Joseph Related: https://github.com/numpy/numpy/issues/7845 https://mail.python.org/archives/list/numpy-discussion@python.org/thread/NI…

2 3

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

May 25, 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 0

NumPy 2.5.x branched
by Charles R Harris May 24, 2026

May 24, 2026

Hi All, NumPy maintenance/2.5.x has been branched and main is ready for 2.6.0 development. Cheers, Charles Harris

1 0

NumPy 2.4.6 released.
by Charles R Harris May 19, 2026

May 19, 2026

Hi All, On behalf of the NumPy team, I'm pleased to announce the release of NumPy 2.4.6. NumPy 2.4.6 is a quick release that fixes a regression discovered in the 2.4.5 release. This release supports Python versions 3.11-3.14. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/2.4.6>; release notes and the changelog are available on Github <https://github.com/numpy/numpy/releases/tag/v2.4.6>. *Contributors* A total of 4 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - !EarlMilktea - Charles Harris - Sebastian Berg - Warren Weckesser *Pull requests merged* A total of 4 pull requests were merged for this release. - #31444: MAINT: Prepare 2.4.x for further development - #31453: BUG: Fix regression in ``arr.conj()`` - #31459: BUG: ``np.linalg.svd(..., hermitian=True)`` returns non-unitary... - #31460: BUG: Don't call INCREF/DECREF on descr in NpyStringAcquireAllocator... Cheers, Charles Harris

1 0

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

NumPy 2.4.5 Released
by Charles R Harris May 15, 2026

May 15, 2026

Hi All, On behalf of the NumPy team, I'm pleased to announce the release of NumPy 2.4.5. NumPy 2.4.5 is a patch release that fixes bugs discovered after the 2.4.4 release, has some typing improvements, and maintains infrastructure. This release supports Python versions 3.11-3.14. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/2.4.5>; release notes and the changelog are available on Github <https://github.com/numpy/numpy/releases/tag/v2.4.5>. *Contributors* A total of 17 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Aleksei Nikiforov - Anarion Zuo + - Ankit Ahlawat - Breno Favaretto + - Charles Harris - Igor Krivenko + - Ijtihed Kilani + - Joren Hammudoglu - Maarten Baert + - Matti Picus - Nathan Goldbaum - Praneeth Kodumagulla + - Ralf Gommers - RoomWithOutRoof + - Sebastian Berg - Warren Weckesser - div + *Pull requests merged* A total of 28 pull requests were merged for this release. - #31093: MAINT: Prepare 2.4.x for further development - #31182: TYP: fix ``np.shape`` assignability issue for python lists (#31171) - #31197: ENH: Return rank 0 for empty matrices in matrix_rank (#30422) - #31198: CI/BUG: add native jobs for s390x, fix bug in ``pack_inner``... - #31199: BUG: f2py map complex_long_double to NPY_CLONGDOUBLE - #31205: MAINT: f2py: Stop setting re._MAXCACHE to 50. - #31206: BUG: fix heap buffer overflow in timedelta to string casts - #31207: MAINT: Rename ppc64le and s390x workflow (#31121) - #31208: BUG: Fix matvec/vecmat in-place aliasing (out=input produces... - #31209: TYP: ``tile``\ : accept numpy scalars and arrays as second argument... - #31211: DEP: Undo deprecation for np.dtype() signature used by old pickles... - #31212: REV: Manual revert of float16 svml use (#31178) - #31222: TYP: ``ix_`` fix for boolean and non-1d input (#31218) - #31329: BUG: incorrect temp elision for new-style (NEP 43) user-defined... - #31330: TYP: fix sliding_window_view axis parameter typing - #31335: BUG: Prevent deadlock due to downstream importing NumPy in dlopen... - #31336: BUG: Fix segfault in nditer.multi_index when __getitem__ raises... - #31338: TYP: Fix ruff lint error - #31357: BUG: fix memory leak in np.zeros when fill-zero loop raises (#31320) - #31358: BUG: np.einsum() fails with a 0-dimensional out argument and... - #31379: BUG: Fix signed overflow issue in npy_gcd for INT_MIN on s390x... - #31383: CI: remove Cirrus CI FreeBSD job (#31380) - #31390: BUILD: newer MKL uses so.3 - #31391: BLD/MAINT: improve support for Intel LLVM compilers - #31401: BUG: Avoid UB in safe_[add,sub,mul] helpers (#31396) - #31402: BUG: exclude __pycache__ directories from wheels (#31397) - #31404: TYP: ``_NestedSequence`` type parameter default to work around... - #31426: TYP: Fix ``DTypeLike`` runtime type-checker support (#31425) Cheers, Charles Harris

1 0

Promoting RISC-V to a Tier 3 supported platform
by Ralf Gommers May 12, 2026

May 12, 2026

Hi all, There has been sustained interest in, and responsive contributors for, RISC-V support in NumPy. There are now self-hosted runners from the RISE project (https://riseproject.dev/), which we're about to get green (I hope) on https://github.com/numpy/numpy/pull/30995. Their interest extends to adding RISC-V as a supported platform for which we ship wheels on PyPI - see https://github.com/numpy/numpy/issues/30216. It seems a little too early to consider crossing that bridge today, but it's an up-and-coming platform so it's fairly likely that we'll consider it in the future I'd think. For now, I propose we add RISC-V as a Tier 3 platform at https://numpy.org/neps/nep-0057-numpy-platform-support.html#tier-3, next to ppc64le and Pyodide. That means we have CI support and contributors who have stuck up their hand and can be pinged in case of platform-specific issues that need addressing. We also have SIMD and CPU detection code specific to RISC-V, so having native runners in CI will be quite helpful either way. And hopefully we can disable the slow QEMU-based job once we're happy with the self-hosted runners. Thoughts or concerns? Cheers, Ralf

4 3