Mailman 3 October 2024 - NumPy-Discussion

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 Newcomers' Hour - June 27th, 2024 at 10 pm UTC
by Inessa Pawson March 31, 2025

March 31, 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 8

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

next NumPy Optimization Team meeting - October 28th, 2024 at 5 pm UTC
by Inessa Pawson Dec. 8, 2024

Dec. 8, 2024

Hi, all! The next NumPy Optimization Team meeting will be held TODAY, October 28th 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 2

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

How do I use the numpy on spyder?
by Joao Pereira Oct. 31, 2024

Oct. 31, 2024

I don´t know how to use the numpy on spyder. I have tried to use this line: "import numpy as np" but i dont know if it's the only necessary thing to do. If you could explain it to me I'll appreciate it.

2 1

C API could be more consistent with returning NPY_SUCCEED/NPY_FAIL
by sverre.hassing＠gmail.com Oct. 31, 2024

Oct. 31, 2024

While using the C API to work with Numpy arrays, I came across some inconsistencies regarding the return of a success state from various Numpy functions. For example, the array iterator functions return either NPY_SUCCEED (defined as 1) or NPY_FAIL (defined as 0) to indicate whether the function successfully finished. However, various of the array functions return -1 on success and 0 on failure. The result is similar enough, but I would think it more consistent to use NPY_SUCCEED/NPY_FAIL everywhere. As an example, consider the documentation pages for the Array API: https://numpy.org/doc/stable/reference/c-api/array.html and the Array iterator API: https://numpy.org/doc/stable/reference/c-api/iterator.html#array-iterator-a… I hope this is the right place to place this. It is the first time I really publicly engage with this kind of thing. This did not seem like a bug and the Github page indicated that feature requests should go to the mailing list first.

2 1

Suggestion to show the shape in repr for summarized arrays
by Marten van Kerkwijk Oct. 30, 2024

Oct. 30, 2024

Hi All, When the repr of an array is shown, currently the dtype and shape are explicitly listed if these cannot be directly inferred from the list that is shown, i.e., if the dtype is not float64 or int64, and if the size of the array is zero, but the shape not the simple (0,). For instance, ``` np.empty((10,2,0), dtype="i2") array([], shape=(10, 2, 0), dtype=int16) ``` I propose to also show the shape for the (rare) case that an array is summarized, i.e., when it has more than the default threshold of 1000 elements, and elements are replaced by `...`. The logic is that also in that case it is no longer clear what the shape actually is, which is useful information (e.g., if working in a notebook -- which is the original use case at https://github.com/numpy/numpy/issues/27461). I have a PR for that at https://github.com/numpy/numpy/pull/27482 which would lead to the following: ``` np.arange(1001) array([ 0, 1, 2, ..., 998, 999, 1000], shape=(1001,)) ``` Just to be sure: this PR causes *no* change for any arrays with sizes less than a 1000, so I do not believe this change will lead to a lot of unnecessary churn for down-stream packages. Indeed, between numpy and astropy (which has lots of doctests), the only changes to (doc)tests that were needed are the very few for arrays where the "threshold" is explicitly exceeded. One irritant is that the shape is not an argument that can be passed in to an `np.array` call. While this is just as much the case for zero-sized arrays, perhaps a better solution would be to move the shape information out of the parentheses, e.g., using ``...) # shape=(...)``. I can change the PR to do that if that's the consensus. All the best, Marten

5 5