Mailman 3 March 2025 - NumPy-Discussion

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

April 3, 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 20

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

next NumPy Newcomers' Hour - June 27th, 2024 at 10 pm UTC
by Inessa Pawson Sept. 12, 2025

Sept. 12, 2025

Our next Newcomers' Hour will be held TOMORROW, June 27th at 10 pm UTC. Stop by to ask questions, share your progress, celebrate success, 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 11

next NumPy triage meeting - Wednesday, January 22nd, 2025 at 6 pm UTC
by Inessa Pawson May 11, 2025

May 11, 2025

The next NumPy triage meeting will be held this Wednesday, January 22nd at 18:00 UTC. As always, 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 7

next Documentation team meeting
by Mukulika Pahari May 4, 2025

May 4, 2025

Hi all, Our next Documentation Team meeting will happen on *Monday, July 15* at *7PM UTC*. All are welcome - you don't need to already be a contributor to join. If you have questions or are curious about what we're doing, we'll be happy to meet you! If you wish to join on Zoom, use this (updated) link: https://numfocus-org.zoom.us/j/85016474448?pwd=TWEvaWJ1SklyVEpwNXUrcHV1YmFJQ... Here's the permanent hackmd document with the meeting notes (still being updated): https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg Hope to see you around! Best wishes, Mukulika

2 18

next NumPy triage meeting - Wednesday, April 2nd, 2025 at 5 pm UTC - now meeting ONE HOUR EARLIER
by Inessa Pawson March 30, 2025

March 30, 2025

Hi, everyone! The next NumPy triage meeting will be held this Wednesday, April 2nd at 17:00 (5 pm) UTC. Please note the TIME CHANGE! 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 0

Moving the meetings schedule to one hour earlier
by Sebastian Berg March 30, 2025

March 30, 2025

Hi all, it's that time of the year again where daylight savings time starts (the US had it already and Europe will have it now). I suggest we "realign" our meeting to this time zone (since it is scheduled as UTC), I think for our typical crowd that is the nicer time slot. (I would slightly prefer to move it, but am OK either way.) - Sebastian

3 3

Enforce array (no-scalar) return with out=... in ufuncs
by Sebastian Berg March 26, 2025

March 26, 2025

Hi all, Since it is an API decision, I have an open PR: https://github.com/numpy/numpy/pull/28576 To allow `out=...` in ufuncs (yes, three dots, the Ellipsis). NumPy normally has the bad habit of always returning scalars rather than 0-D arrays. Passing `out=...` would be one way to ensure arrays are always returned. I have picked it because: 1. to me `out=np.ndarray` might indicate no subclasses or be weird if e.g. cupy supports it (via `__array_ufunc__`). 2. `...` allures to `arr1d[0, ...]` in indexing, where including `...` ensures an array return even if it does nothing else. This is useful in a few places in NumPy, the main reason is if you have `dtype=object`. IMO, this doesn't preclude a general transition towards returning scalars less aggressively (or never), but to me it is easy and useful enough to do, even if we might have a better solution in the future. If no-one has concerns, I think we'll merge this soon, but I am always happy to hear opinions! Cheers, Sebastian PS: This PR is about ufuncs, I suppose a few odd functions might "inherit" it. We may want to allow it for other functions that have an `out=`, but it is not the case yet.

1 0

Proposal to Extend NumPy Broadcasting for (D₁, D₂, ..., N, M) → (D₁, D₂, ..., K, M) When K is a Multiple of N (K % N == 0)
by Shasang Thummar March 25, 2025

March 25, 2025

Dear NumPy Developers, I hope you are doing well. I am writing to propose an enhancement to NumPy’s broadcasting mechanism that could make the library even more powerful, intuitive, and flexible while maintaining its memory efficiency. ## **Current Broadcasting Rule and Its Limitation** As per NumPy's current broadcasting rules, if two arrays have different shapes, the smaller array can be expanded **only if one of its dimensions is 1**. This allows memory-efficient expansion of data without copying. However, if a dimension is greater than 1, NumPy **does not** allow expansion to a larger size, even when the larger size is a multiple of the smaller size. ### **Example of Current Behavior (Allowed Expansion)** ```python import numpy as np A = np.array([[1, 2, 3]]) # Shape (1,3) B = np.array([[4, 5, 6], # Shape (2,3) [7, 8, 9]]) C = A + B # Broadcasting works because (1,3) can expand to (2,3) print(C) *Output:* [[ 5 7 9] [ 8 10 12]] Here, A has shape (1,3), which is automatically expanded to (2,3) without copying because *a dimension of size 1 can be stretched*. However, *NumPy fails when trying to expand a dimension where N > 1, even if the larger size is a multiple of N*. *Example of a Case That Fails (Even Though It Could Work)* A = np.array([[1, 2, 3], # Shape (2,3) [4, 5, 6]]) B = np.array([[10, 20, 30], # Shape (4,3) [40, 50, 60], [70, 80, 90], [100, 110, 120]]) C = A + B # Error! NumPy does not allow (2,3) to (4,3) *This fails with the error:* ValueError: operands could not be broadcast together with shapes (2,3) (4,3) *Why Should This Be Allowed?* If *a larger dimension is an exact multiple of a smaller one*, then logically, the smaller array can be *repeated* along that axis *without physically copying data*—just like NumPy does when broadcasting (1,M) to (N,M). In the above example, - A has shape (2,3), and B has shape (4,3). - Since 4 is *a multiple of* 2 (4 % 2 == 0), A could be *logically repeated 2 times* to become (4,3). - NumPy *already does* a similar expansion when a dimension is 1, so why not extend the same logic? *Proposed Behavior (Expanding N → M When M % N == 0)* Allow an axis with size N to be broadcast to size M *if and only if M is an exact multiple of N (M % N == 0)*. This is *just as memory-efficient* as the current broadcasting rules because it can be done using *stride tricks instead of copying data*. *Example of the Proposed Behavior* If NumPy allowed this new form of broadcasting: A = np.array([[1, 2, 3], # Shape (2,3) [4, 5, 6]]) B = np.array([[10, 20, 30], # Shape (4,3) [40, 50, 60], [70, 80, 90], [100, 110, 120]]) # Proposed new broadcasting rule C = A + B print(C) *Expected Output:* [[ 11 22 33] [ 44 55 66] [ 71 82 93] [104 115 126]] This works by *logically repeating A* to match B’s shape (4,3). *Why This is a Natural Extension of Broadcasting* - *Memory Efficiency:* Just like broadcasting (1,M) to (N,M), this expansion does *not* require physically copying data. Instead, strides can be adjusted to *logically repeat elements*, making this as efficient as current broadcasting. - *Intuitiveness:* Right now, broadcasting already surprises new users. If (1,3) can become (2,3), why not (2,3) to (4,3) when 4 is a multiple of 2? This would be a more intuitive rule. - *Extends Current Functionality:* This is *not* a new concept—it *extends the existing rule* where 1 can be stretched to any value. We are generalizing it to *any factor relationship* (N → M when M % N == 0). *Implementation Considerations* The logic behind NumPy’s current broadcasting already uses *stride tricks* for memory-efficient expansion. Extending it to handle (N, M) → (K, M) (where K % N == 0) would require: - Updating np.broadcast_shapes(), np.broadcast_to(), and related functions. - Extending the existing logic that handles expanding 1 to support factors as well. - Ensuring backward compatibility and maintaining performance. *Conclusion* I strongly believe this enhancement would make NumPy’s broadcasting *more powerful, more intuitive, and just as efficient as before*. The fact that we can implement this *without unnecessary copying* makes it a natural extension of the existing feature. I would love to hear the NumPy team’s thoughts on this! If the community is open to it, I am also interested in contributing to its implementation. Looking forward to your feedback! Best regards, *Shasang Thummar* shasangthummar4(a)gmail.com

5 4

17ᵗʰ Advanced Scientific Programming in Python in Plovdiv, Bulgaria, 21–28 September, 2025
by Tiziano Zito March 24, 2025

March 24, 2025

ASPP2025: 17ᵗʰ Advanced Scientific Programming in Python Summer School ====================================================================== https://aspp.school Scientists spend more and more time writing, maintaining, and debugging software. While techniques for doing this efficiently have evolved, only few scientists have been trained to use them. As a result, instead of doing their research, they spend far too much time writing deficient code and reinventing the wheel. In this course we will present a selection of advanced programming techniques and best practices which are standard in the industry, but especially tailored to the needs of a programming scientist. Lectures are interactive and allow students to acquire direct hands-on experience with the topics. Students will work in pairs throughout the school and will team up to practice the newly learned skills in a real programming project — an entertaining computer game. We use the Python programming language for the entire course. Python works as a simple programming language for beginners, but more importantly, it also works great in scientific simulations and data analysis. Python is the standard tool for the programming scientist due to clean language design, ease of extensibility, and the great wealth of open source libraries for scientific computing and data visualization. This school is targeted at PhD students, postdocs and more senior researchers from all areas of science. Competence in Python or in another language such as Java, JavaScript, C/C++, MATLAB, or R is absolutely required. Basic knowledge of Python and git or another version control system is assumed. Participants without any prior experience with Python or git should work through the proposed introductory material before the course. We care for diversity and inclusion, and strive for a welcoming atmosphere to programming scientists of all levels. In particular, we have focused on recruiting an international and gender-balanced pool of students. Date & Location =============== 21–28 September, 2025. Plovdiv, Bulgaria. Application =========== You can apply online: https://aspp.school Application deadline: 23:59 UTC, Sunday 1 June, 2025. There will be no deadline extension, so be sure to apply on time. Invitations and notifications of rejection will be sent by Sunday 15 June, 2025. Participation is for free, i.e. no fee is charged! Participants however should take care of travel, living, and accommodation expenses by themselves. Program ======= • Large-scale collaborative scientific code development with git and code forges • Testing and debugging scientific code • Organizing, documenting, and distributing scientific code • Data in scientific programming • Scientific programming patterns in Python • What every scientist should know about computer architecture • Writing parallel applications in Python • Programming in teams Faculty ======= • Aitor Morales-Gregorio, Faculty of Mathematics and Physics, Charles University, Prague, Czechia • Guillermo Aguilar, Department of Computational Psychology, Technische Universität Berlin, Germany • Jenni Rinker, Department of Wind and Energy Systems, Technical University of Denmark, Lyngby, Denmark • Lisa Schwetlick, Laboratory of Psychophysics, EPFL, Lausanne, Switzerland • Pamela Hathway, YPOG, Berlin/Nürnberg, Germany • Pietro Berkes, NAGRA Kudelski, Lausanne, Switzerland • Rike-Benjamin Schuppner, Institute for Theoretical Biology, Humboldt-Universität zu Berlin, Germany • Tiziano Zito, innoCampus, Technische Universität Berlin, Germany • Victoria Shevchenko, Inria Saclay Palaiseau and Université Paris Cité, France • Zbigniew Jędrzejewski-Szmek, Red Hat Inc., Warsaw, Poland Organizers ========== Head of the organization for ASPP and responsible for the scientific program: • Tiziano Zito, innoCampus, Technische Universität Berlin, Germany Organization team in Plovdiv: • Maya Ivanova Nikolova, MNKnowledge, Sofia, Bulgaria • Verjinia Metodieva, Charité – Universitätsmedizin Berlin, ECN, Germany Sponsors ======== ASPP2025 is hosted by the Technical University of Sofia, Plovdiv branch. The organization is done in collaboration with MNKnowledge and with the financial and institutional support of the Tübingen AI Center. Website: https://aspp.school Contact: info(a)aspp.school

1 0