Mailman 3 July 2024 - NumPy-Discussion

numpy-user-dtypes updated for NumPy 2.0
by Nathan 17 Jul '24

17 Jul '24

Hi all, I just pushed some commits to the numpy-user-dtypes repo ( https://github.com/numpy/numpy-user-dtypes) that fixes compatibility with the public version of the DType API that shipped in NumPy 2.0. If you’ve been waiting for some runnable examples to look at before trying to write your own DType, wait no more! Also Swayam Singh, an intern at Quansight Labs this summer, will be working on an extended precision float DType in the user dtypes repo to hopefully allow a migration path for users of the NumPy 80 bit long double DType so NumPy can eventually deprecate and remove it. If you’re curious about any of that please subscribe to the repo and open issues or respond here. Nathan

2 2

next Documentation team meeting
by Mukulika Pahari 15 Jul '24

15 Jul '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 0

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

14 Jul '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 3

Enhancement for generalized ufuncs
by Warren Weckesser 12 Jul '24

12 Jul '24

I have implemented quite a few generalized ufuncs over in ufunclab (https://github.com/WarrenWeckesser/ufunclab), and in the process I have accumulated a gufunc "wish list". Two items on that list are: (1) the ability to impose constraints on the core dimensions that are checked when the gufunc is called. By far the most common use-case I have is requiring that a dimension have length at least 1. To do this currently, I check the shapes in the ufunc loop function, and if they are not valid, raise an exception and hope that the gufunc machinery processes it as expected when the loop function returns. (Sorry, I'm using lingo--"loop function", "core dimension", etc--that will be familiar to those who already know the ufunc C API, but not so familiar to general users of NumPy.) (2) the ability to have the output dimension be a function of the input dimensions, instead of being limited to one of the input dimensions or an independent dimension. Then one could create, for example, a 1-d convolution gufunc with shape signature that is effectively `(m),(n)->(m + n - 1)` (corresponding to `mode='full'` in `np.convolve`) and the gufunc code would automatically allocate the output with the correct shape and dtype. I have proposed a change in https://github.com/numpy/numpy/pull/26908 that makes both these features possible. A field is added to the PyUFuncObject that is an optional user-defined C function that the gufunc author implements. When a gufunc is called, this function is called with an array of the values of the core dimensions of the input and output arrays. Some or all of the output core dimensions might be -1, meaning the arrays are to be allocated by the gufunc/iterator machinery. The new "hook" allows the user to check the given core dimensions and raise an exception if some constraint is not satisfied. The user-defined function can also replace those -1 values with sizes that it computes based on the given input core dimensions. To define the 1-d convolution gufunc, the actual shape signature that is passed to `PyUFunc_FromFuncAndDataAndSignature` is `(m),(n)->(p)`. When a user passes arrays with shapes, say, (20,) and (30,) as the input and with no output array specified, the user-defined function will get the array [20, 30, -1]. It would replace -1 with m + n - 1 = 49 and return. If the caller *does* include an output array in the call, the core dimension of that array will be the third element of the array passed to the user-defined function. In that case, the function verifies that the value equals m + n - 1, and raises an exception if it doesn't. Here's that 1-d convolution, called `conv1d_full` here, in action: ``` In [14]: import numpy as np In [15]: from experiment import conv1d_full In [16]: type(conv1d_full) Out[16]: numpy.ufunc ``` `m = 4`, `n = 6`, so the output shape is `p = m + n - 1 = 9`: ``` In [17]: conv1d_full([1, 2, 3, 4], [-1, 1, 2, 1.5, -2, 1]) Out[17]: array([-1. , -1. , 1. , 4.5, 11. , 9.5, 2. , -5. , 4. ]) ``` Standard broadcasting: ``` In [18]: conv1d_full([[1, 2, 3, 4], [0.5, 0, -1, 1]], [-1, 1, 2, 1.5, -2, 1]) Out[18]: array([[-1. , -1. , 1. , 4.5 , 11. , 9.5 , 2. , -5. , 4. ], [-0.5 , 0.5 , 2. , -1.25, -2. , 1. , 3.5 , -3. , 1. ]]) ``` Comments here or over in the pull request are welcome. The essential changes to the source code are just 7 lines in `ufunc_object.c` and 7 lines in `ufuncobject.h`. The rest of the changes in the PR create a couple gufuncs that use the new feature, with corresponding unit tests. Warren

2 4

Windows 11 arm64 wheel
by slobodan.miletic＠endava.com 12 Jul '24

12 Jul '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

4 4

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

12 Jul '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 1

Next NumPy Newcomers' Hour - July 11th, 2024 at 12 PM UTC
by Ganesh Kathiresan 11 Jul '24

11 Jul '24

Our next Newcomers' Hour will be held this Thursday, 11th, 2024 at 12 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. Thanks, Ganesh

1 0

Re: NumPy-Discussion Digest, Vol 214, Issue 14
by David Nicholson 10 Jul '24

10 Jul '24

Hi Jacopo, Here's a couple resources you might find helpful: https://www.pyopensci.org/python-package-guide/index.html https://learn.scientific-python.org/development/ For your question about tests, sounds like you might want to parametrize a fixture https://learn.scientific-python.org/development/guides/pytest/#tests-should… I'm sure other people on the list will have helpful advice too. Your questions might be a little outside of the scope of this list though. You could consider asking in the pyOpenSci or the Python discourse as well https://pyopensci.discourse.group/ https://discuss.python.org/ --David David Nicholson, Ph.D. https://nicholdav.info/ https://github.com/NickleDave On Wed, Jul 10, 2024 at 12:01 PM <numpy-discussion-request(a)python.org> wrote: > Send NumPy-Discussion mailing list submissions to > numpy-discussion(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > or, via email, send a message with subject or body 'help' to > numpy-discussion-request(a)python.org > > You can reach the person managing the list at > numpy-discussion-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NumPy-Discussion digest..." > > Today's Topics: > > 1. music package and testing (Jacopo Donati) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 10 Jul 2024 11:41:08 -0000 > From: "Jacopo Donati" <jacopo.donati(a)gmail.com> > Subject: [Numpy-discussion] music package and testing > To: numpy-discussion(a)python.org > Message-ID: <172061166828.21249.2941220348120809027(a)mail.python.org> > Content-Type: text/plain; charset="utf-8" > > Hi there, > > I'm writing on behalf of the team of `music`, a package that generates and > manipulates sound in a mathematically precise manner. You can find it > here: https://github.com/ttm/music > > We are fixing the library so that it conforms as much as possible to the > characteristics of the other libraries in the numpy universe. Can you give > us any suggestion regarding code organization, naming convention, etc.? > > Also, we are writing the tests and we need some help to think those for > the most complex functions. For example, we test the synth of a simple > note with this test: > https://github.com/jacopodonati/music/blob/c33e3eb80e7d4d6455f442ebb12ed16a… > But what if we have to test the synth of a note with both a change in > pitch and a vibrato applied to it? What would be the best approach for a > test? > For reference, this is the function to synth that kind of note: > https://github.com/jacopodonati/music/blob/c33e3eb80e7d4d6455f442ebb12ed16a… > > Any help will be very much appreciated! > > Regards, > > jd > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion(a)python.org > To unsubscribe send an email to numpy-discussion-leave(a)python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > > > ------------------------------ > > End of NumPy-Discussion Digest, Vol 214, Issue 14 > ************************************************* >

1 0

music package and testing
by Jacopo Donati 10 Jul '24

10 Jul '24

Hi there, I'm writing on behalf of the team of `music`, a package that generates and manipulates sound in a mathematically precise manner. You can find it here: https://github.com/ttm/music We are fixing the library so that it conforms as much as possible to the characteristics of the other libraries in the numpy universe. Can you give us any suggestion regarding code organization, naming convention, etc.? Also, we are writing the tests and we need some help to think those for the most complex functions. For example, we test the synth of a simple note with this test: https://github.com/jacopodonati/music/blob/c33e3eb80e7d4d6455f442ebb12ed16a… But what if we have to test the synth of a note with both a change in pitch and a vibrato applied to it? What would be the best approach for a test? For reference, this is the function to synth that kind of note: https://github.com/jacopodonati/music/blob/c33e3eb80e7d4d6455f442ebb12ed16a… Any help will be very much appreciated! Regards, jd

1 0

Accessing real and imaginary parts of npy_complex(nbits)
by Brendan Murphy 09 Jul '24

09 Jul '24

Hi, This is my first look at the numpy internals, so I'm trying to help update pytensor to be compatible with numpy 2.0, and we have some structs that inherit from npy_complex64 and npy_complex128, which currently use .real and .imag to access real and imaginary parts. Assuming a 64 bit system, it is easy to update the code using npy_crealf (etc) for the struct that inherits from npy_complex64, and so on. (I'll put an example of the code at the bottom of the post.) Since numpy doesn't assume a 64 bit system, I'm writing some aliases for npy_crealf etc., depending on NPY_SIZEOF_FLOAT etc. I'm wondering if there is a smarter way to do this. Also, the pytensor code redefines complex arithmetic in terms of the standard "math" definitions. For C99 complex types, this can be achieved using #pragma STDC CX_LIMITED_RANGE (in theory, but really depending on the compiler). Is there any way to ask numpy to use this directive? (Googling says this makes complex arithmetic 3-5 times faster. The C99 complex arithmetic tries to avoid overflow, and this directive is only recommended if you know that won't be an issue. I don't know if we can assume that, but this code has been this way since it was added to Theano.) Example code: struct pytensor_complex64 : public npy_complex64 { typedef pytensor_complex64 complex_type; typedef npy_float32 scalar_type; complex_type operator+(const complex_type &y) const { complex_type ret; // ret.real = this->real + y.real; // ret.imag = this->imag + npy_cimagf(y); npy_csetrealf(&ret, npy_crealf(*this) + npy_crealf(y)); npy_csetimagf(&ret, npy_cimagf(*this) + npy_cimagf(y)); return ret; } complex_type operator-() const { complex_type ret; npy_csetrealf(&ret, -npy_crealf(*this)); npy_csetimagf(&ret, -npy_cimagf(*this)); return ret; } bool operator==(const complex_type &y) const { return (npy_crealf(*this) == npy_crealf(y)) && (npy_cimagf(*this) == npy_cimagf(y)); } bool operator==(const scalar_type &y) const { return (npy_crealf(*this) == y) && (npy_crealf(*this) == 0); } complex_type operator-(const complex_type &y) const { complex_type ret; npy_csetrealf(&ret, npy_crealf(*this) - npy_crealf(y)); npy_csetimagf(&ret, npy_cimagf(*this) - npy_cimagf(y)); return ret; } complex_type operator*(const complex_type &y) const { complex_type ret; npy_csetrealf(&ret, npy_crealf(*this) * npy_crealf(y) - npy_cimagf(*this) * npy_cimagf(y)); npy_csetimagf(&ret, npy_crealf(*this) * npy_cimagf(y) + npy_cimagf(*this) * npy_crealf(y)); return ret; } complex_type operator/(const complex_type &y) const { complex_type ret; scalar_type y_norm_square = npy_crealf(y) * npy_crealf(y) + npy_cimagf(y) * npy_cimagf(y); npy_csetrealf(&ret, (npy_crealf(*this) * npy_crealf(y) + npy_cimagf(*this) * npy_cimagf(y)) / y_norm_square); npy_csetimagf(&ret, (npy_crealf(*this) * npy_crealf(y) - npy_cimagf(*this) * npy_cimagf(y)) / y_norm_square); return ret; } template <typename T> complex_type &operator=(const T &y); pytensor_complex64() {} template <typename T> pytensor_complex64(const T &y) { *this = y; } template <typename TR, typename TI> pytensor_complex64(const TR &r, const TI &i) { npy_csetrealf(this, r); npy_csetimagf(this, i); } };

1 1