Mailman 3 September 2024 - NumPy-Discussion

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

12 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 9

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

07 Oct '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 9

next Documentation team meeting
by Mukulika Pahari 06 Oct '24

06 Oct '24

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

1 6

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

04 Oct '24

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

What should remain on PyPi
by Charles R Harris 02 Oct '24

02 Oct '24

Hi All, I just got through deleting a bunch of pre-releases on PyPi and it occurred to me that we should have a policy as to what releases should be kept. I think that reproducibility requires that we keep all the major and micro versions, but if so, we should make that an official guarantee. Perhaps a short NEP? This might even qualify for an SPEC. Thoughts? Chuck

6 6

Suggestion to show the shape in repr for summarized arrays
by Marten van Kerkwijk 01 Oct '24

01 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

4 4

I am getting an error in anaconda jupyter notebook, I am unable to solve. please help me.
by Usha Gayatri 01 Oct '24

01 Oct '24

This is the error i am getting when trying to execute import numpy as np File E:\anaconda3\Lib\site-packages\pandas\_libs\interval.pyx:1, in init pandas._libs.interval() ValueError: numpy.dtype size changed, may indicate binary incompatibility. Expected 96 from C header, got 88 from PyObject

2 1

Re: Extend ldexp to handle complex inputs
by Stefano Miccoli 27 Sep '24

27 Sep '24

‘np.ldexp’ exists mainly for compatibility with the C/C++ functions ldexp, ldexpf, ldexpl, which are defined for float/double/long double. Quoting the C refs: > On binary systems (where FLT_RADIX is 2), ldexp is equivalent to scalbn. > The function ldexp ("load exponent"), together with its dual, frexp, can be used to manipulate the representation of a floating-point number without direct bit manipulations. > On many implementations, ldexp is less efficient than multiplication or division by a power of two using arithmetic operators. So in general I do not think that extending ‘np.ldexp’ to complex makes much sense, since it would be peculiar to numpy implementation and destroy the C/C++ equivalence. Stefano

1 0

Extend ldexp to handle complex inputs
by Carlos Martin 25 Sep '24

25 Sep '24

Currently, [ldexp](https://numpy.org/doc/stable/reference/generated/numpy.ldexp.html) throws a TypeError on a complex input: ```python3 import numpy as np def naive_ldexp(x, n): return x * 2**n def new_ldexp(x, n): if np.iscomplex(x): y = np.empty_like(x) y.real = np.ldexp(x.real, n) y.imag = np.ldexp(x.imag, n) return y else: return np.ldexp(x, n) def main(): x = 2.2 + 3.3j n = 3 print(naive_ldexp(x, n)) print(new_ldexp(x, n)) print(np.ldexp(x, n)) if __name__ == "__main__": main() ``` ``` (17.6+26.4j) (17.6+26.4j) Traceback (most recent call last): File "test.py", line 34, in <module> main() File "test.py", line 30, in main print(np.ldexp(x, n)) ^^^^^^^^^^^^^^ TypeError: ufunc 'ldexp' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe'' ``` This can easily be solved by applying ldexp to the real and imaginary parts of the input, as shown in the function new_ldexp above.

2 1

Windows 11 arm64 wheel
by slobodan.miletic＠endava.com 25 Sep '24

25 Sep '24

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