Mailman 3 - NumPy-Discussion

next NumPy community meeting - June 5th, 2024 at 6 pm UTC
by Inessa Pawson 03 Nov '24

03 Nov '24

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 11

How do I use the numpy on spyder?
by Joao Pereira 31 Oct '24

31 Oct '24

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 31 Oct '24

31 Oct '24

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 30 Oct '24

30 Oct '24

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

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

29 Oct '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 10

next NumPy Optimization Team meeting - October 28th, 2024 at 5 pm UTC
by Inessa Pawson 28 Oct '24

28 Oct '24

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 0

Canonical way of serialising Generators
by Andrew Nelson 27 Oct '24

27 Oct '24

Hi all, is there a canonical way of serialising Generators (not via pickle). Would the following be reasonable for saving and restoring state: ``` def serialize_rng(rng): klass = rng.bit_generator.state['bit_generator'] entropy = rng.bit_generator.seed_seq.entropy return klass, entropy def deserialize_rng(klass, entropy, rng=None): if rng is not None and klass == rng.bit_generator.state['bit_generator']: rng.bit_generator.seed_seq.entropy = entropy return rng BG = getattr(np.random, klass) bg = BG(np.random.SeedSequence(entropy)) return np.random.default_rng(bg) ```

2 2

Endorsing SPECs 1, 6, 7, and 8
by Sebastian Berg 25 Oct '24

25 Oct '24

Hi all, TL;DR: NumPy should endorse some or all of the new SPECs if we like them. If you don't or do like them, please discuss, otherwise I suspect we will propose and endorsing them soon and do it if a few core maintainers agree. --- The Scientific Python project has the SPEC process to write up helpful tips/patterns [1] with the idea that projects "endorse" them to indicate that we think following the SPEC is a good idea. One example probably known best is SPEC 0, which is NEP 27 (the suggested minimum supported versions for dependencies, e.g. Python/library versions). There has been a lot of work recently to write some new SPECs, and the following ones are up for endorsement by NumPy: * 1 -- Lazy Loading of Submodules and Functions https://scientific-python.org/specs/spec-0001 * 6 -- Keys to the Castle https://scientific-python.org/specs/spec-0006/ * 7 -- Seeding Pseudo-Random Number Generation https://scientific-python.org/specs/spec-0007/ * 8 -- Securing the Release Process https://scientific-python.org/specs/spec-0008/ Endorsing them means we think they are good guidance for projects, not necessarily strictly following them [2]. Without input, I suspect we may endorse them soon (if a few maintainers give a thumbs up). But of course it would be great to discuss and maybe improve the SPECs in the progress! SPEC 7 is important, because it describes how we would like other libraries to use the new random number generation API in the future (but actually doesn't apply directly). Cheers, Sebastian [1] The SPECs are not necessarily fixed. If you think they are missing a note/solution, we can modify them. [2] With it's flat namespace, I am not sure e.g. lazy-loading is of much use to NumPy (just like we have longer compatibility than SPEC 0).

8 9

Re: np.ndenumerate doesn't obey mask?
by Stefano Miccoli 23 Oct '24

23 Oct '24

> On 22 Oct 2024, at 18:00, numpy-discussion-request(a)python.org wrote: > > From: Neal Becker <ndbecker2(a)gmail.com> > Subject: [Numpy-discussion] np.ndenumerate doesn't obey mask? > Date: 21 October 2024 at 18:52:41 CEST > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Reply-To: Discussion of Numerical Python <numpy-discussion(a)python.org> > > > I was using ndenuerate with a masked array, and it seems that the mask is ignored. Is this true? If so, isn't that a bug? > This is expected behaviour: you should use the function from the “.ma" namespace “numpy.ma.ndenumerate" <https://numpy.org/devdocs/reference/generated/numpy.ma.ndenumerate.html#num…> for skipping masked elements. By design numpy.enumerate does not skip masked elements. Stefano

1 0

np.ndenumerate doesn't obey mask?
by Neal Becker 21 Oct '24

21 Oct '24

I was using ndenuerate with a masked array, and it seems that the mask is ignored. Is this true? If so, isn't that a bug?

1 0