Mailman 3 October 2022 - NumPy-Discussion

next NumPy community meeting
by Inessa Pawson 10 Sep '23

10 Sep '23

The next NumPy community meeting will be held this Wednesday, August 17th at 18:00 (6 pm) UTC. Join us via Zoom: https://us06web.zoom.us/j/83278611437?pwd=ekhoLzlHRjdWc0NOY2FQM0NPemdkZz09 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 meeting, visit: https://github.com/numpy/archive/blob/main/community_meetings/community-202… Cheers, Inessa Inessa Pawson Contributor Experience Lead | NumPy https://numpy.org/ Twitter: @inessapawson

1 28

reminder: put an upper bound on setuptools if you use numpy.distutils!
by Ralf Gommers 31 Aug '23

31 Aug '23

Hi all, After setuptools 65.0 was released a few days ago, all users of numpy.distutils had their builds broken. This is already fixed in setuptools 65.0.2 because the breakage was particularly bad. However, the next breakage may not be fixed anymore (and more breakages *are* expected). So this is a good time to remind you all that you should put an upper bound on the setuptools version you allow in the releases of your package - to the last version that is known to work with your package. Our official stance here is that setuptools versions >=60 are not supported - see the "deprecating numpy.distutils" thread: https://mail.python.org/archives/list/numpy-discussion@python.org/message/P…. Newer versions may work for you, depending on what features you use. They don't for NumPy and for SciPy; both projects pin to 59.X to avoid problems. For the recent issue with setuptools 65.0.0, see https://github.com/numpy/numpy/issues/22135. We have also made the warnings about this topic in our docs more explicit, see https://github.com/numpy/numpy/pull/22154. Cheers, Ralf

2 2

mixed mode arithmetic
by Neal Becker 11 Jul '23

11 Jul '23

I've been browsing the numpy source. I'm wondering about mixed-mode arithmetic on arrays. I believe the way numpy handles this is that it never does mixed arithmetic, but instead converts arrays to a common type. Arguably, that might be efficient for a mix of say, double and float. Maybe not. But for a mix of complex and a scalar type (say, CDouble * Double), it's clearly suboptimal in efficiency. So, do I understand this correctly? If so, is that something we should improve?

4 6

Representation of NumPy scalars
by Sebastian Berg 09 Jun '23

09 Jun '23

TL;DR: NumPy scalars representation is e.g. `34.3` instead of `float32(34.3)`. So the representation is missing the type information. What are your thoughts on changing that? Hi all, I am thinking about the next steps for NEP 50 (The NEP wants to fix the NumPy promotion rules, especially with respect to scalars): https://numpy.org/neps/nep-0050-scalar-promotion.html In relation to that, there was one point that Stéfan brought up previously. The NumPy scalars (representation) currently print as numbers: >>> np.float32(34.3) 34.3 >>> np.uint8(5) 5 That can already be confusing now. However, it gets more problematic if NEP 50 is introduced since the behavior between a Python `34.3` and `np.float32(34.3)` would differ more than it does now (please refer to the NEP). The change would be that we should print as: float64(34.3) (or similar?) This Email is mainly to ask for any feedback or concern on such a change. I suspect we may have to write a very brief NEP about it. If there is little concern, maybe we could move forward such a change promptly. Otherwise it could be moved forward together with NEP 50 and take effect in a "major" release [1]. Cheers, Sebastian [1] Note that for me, even a major release would hopefully not affect the majority of users or be very disruptive.

11 21

Invalid value encoutered : how to prevent numpy.where to do this?
by Eric Emsellem 18 Feb '23

18 Feb '23

Dear all, I have a code using lots of "numpy.where" to make some constrained calculations as in: data = arange(10) result = np.where(data == 0, 0., 1./data) # or data1 = arange(10) data2 = arange(10)+1.0 result = np.where(data1 > data2, np.sqrt(data1-data2), np.sqrt(data2-data2)) which then produces warnings like: /usr/bin/ipython:1: RuntimeWarning: invalid value encountered in sqrt or for the first example: /usr/bin/ipython:1: RuntimeWarning: divide by zero encountered in divide How do I avoid these messages to appear? I know that I could in principle use numpy.seterr. However, I do NOT want to remove these warnings for other potential divide/multiply/sqrt etc errors. Only when I am using a "where", to in fact avoid such warnings! Note that the warnings only happen once, but since I am going to release that code, I would like to avoid the user to get such messages which are irrelevant here (because I am testing, with the where, when NOT to divide by zero or take a sqrt of a negative number). thanks! Eric

5 4

Documentation Team meeting - Monday June 8th
by Melissa Mendonça 04 Dec '22

04 Dec '22

Hi all! A reminder that on Monday, June 8, we have another documentation team meeting at 3PM UTC**. If you wish to join on Zoom, you need to use this link https://zoom.us/j/420005230 Here's the permanent hackmd document with the meeting notes: https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg <https://www.google.com/url?q=https%3A%2F%2Fhackmd.io%2FoB_boakvRqKR-_2jRV-Q…> Hope to see you around (especially if you want to introduce yourself or discuss ideas for Google Season of Docs). ** You can click this link to get the correct time at your timezone: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Documentati… - Melissa

6 74

next NumPy triage meeting
by Inessa Pawson 27 Nov '22

27 Nov '22

The next NumPy triage meeting will be held this Wednesday, August 10th at 16:00 (4 pm) UTC. This is a meeting where we synchronously triage prioritized PRs and issues. Join us via Zoom: https://us06web.zoom.us/j/82096749952?pwd=MW9oUmtKQ1c3a2gydGk1RTdYUUVXZz09 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 Contributor Experience Lead | NumPy email: inessa(a)albuscode.org

1 8

New methods exposing UFunc dtype resolution/promotion and internals
by Sebastian Berg 16 Nov '22

16 Nov '22

Hi all, I would like to expose more of the ufunc internals in the following PR: https://github.com/numpy/numpy/pull/22422/ There are three new proposed functions. I hope the first one can be generally useful while the last two are very specific (and thus underscored), but will hopefully become useful e.g. for Numba or numexpr. ufunc.resolve_dtypes(dtypes, *, signature=None, casting=None, reduction=False) ----------------------------------------------------------- Allows you to find out what dtypes NumPy's implementation will use without executing a ufunc. For the full docs, see: https://output.circle-artifacts.com/output/job/c8f72dd5-f8fb-448c-8fd8-d618… Example from the docs: >>> int32 = np.dtype("int32") >>> float32 = np.dtype("float32") The typical ufunc call does not pass an output dtype. `np.add` has two inputs and one output, so leave the output as ``None`` (not provided): >>> np.add.resolve_dtypes((int32, float32, None)) (dtype('float64'), dtype('float64'), dtype('float64')) The loop found uses "float64" for all operands (including the output), the first input would be cast. ``resolve_dtypes`` supports "weak" handling for Python scalars by passing ``int``, ``float``, or ``complex``: >>> np.add.resolve_dtypes((float32, float, None)) (dtype('float32'), dtype('float32'), dtype('float32')) Where the Python ``float`` behaves samilar to a Python value ``0.0`` in a ufunc call. (See :ref:`NEP 50 <NEP50>` for details.) ufunc._resolve_dtypes_and_context(dtypes, *, signature=None, casting=None, reduction=False) ------------------------------------------------------------- Identical to the above, but it additionally returns a "call_info" which allows access to the actual ufunc implmentation. ufunc._get_loop(call_info, /, *, fixed_strides=None) ---------------------------------------------------- Second function that is passed the `call_info` from the previous one. Both would normally be called (this is because it is the way NumPy must do it internally and allows most flexibility). After doing both calls, `call_info` can be used from C to directly access the C implementation. Flux in the C-API are expected (for now). But for example Numba already releases new versions when NumPy releases a new version. Cheers, Sebastian

1 1

NEP 50 and integers (e.g. uint8 together -1)
by Sebastian Berg 08 Nov '22

08 Nov '22

Hi all, In NEP 50 (https://numpy.org/neps/nep-0050-scalar-promotion.html) my current proposal is that the following: np.array([1, 2], dtype="uint8") + (-1) which currently returns an "int16" array must raise an error. This is because we want to return a uint8 array but the -1 cannot be represented well by -1. The same should also happen for a value of 300 (rather than -1). My main question is not about making this an error though. The question is whether the following two cases should also error: uint8_arr = np.array([1, 2], dtype="uint8") uint8_arr[0] = -1 or: np.array([-1], dtype=np.uint8) (In practice these currently give the maximum integer with well defined integer overflow.) Note that the call `np.uint8(-1)` could be a special case here! The reason I ask is that my PR: https://github.com/numpy/numpy/pull/21875 currently introduces the new error without changing the other cases and this requires adding a full new conversion path. If we want to change that anyway (or keep things aligned), I could simplify the logic in the PR. Cheers, Sebastian

3 5

next NumPy Newcomers' Hour - 12 pm UTC
by Inessa Pawson 30 Oct '22

30 Oct '22

Our next Newcomers' Hour will be held this Thursday, November 3rd, at 12 pm UTC. (Please note the new time that is friendly for those who are in the eastern hemisphere!) Stop by to ask questions 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 Contributor Experience Lead | NumPy https://numpy.org/ GitHub: inessapawson

2 1