Mailman 3 December 2025 - NumPy-Discussion

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

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

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

NumPy <1.x with Python 3.14 is fundamentally broken
by Sebastian Berg Jan. 18, 2026

Jan. 18, 2026

Hi all, a small piece of information: NumPy 1.x was not released with support for Python 3.14. Most of the time, a too new Python versions (in recent past) just broke compilation. However, this time around optimization work together with the one bit of arcane optimization tricks in NumPy *will* cause silently incorrect results in most non-trivial code [1]. There are no releases to yank or upper bounds to set so I didn't think we can actually do anything about it. But this just came up again (this time in pandas). IThe only (new) idea I have would be to upload a Python 1.26 + Python 3.14 wheel that includes no code besides raising an error at install time. (Anyone who is running into issues is compiling NumPy from scratch, but I guess they would probably use the wheel first if available.) Cheers, Sebastian [1] May affect windows builds less badly, where NumPy doesn't do this trick, but what does it matter....

5 5

next NumPy triage meeting - Wednesday, May 28th, 2025 at 5 pm UTC
by Inessa Pawson Jan. 4, 2026

Jan. 4, 2026

The next NumPy triage meeting will be held this Wednesday, May 28th at 17:00 (5 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… Please notify us of issues or PRs that you’d like to have reviewed by adding a GitHub link to them in the meeting agenda: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg -- Cheers, Inessa Inessa Pawson GitHub: inessapawson

1 14

Are optimization for array_equal implementation welcome?
by Mark Harfouche Dec. 23, 2025

Dec. 23, 2025

The current array_equal implementation allocates an intermediate array for the elementwise comparison of the two input arrays. it would be great to do all this in c that is something like a reduction operation. I say this because certain workflows (zarr) like to check for equality against "zero" and simply not encode the data to avoid extra files on disk. this inevitably means that something like a full memory copy of your array is allocated for this equality check, which should only have a memory footprint of O(1) instead of O(n) which it has now. Are PRs welcome to implement optimize this? https://github.com/numpy/numpy/blob/67fc5c311eea54b27e43c2c769b3b8f878ae43f… Selfishly, I would love to optimize the equal_nan=False usecase first, but perhaps with AI assistants, we can do both in 1 shot.... Let me know your thoughts Best, Mark

3 2

NumPy 2.4.0 released
by Charles R Harris Dec. 20, 2025

Dec. 20, 2025

Hi All, On behalf of the NumPy team, I'm pleased to announce the release of NumPy 2.4.0. The NumPy 2.4.0 release continues the work to improve free threaded Python support, user dtypes implementation, and annotations. There are many expired deprecations and bug fixes as well. This release supports Python versions 3.11-3.14. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/2.4.0>; release notes and the changelog are available on Github <https://github.com/numpy/numpy/releases/tag/v2.4.0>. *Highlights* Apart from annotations and `same_value` kwarg, the 2.4 highlights are mostly of interest to downstream developers. They should help in implementing new user dtypes. - Many annotation improvements. In particular, runtime signature introspection. - New `casting` kwarg `'same_value'` for casting by value. - New `PyUFunc_AddLoopsFromSpec` function that can be used to add user sort loops using the `ArrayMethod` API. - New `__numpy_dtype__` protocol. *Contributors* A total of 142 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - !DWesl - !MyUserNameWasTakenLinux + - !ianlv + - !kostayScr + - !olivier + - Aadya Chinubhai + - Aaron Kollasch + - Abdu Zoghbi + - Abhishek Kumar - Abhishek Tiwari + - Adam Turner + - Akhil Kannan + - Aleksandr A. Voyt + - Amelia Thurdekoos + - Andrew Nelson - Angus Gibson + - Anik Chand + - Aniket Singh Yadav + - Ankit Ahlawat + - Arthur Lacote + - Ben Woodruff - Bernard Roesler + - Brad Smith + - Britney Whittington + - Carlos Martin - Charles Harris - Charlie Lin + - Chris Navarro - Christian Barbia + - Christian Bourjau + - Christine P. Chai - Christopher Sidebottom - Clément Robert - Copilot + - Dan Raviv + - Daniel Bertalan + - David Seifert + - Dennis Van de Vorst + - Developer-Ecosystem-Engineering - Diego Atencia + - Dillon Niederhut - Dimitri Papadopoulos Orfanos - Diya Singh + - Evgeni Burovski - Faizan-Ul Huda + - François Rozet - Germán Godoy Gutierrez + - Gubaydullin Danis + - Guido Imperiale - Hamza Meel + - Hannah Aizenman - Henry Schreiner - Hunter Hogan + - Iason Krommydas + - Inessa Pawson - Jake VanderPlas - Jingu Kang + - Joe Rickerby + - Johnnie Gray + - Jonathan Reimer + - Joren Hammudoglu - Kaiyuan Yang + - Kelvin Li + - Khelf Mohamed + - Koki Watanabe + - Kumar Aditya + - Leonardo Paredes + - Lucas Colley - Lysandros Nikolaou - Maanas Arora - Marc Redemske + - Marco Barbosa - Marco Edward Gorelli - Mark Ryan - Marten van Kerkwijk - Maryanne Wachter - Mateusz Sokół - Matthias Bussonnier - Matti Picus - Melissa Weber Mendonça - Michael Davidsaver - Michael Siebert - Michał Górny - Mohammed Abdul Rahman - Mohammed Zuhaib + - Mohit Deoli + - Moritz Groß + - Mugundan Selvanayagam - Muhammad Maaz + - Mukulika Pahari - Nathan Goldbaum - Nicholas Bidler + - Paresh Joshi + - Parsa Shemirani + - Paul Caprioli + - Phoenix Studio + - Pieter Eendebak - Rafael Laboissière + - Raghuveer Devulapalli - Ralf Bürkle + - Ralf Gommers - Richard Smythe + - Riku Sakamoto + - Rohit Goswami - Ross Barnowski - Rupesh Sharma + - Sachin Shah + - Samruddhi Baviskar + - Sandeep Gupta + - Sandro + - Sanjay Kumar Sakamuri Kamalakar + - Sarang Joshi + - Sayed Awad - Sebastian Berg - Sergey Fedorov + - Shirong Wang + - Shyok Mutsuddi + - Simola Nayak + - Stan Ulbrych - Steven Hur + - Swayam Singh + - T.Yamada + - Tim Hoffmann - Timileyin Daso + - Tobias Markus + - Tontonio3 + - Toshaksha + - Trey Cole + - Tyler Reddy - Varad Raj Singh + - Veit Heller + - Vineet Kumar + - Wang Yang (杨旺) - Warren Weckesser - William Pursell + - Xiaoyu + - Yasir Ashfaq + - Yuki K - Yuvraj Pradhan - Zebreus + - Zhi Li + - dependabot[bot] Cheers, Charles Harris

1 0

ENH: Add float16, npy_half, specific routines to the NumPy C-API as NpyHalf*
by Amelia Thurdekoos Dec. 11, 2025

Dec. 11, 2025

Current situation float16, npy_half, is currently handled through a set of helper functions located in numpy/halffloat.h and implemented in npymath. This requires linking against the libnpymath.a, a static library. Linking against a static library is problematic as a static library built with one compiler often cannot be linked with an application built with a different compiler. See #20880 <https://github.com/numpy/numpy/issues/20880>. Goal Expose halffloat.h functionality through the regular NumPy C-API as NpyHalf*, without requiring the linking of npymath explicitly as a step toward removing the npymath static library altogether. Proposed ImplementationSummary - I propose to add a new NumPy C-API file in the multiarray C extension directory as NpyHalf*, with the primary design objective to eliminate the need for an explicit link to libnpymath.a. Implementation Specifics - All functionality currently available in include/halffloat.h will be duplicated into multiarray/*.h, which will be the primary entrance point of the API. Whether the include/halffloat.h functionality will be duplicated in its own file, or incorporated into an existing header, is still an open question. - The naming convention will be NpyHalf* for all API functions. See appendix A for an explicit list of functions currently contained in include/halffloat.h. - Functionality will be identical to include/halffloat.h.but the interface will be inline with the existing C-API patterns and may not be a one to one copy of the interface present in include/halffloat.h. - All API functions will be added to code_generators/numpy_api.py beginning at location 369, and counting up. Versioning will be MinVersion("2.4"). With code_generators/cversions.txt updated with new hashing information. - The contents of npymath relevant to ensuring proper working of NpyHalf* will be ported and contained in the multiarray directory. - If I identify any shared functions used in include/halffloat.h that may assist in the removal of npymath static library altogether I'll contain the functions in a suitable header file. Error Handling and Semantics - Error handling will follow the normal NumPy conventions. - Current semantics, behavior of code that use include/halffloat.h will remain unchanged and continue to produce identical results. Documentation - New C-API documentation will be added as needed. - Documentation requiring include/halffloat.h and npymath will be updated with language that the new NpyHalf* functions are preferred. With additional language to require accessing import_array() for access to NpyHalf* API functionality. Testing and Benchmarking - A review of current tests seems to indicate a lack of float16 specific tests. I will develop and add tests to cover NpyHalf* functions. - Benchmarking will be completed so as not to unduly decrease performance. NumPy Internals Update - There are several internal self contained NumPy functions that point to include/halffloat.h and npymath. For the sake of completeness I will update and refactor these functions to the new API. Conclusion and Community Feedback - I'm planning to begin work on adding a new NumPy C-API file in the multiarray C extension directory as NpyHalf* soon. - I have posted this as issue #30280 <https://github.com/numpy/numpy/issues/30280>, in addition to this email. Any feedback is, as always, much appreciated. Appendix A - List of Functions in include/halffloat.h /* include/halffloat.h */ float npy_half_to_float(npy_half h);double npy_half_to_double(npy_half h);npy_half npy_float_to_half(float f);npy_half npy_double_to_half(double d);�/* Comparisons */int npy_half_eq(npy_half h1, npy_half h2);int npy_half_ne(npy_half h1, npy_half h2);int npy_half_le(npy_half h1, npy_half h2);int npy_half_lt(npy_half h1, npy_half h2);int npy_half_ge(npy_half h1, npy_half h2);int npy_half_gt(npy_half h1, npy_half h2);/* faster *_nonan variants for when you know h1 and h2 are not NaN */int npy_half_eq_nonan(npy_half h1, npy_half h2);int npy_half_lt_nonan(npy_half h1, npy_half h2);int npy_half_le_nonan(npy_half h1, npy_half h2);�/* Miscellaneous functions */int npy_half_iszero(npy_half h);int npy_half_isnan(npy_half h);int npy_half_isinf(npy_half h);int npy_half_isfinite(npy_half h);int npy_half_signbit(npy_half h);npy_half npy_half_copysign(npy_half x, npy_half y);npy_half npy_half_spacing(npy_half h);npy_half npy_half_nextafter(npy_half x, npy_half y);npy_half npy_half_divmod(npy_half x, npy_half y, npy_half *modulus); /* Bit-level conversions */npy_uint16 npy_floatbits_to_halfbits(npy_uint32 f);npy_uint16 npy_doublebits_to_halfbits(npy_uint64 d);npy_uint32 npy_halfbits_to_floatbits(npy_uint16 h);npy_uint64 npy_halfbits_to_doublebits(npy_uint16 h); -- Amelia Thurdekoos Staff Software Engineer, Quansight Quansight | Your Data Experts w: www.quansight.org <http://quansight.org/> e: athurdekoos(a)quansight.com <https://www.linkedin.com/company/quansight/> <https://www.instagram.com/quansightai/> <https://bsky.app/profile/quansight.com> <https://twitter.com/quansightai>

7 17

Proposed enhancement: Finite Zipf distribution for NumPy
by Warren Weckesser Dec. 10, 2025

Dec. 10, 2025

NumPy implements the Zipf distribution (also known as the zeta distribution), as `random.Generator.zipf(a, size=None)`. This is a discrete distribution with infinite support {1, 2, 3, ...}. The PMF of the distribution is p(k, a) = k**-a / zeta(a), a > 1, k = 1, 2, 3, ..., where zeta(a) is the Riemann zeta function (https://en.wikipedia.org/wiki/Riemann_zeta_function). (Technically, NumPy's implementation is limited to the maximum representable 64 bit integer integer, but the intent is to model the infinite support.) The distribution is implemented in SciPy as `scipy.stats.zipf`. A variation of this distribution is the finite Zipf distribution. It has finite support {1, 2, 3, ..., n}, and the PMF is p(k, a, n) = k**-a / H(n, a), a >= 0, k = 1, 2, ..., n where H(n, a) is the generalized harmonic number. In SciPy, this distribution is implemented in `scipy.stats.zipfian`. I have an implementation of an efficient rejection method for the finite distribution that is currently in a SciPy pull request: https://github.com/scipy/scipy/pull/24011. I think this would make a good addition to NumPy. We wouldn't need a new method; this could be implemented by adding the `n` parameter to the existing `zipf` method of `numpy.random.Generator`, so the signature becomes zipf(a, size=None, *, n=None) The default n=None preserves the current behavior. When `n` is a positive integer, variates from the finite distribution are generated. Because the finite distribution has no convergence limitation for the normalizing constant, the constraint on `a` in that case can be broadened to `a >= 0`. Notes on the implementation are at https://github.com/WarrenWeckesser/experiments/tree/main/python/numpy/rando…, and some validation scripts are in https://github.com/WarrenWeckesser/experiments/tree/main/python/scipy/test-…. API-wise, this is a small change to NumPy. Also, the algorithm is a straightforward implementation of the rejection method (well, "straightforward" if you are already familiar with the general idea), so the implementation should be easy to understand and maintain. Why add it to both SciPy and NumPy? Ideally, this would just be in NumPy, and SciPy could start using it reliably once the NumPy version with the enhancement becomes the oldest supported NumPy version. But the current SciPy implementation of random variate generation when 0 <= a <= 1 is very slow, so I would like to also have this available in SciPy sooner than later. When the NumPy version with the enhancement is the oldest version supported by SciPy, SciPy can remove its implementation and use NumPy. What do you think? Warren

3 4

next NumPy New Contributors' Hour - Thursday, December 11th, 2025 at 10 pm UTC
by Inessa Pawson Dec. 7, 2025

Dec. 7, 2025

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