Mailman 3 October 2022 - NumPy-Discussion

next NumPy community meeting
by Inessa Pawson 26 Mar '23

26 Mar '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 16

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 03 Dec '22

03 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

Representation of NumPy scalars
by Sebastian Berg 30 Nov '22

30 Nov '22

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 20

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

How will Google DeepMind's AlphaTensor effect numpy
by canhtart＠gmail.com 26 Oct '22

26 Oct '22

Hello! I was curious on how AlphaTensor will effect NumPy and other similar applications considering it has found a way to perform 3x3 matrix multiplication efficiently. https://www.deepmind.com/blog/discovering-novel-algorithms-with-alphatensor. I am not even sure how NumPy does this under the hood, is it 2x2? Is anyone working on implementing this 3x3 algorithm for NumPy? Is it too early, and if so why? Are there any concerns about this algorithm? I am new to the mailing list, it is nice to be here! Long-time user of NumPy in my projects, thank you for your amazing work! Can

3 2

ANN: NumExpr 2.8.4 Release
by Robert McLeod 25 Oct '22

25 Oct '22

======================== Announcing NumExpr 2.8.4 ======================== Hi everyone, This is a maintenance and bug-fix release for NumExpr. In particular, now we have added Python 3.11 support. Project documentation is available at: http://numexpr.readthedocs.io/ Changes from 2.8.3 to 2.8.4 --------------------------- * Support for Python 3.11 has been added. * Thanks to Tobias Hangleiter for an improved accuracy complex `expm1` function. While it is 25 % slower, it is significantly more accurate for the real component over a range of values and matches NumPy outputs much more closely. * Thanks to Kirill Kouzoubov for a range of fixes to constants parsing that was resulting in duplicated constants of the same value. * Thanks to Mark Harfouche for noticing that we no longer need `numpy` version checks. `packaging` is no longer a requirement as a result. What's Numexpr? --------------- Numexpr is a fast numerical expression evaluator for NumPy. With it, expressions that operate on arrays (like "3*a+4*b") are accelerated and use less memory than doing the same calculation in Python. It has multi-threaded capabilities, as well as support for Intel's MKL (Math Kernel Library), which allows an extremely fast evaluation of transcendental functions (sin, cos, tan, exp, log...) while squeezing the last drop of performance out of your multi-core processors. Look here for a some benchmarks of numexpr using MKL: https://github.com/pydata/numexpr/wiki/NumexprMKL Its only dependency is NumPy (MKL is optional), so it works well as an easy-to-deploy, easy-to-use, computational engine for projects that don't want to adopt other solutions requiring more heavy dependencies. Where I can find Numexpr? ------------------------- The project is hosted at GitHub in: https://github.com/pydata/numexpr You can get the packages from PyPI as well (but not for RC releases): http://pypi.python.org/pypi/numexpr Documentation is hosted at: http://numexpr.readthedocs.io/en/latest/ Share your experience --------------------- Let us know of any bugs, suggestions, gripes, kudos, etc. you may have. Enjoy data! -- Robert McLeod robbmcleod(a)gmail.com robert.mcleod(a)hitachi-hightech.com

1 0

NumPy-Discussion October 2022