Mailman 3 May 2024 - NumPy-Discussion

next NumPy triage meeting - May 29th, 2024 at 7 pm UTC
by Inessa Pawson 08 Dec '24

08 Dec '24

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 13

Fixing definition of reduceat for Numpy 2.0?
by Martin Ling 24 Nov '24

24 Nov '24

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 22 Nov '24

22 Nov '24

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

PR - can I get a new review?
by Jake S. 23 Jul '24

23 Jul '24

Hi community, PR 26081 <https://github.com/numpy/numpy/pull/26081> is about making numpy's ShapeType covariant and bound to a tuple of ints. The community has requested this occasionally in issue 16544 <https://github.com/numpy/numpy/issues/16544>. I'm reaching out via the listserv because it's been a few months, and I don't want it to get too stale. I could really use some help pushing it over the finish line. Summary: Two numpy reviewers and one interested community member reviewed the PR and asked for a type alias akin to npt.NDArray that allowed shape. I worked through the issues with TypeVarTuple and made npt.Array, and it was fragile, but passing CI. After a few months passed, I returned to fix the fragility in the hopes of getting some more attention, but now it fails CI in some odd builds (passes the mypy bit). I have no idea how to get these to pass, as they appear unrelated to anything I've worked on (OpenBLAS on windows, freeBSD...?). Thanks, Jake

3 4

next Documentation team meeting + poll for future meeting times
by Mukulika Pahari 03 Jun '24

03 Jun '24

Hi all, Our next Documentation Team meeting will happen on *Monday, May 20* at *11PM UTC*. ** Since we have requests to revisit the meeting time, please tell us your availability for future meetings here - https://www.when2meet.com/?25066561-WcODg ** 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

1 1

NumPy Optimization Team meeting - June 3rd, 5 pm UTC
by Inessa Pawson 31 May '24

31 May '24

The next NumPy Optimization Team meeting will be held this Monday, June 3rd 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 0

Condensing _fr0 and _fr1 into one function in getlimits.py
by trevor.depalatis＠gmail.com 27 May '24

27 May '24

Hello! I'm not sure if this is the right place to post, but I'm a first time contributor and I noticed that there might be some code in getlimits.py that could be condensed. It looks like from lines 16-30 there are two functions for fixing rank, "_fr0" and "_fr1", that could turn into one function, given how much code they both share. I'd love to implement this, but am I missing something significant that requires these two to be separate? Thanks for your time, Trevor

1 0

Question regarding transitioning native extension to NumPy 2.0
by Pavlyk, Oleksandr 24 May '24

24 May '24

I am working to transition mkl_fft and mkl_random to NumPy 2.0. Both of these projects contain native extensions. I have distilled unexpected behavior behind observed test failures in minimal C extension: https://github.com/oleksandr-pavlyk/reproducer-for-question-about-numpy2 The extension defines a single Python function which does expects numpy.ndarray, and queries its itemsize in two ways 1. By calling C function declared in "_aux.h" defined in "_aux.c" to call PyArray_ITEMSIZE and return the result 2. By calling PyArray_ITEMSIZE directly https://github.com/oleksandr-pavlyk/reproducer-for-question-about-numpy2/bl… The result obtained by calling C function is always 0, while direct call gives the correct result. I am hoping for advice about what is wrong and how to fix it. Thank you, Sasha

2 1

updating the NumPy roadmap
by Ralf Gommers 24 May '24

24 May '24

Hi all, Now that the dust has settled on what we're including in the NumPy 2.0 release, it felt like a good time to update the project roadmap. After a few discussions with other maintainers I opened https://github.com/numpy/numpy/pull/26505. Part of it is a regular maintenance update: remove what we've implemented or decided not to do, and rewrite existing roadmap entries to reflect their current state. The other part is adding some new items. In particular: 1. Under the documentation section, add that we plan to make all example code interactive via jupyterlite-sphinx 2. Under the "platform support" section, add that we aim to start supporting free-threaded CPython, and plan to better define platform support tiers 3. A new section " binary size reduction" 4. A new section "NumPy 2.0 stabilization & downstream usage" 5. A new section "Security" (focused on supply chain security) If you are interested in what will end up on the roadmap, please do review that PR. For major topics, this thread can be used. New ideas are of course welcome, in particular from NumPy team members and from contributors who plan to work on something large enough that it should be represented on the roadmap. As a reminder: the roadmap has no dates, and not everything on it is guaranteed to materialize. The first sentences of the roadmap explain the purposes: "This is a live snapshot of tasks and features we will be investing resources in. It may be used to encourage and inspire developers and to search for funding." We plan to keep the PR open for at least 10 days from now, or until discussion settles. Cheers, Ralf

1 0

ANN: NumPy 2.0 release date: 16 June 2024
by Ralf Gommers 23 May '24

23 May '24

Hi all, In yesterday's community meeting we discussed the 2.0 release schedule, and concluded that we are far enough along to pick a date for the final 2.0 release. That date will be June 16 (barring any major last-minute blockers appearing of course). A quick timeline: - `maintenance/2.0.x` branch creation: March 8 - beta 1: March 12 - release candidate 1: March 30 - release candidate 2: May 12 - as of today, 37 out of 58 of the downstream packages we're currently tracking at https://github.com/numpy/numpy/issues/26191 have done a 2.0-compatible release (including all of the ones lowest in the dependency tree that we were tracking early on), and many of the others have a release planned or 2.0 fixes merged or close to being complete. We've had 2.5 months of the release process, and very few blocking issues have been opened over the last weeks. Another 3.5 weeks should be enough for most package authors who still have work to do for their own releases, as well as for end users to test their code and either fix potential issues or temporarily add `numpy<2` constraints in the relevant places. In addition to this announcement email and the notice on https://github.com/numpy/numpy/issues/24300, we will update the numpy.org website and use our Twitter and LinkedIn project accounts to announce the release date. Thank you to everyone who helped us get so close to the finish line! Cheers, Ralf

1 0