Mailman 3 July 2024 - NumPy-Discussion

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 Documentation team meeting
by Mukulika Pahari May 5, 2025

May 5, 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 community meeting - June 5th, 2024 at 6 pm UTC
by Inessa Pawson March 22, 2025

March 22, 2025

The next NumPy community meeting will be held this Wednesday, June 5th at 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 19

next NumPy triage meeting - May 29th, 2024 at 7 pm UTC
by Inessa Pawson Jan. 5, 2025

Jan. 5, 2025

The next NumPy triage meeting will be held this Wednesday, May 29th at 7pm UTC. This is a meeting where we synchronously triage prioritized PRs and issues. Join us via Zoom: https://numfocus-org.zoom.us/j/82096749952?pwd=MW9oUmtKQ1c3a2gydGk1RTdYUUVX… . Everyone is welcome to attend and contribute to a conversation. 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

Fixing definition of reduceat for Numpy 2.0?
by Martin Ling Nov. 24, 2024

Nov. 24, 2024

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

5 10

New matvec and vecmat functions
by Marten van Kerkwijk Nov. 22, 2024

Nov. 22, 2024

Hi All, I have a PR [1] that adds `np.matvec` and `np.vecmat` gufuncs for matrix-vector and vector-matrix calculations, to add to plain matrix-matrix multiplication with `np.matmul` and the inner vector product with `np.vecdot`. They call BLAS where possible for speed. I'd like to hear whether these are good additions. I also note that for complex numbers, `vecmat` is defined as `x†A`, i.e., the complex conjugate of the vector is taken. This seems to be the standard and is what we used for `vecdot` too (`x†x`). However, it is *not* what `matmul` does for vector-matrix or indeed vector-vector products (remember that those are possible only if the vector is one-dimensional, i.e., not with a stack of vectors). I think this is a bug in matmul, which I'm happy to fix. But I'm posting here in part to get feedback on that. Thanks! Marten [1] https://github.com/numpy/numpy/pull/25675 p.s. Separately, with these functions available, in principle these could be used in `__matmul__` (and thus for `@`) and the specializations in `np.matmul` removed. But that can be a separate PR (if it is wanted at all).

7 18

next NumPy Optimization Team meeting - June 24th, 2024 at 5 pm UTC
by Inessa Pawson Oct. 4, 2024

Oct. 4, 2024

The next NumPy Optimization Team meeting will be held this Monday, June 24th at 5 pm 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 5

Windows 11 arm64 wheel
by slobodan.miletic＠endava.com Sept. 25, 2024

Sept. 25, 2024

Hi, I am writing on behalf of my team from Endava company. Our task is to work with opensource community, and setup multiple applications for use on win11 arm64 machines. One of the tasks is to understand the problems and if possible help NumPy team in setting up win11 arm64 compatible wheel on the PyPi. I saw that there were some earlier discussions about this subject, and as I understood problem was that at that moment this configuration was not so common and there were no appropriate CI slaves to create the wheel. Today there are more devices in this configuration available on the market and additional are announced, so I wanted to check if there are plans for creating this wheel, and if we can somehow help with that work? Regards, Slobodan

5 10

Applying a function on local environments
by langthom＠forwiss.uni-passau.de July 27, 2024

July 27, 2024

Dear all, my goal would be to apply some function on a local environment of size K x K x K where K is bigger than 1 and odd. For example, if K = 3, it would be nice to apply some function "func" on such an environment around each n-dimensional position within the n-dimensional array. So, for K = 3 and the position (1,1,1) if a 3D array, one would collect the array values at the positions X = [(0,0,0),(0,0,1),(0,0,2),(0,1,0),...(2,2,2)] (K**3 = 27 in total in this example) and yield those values to "func". The result value at position (1,1,1) in the output array would be y = func(X). The same would apply for all entries excluding the padding area (or according to some padding policy). While I coded this many times on plain buffers in C++, I was wondering if there would be an *efficient* way to do this in numpy? Up to now I relied on the ndenumerate way of iterating n-dimensional arrays and aggregating the values using slices, but this turns out to be unbearably slow even for quite small arrays :-/ Is there a better "numpy-isque" way to do this? I thought of writing a custom view or subclassing, but the efficient aggregation of local environments using the ndenumerate and slice approach is slow, yet in C/C++ random access and native support for parallelism (by means of OpenMP) would drastically accelerate this. Or would it even be preferred to add this functionality to the library? I could imagine a special view, e.g., "LocalEnvironmentArrayView" or just a simple function with the intended usage something like the following: * a = ... # some n-dimensional numpy array * func = lambda env: np.mean(env) - np.std(env) * w = numpy.apply_on_local_environments(a, func, environment_size=3) So, each entry in the interior (or also the boundary, depending on the padding policy) of w would correspond to the evaluation of func on that local environment. Best regards, Thomas

5 5

A better syntax for using ufunc.at?
by Oras P. July 25, 2024

July 25, 2024

I am aware that to do unbuffered addition operation, I can use `np.add.at` like this: ``` np.add.at(arr, idxs, vals) ``` I think this syntax looks a bit unnatural, and it is not obvious what it does at first glance. An idea I have is to use a custom accessor, like ``` arr.at[idxs] += vals # or arr.unbuffered[idxs] += vals ``` While I'm not fluent in Numpy's working mechanisms, this seems possible to implement by just having the method `.at`/`.unbuffered` return a reference to the original array with a special flag set, then make the `+=` operator, etc check this flag and use the unbuffered operation accordingly. Has this kind of feature been proposed at all? I did try to search Github and this mailing list for something similar, but I'm quite new to numpy development, so apologies in advance if this is not the right place to ask.

3 4