Mailman 3 June 2022 - NumPy-Discussion

NumPy 1.23.0rc3 released
by Charles R Harris 11 Jun '22

11 Jun '22

Hi All, On behalf of the NumPy team, I'm pleased to announce the release of NumPy 1.23.0rc2. The NumPy 1.23.0 release continues the ongoing work to improve the handling and promotion of dtypes, increase the execution speed, clarify the documentation, and expire old deprecations. The highlights are: - Implementation of ``loadtxt`` in C, greatly improving its performance. - Exposing DLPack at the Python level for easy data exchange. - Changes to the promotion and comparisons of structured dtypes. - Improvements to f2py. The Python versions supported in this release are 3.8-3.10, 3.11 will be supported when it comes out. Note that 32 bit wheels are only provided for Windows, all other wheels are 64 bits on account of Ubuntu, Fedora, and other Linux distributions dropping 32 bit support. All 64 bit wheels are also linked with 64 bit OpenBLAS. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.23.0rc3/>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v1.23.0rc3>. *Contributors* A total of 151 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - @DWesl - @GalaxySnail + - @code-review-doctor + - @h-vetinari - Aaron Meurer - Alexander Shadchin - Alexandre de Siqueira - Allan Haldane - Amrit Krishnan - Andrei Batomunkuev - Andrew J. Hesford + - Andrew Murray + - Andrey Andreyevich Bienkowski + - André Elimelek de Weber + - Andy Wharton + - Arryan Singh - Arushi Sharma - Bas van Beek - Bharat Raghunathan - Bhavuk Kalra + - Brigitta Sipőcz - Brénainn Woodsend + - Burlen Loring + - Caio Agiani + - Charles Harris - Chiara Marmo - Cornelius Roemer + - Dahyun Kim + - Damien Caliste - David Prosin + - Denis Laxalde - Developer-Ecosystem-Engineering - Devin Shanahan + - Diego Wang + - Dimitri Papadopoulos Orfanos - Ding Liu + - Diwakar Gupta + - Don Kirkby + - Emma Simon + - Eric Wieser - Evan Miller + - Evgeni Burovski - Evgeny Posenitskiy + - Ewout ter Hoeven + - Felix Divo - Francesco Andreuzzi + - Ganesh Kathiresan - Gaëtan de Menten - Geoffrey Gunter + - Hans Meine - Harsh Mishra + - Henry Schreiner - Hood Chatham + - I-Shen Leong - Ilhan Polat - Inessa Pawson - Isuru Fernando - Ivan Gonzalez + - Ivan Meleshko + - Ivan Yashchuk + - Janus Heide + - Jarrod Millman - Jason Thai + - Jeremy Volkman + - Jesús Carrete Montaña + - Jhong-Ken Chen (陳仲肯) + - John Kirkham - John-Mark Gurney + - Jonathan Deng + - Joseph Fox-Rabinovitz - Jouke Witteveen + - Junyan Ou + - Jérôme Richard + - Kassian Sun + - Kazuki Sakamoto + - Kenichi Maehashi - Kevin Sheppard - Kilian Lieret + - Kushal Beniwal + - Leo Singer - Logan Thomas + - Lorenzo Mammana + - Margret Pax - Mariusz Felisiak + - Markus Mohrhard + - Mars Lee - Marten van Kerkwijk - Masamichi Hosoda + - Matthew Barber - Matthew Brett - Matthias Bussonnier - Matthieu Darbois - Matti Picus - Melissa Weber Mendonça - Michael Burkhart + - Morteza Mirzai + - Motahhar Mokf + - Muataz Attaia + - Muhammad Motawe + - Mukulika Pahari - Márton Gunyhó + - Namami Shanker + - Nihaal Sangha + - Niyas Sait - Omid Rajaei + - Oscar Gustafsson + - Ovee Jawdekar + - P. L. Lim + - Pamphile Roy + - Pantelis Antonoudiou + - Pearu Peterson - Peter Andreas Entschev - Peter Hawkins - Pierre de Buyl - Pieter Eendebak + - Pradipta Ghosh + - Rafael Cardoso Fernandes Sousa + - Raghuveer Devulapalli - Ralf Gommers - Raphael Kruse - Raúl Montón Pinillos - Robert Kern - Rohit Goswami - Ross Barnowski - Ruben Garcia + - Sadie Louise Bartholomew + - Saswat Das + - Sayed Adel - Sebastian Berg - Serge Guelton - Simon Surland Andersen + - Siyabend Ürün + - Somasree Majumder + - Soumya + - Stefan van der Walt - Stefano Miccoli + - Stephan Hoyer - Stephen Worsley + - Tania Allard - Thomas Duvernay + - Thomas Green + - Thomas J. Fan - Thomas Li + - Tim Hoffmann - Ting Sun + - Tirth Patel - Toshiki Kataoka - Tyler Reddy - Warren Weckesser - Yang Hau - Yoon, Jee Seok + Cheers, Charles Harris

1 0

numpy-stl
by Frank Underdown 10 Jun '22

10 Jun '22

Greetings: I am reaching out to see if anyone is familiar with using numpy-stl. I have some FDTD code, and I want to find a practical way to input a device, drawn in cad, into my fdtd engine. Thank you in advance for help. Cheers! Frank Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

1 0

Njumpy-stl
by frank.underdown＠quaise.energy 09 Jun '22

09 Jun '22

Hello, I recently discovered numpy-stl. I am looking for documentations and tutorials to learn how to use this library. Also, if you know of any books where this library is discussed, I would appreciate you making a recommendation. Thank you in advance for your help. Cheers! Frank

2 1

Importing Numpy when using libpython
by jensaxel＠soegaard.net 09 Jun '22

09 Jun '22

Hi All, Hope this is the right forum. I am working on using Numpy from the programming language Racket. My plan of attack is to use Python via `libpython`. That is, from Racket I use `ffilib` to load `libpython` and from there I use the C API to control Python. Here is what works at the moment: 1. From Racket I can load `libpython` via `ffilib`. 2. It is possible to initialize a Python process and run Python programs in it. 3. It is possible to import modules written in Python. What doesn't work is importing `numpy`. The error I get when I run `import numpy` is: ImportError: dlopen(/usr/local/lib/python3.10/site-packages/numpy/core/_multiarray_umath.cpython-310-darwin.so, 0x0002): symbol not found in flat namespace '_PyBaseObject_Type' Right now, I am trying to figure out where things went wrong. First I checked that Numpy works in the terminal (it did): soegaard@mbp2 ~ % /usr/local/Cellar/python(a)3.10/3.10.4/Frameworks/Python.framework/Versions/3.10/bin/python3.10 Python 3.10.4 (main, Apr 26 2022, 19:42:59) [Clang 13.1.6 (clang-1316.0.21.2)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import numpy >>> numpy.array([[1, 2, 3], [4, 5, 6]], numpy.int32) array([[1, 2, 3], [4, 5, 6]], dtype=int32) I notice that Python is built with `clang`. Is this okay? I ask, partly because there is a cryptic note on GCC in the Numpy installation guide and partly because I have seen posts where static link problems where due to mixing gcc and clang binaries. I installed `python3.10` on my Intel mac using HomeBrew. Then I installed `numpy` using `pip`. Since XCode terminal commands are installed the system `gcc` actually invokes `clang`. In order to check that the paths are as expected, I made the embedded Python instance print out the paths before issuing the command `import numpy`: (ProgramName /usr/local/Cellar/python(a)3.10/3.10.4/Frameworks/Python.framework/Versions/3.10/bin/python3.10) (Prefix /usr/local/Cellar/python(a)3.10/3.10.4/Frameworks/Python.framework/Versions/3.10) (ExecPrefix /usr/local/Cellar/python(a)3.10/3.10.4/Frameworks/Python.framework/Versions/3.10) (ProgramFullPath /usr/local/Cellar/python(a)3.10/3.10.4/Frameworks/Python.framework/Versions/3.10/bin/python3.10) (Path /usr/local/Cellar/python@3.10/3.10.4/Frameworks/Python.framework/Versions/3.10/lib/python310.zip:/usr/local/Cellar/python@3.10/3.10.4/Frameworks/Python.framework/Versions/3.10/lib/python3.10:/usr/local/Cellar/python@3.10/3.10.4/Frameworks/Python.framework/Versions/3.10/lib/python3.10/lib-dynload) (PythonHome #f) The full error message was: Traceback (most recent call last): File "/usr/local/lib/python3.10/site-packages/numpy/core/__init__.py", line 23, in <module> from . import multiarray File "/usr/local/lib/python3.10/site-packages/numpy/core/multiarray.py", line 10, in <module> from . import overrides File "/usr/local/lib/python3.10/site-packages/numpy/core/overrides.py", line 6, in <module> from numpy.core._multiarray_umath import ( ImportError: dlopen(/usr/local/lib/python3.10/site-packages/numpy/core/_multiarray_umath.cpython-310-darwin.so, 0x0002): symbol not found in flat namespace '_PyBaseObject_Type' Any help is appreciated. -- Jens Axel Søgaard

3 3

NumPy-Numba interaction
by Ralf Gommers 08 Jun '22

08 Jun '22

Hi all, In a few places I noticed recently that it has become harder for Numba to keep up with NumPy releases. Numba is very popular, so that's not an ideal situation for end users or for packages which have both NumPy and Numba as dependencies. If we can do things to make the life of the Numba team easier, we should consider doing them I'd think. As far as I can remember, we have never had a broad discussion on this. Numba devs have posted issues about individual APIs or behavior, but they're not labelled or prioritized in any way. Rather they just go in our 1000+ open issues backlog. And then other libraries/projects get to rediscover the same issues sometimes - because if it's an issue for Numba, it's likely to be an issue elsewhere too. Here's an example: https://github.com/numpy/numpy/issues/13718. Independently discovered by PyTorch, Warren's ufunclab, and in the Data APIs discussions at least (I suspect JAX/CuPy too, but they didn't link to that issue). Stuart Archibald wrote up a very nice overview of the main pain points Numba devs are seeing at https://github.com/numba/numba/issues/8008. It would be great if others could read those, and discuss the content in that issue in case things are unclear. And then we could circle back and perhaps add a dedicated topic like "Numba compatibility" on our roadmap under https://numpy.org/neps/roadmap.html#interoperability. Not everything will be fixable, but some things should be. And if we'd have to make a few minor technically backwards-incompatible changes (e.g. returning tuple-of-arrays rather than list-of-arrays from some functions), that'd be worth considering. Cheers, Ralf

1 0

next NumPy Newcomers Hour
by Inessa Pawson 05 Jun '22

05 Jun '22

The next NumPy Newcomers Hour will be held this Thursday, June 2nd at 4 pm UTC. Sebastian Berg, one of the NumPy core developers, will talk about deprecations in NumPy. Join us via Zoom: https://us02web.zoom.us/j/87192457898 Cheers, Inessa Inessa Pawson Contributor Experience Lead | NumPy https://numpy.org/ Twitter: @inessapawson

1 1

Exponential function, sine function and cos function
by Brinley Patterson 04 Jun '22

04 Jun '22

Hi, By using the exponential equation: exp(x) = (sum{k=0}{n} 1/ k! ) ^ x the speed and accuracy of calculating exponent greatly increases. Plus it makes it easier to use with imaginary numbers. I have the python function code if you are interested to learn more about this. This equation can then be used to calculate sine and cos more efficiently using the exponent form of them both. Kind regards, Brinley MSc Machine Learning BSc Mathematical Physics

2 1

API Addition: Polynomial classes now have a "symbol" denoting the variable
by Sebastian Berg 01 Jun '22

01 Jun '22

Hi all, just another small API announcement, that I merged: https://github.com/numpy/numpy/pull/16154 which adds `symbol="x"` to the polynomial classes. Ross' more detailed explanation is copied below. Cheers, Sebastian New attribute ``symbol`` added to polynomial classes ---------------------------------------------------- The polynomial classes in the ``numpy.polynomial`` package have a new ``symbol`` attribute which is used to represent the indeterminate of the polynomial. This can be used to change the value of the variable when printing:: >>> P_y = np.polynomial.Polynomial([1, 0, -1], symbol="y") >>> print(P_y) 1.0 + 0.0·y¹ - 1.0·y² Note that the polynomial classes only support 1D polynomials, so operations that involve polynomials with different symbols are disallowed when the result would be multivariate:: >>> P = np.polynomial.Polynomial([1, -1]) # default symbol is "x" >>> P_z = np.polynomial.Polynomial([1, 1], symbol="z") >>> P * P_z Traceback (most recent call last) ... ValueError: Polynomial symbols differ The symbol can be any valid Python identifier. The default is ``symbol=x``, consistent with existing behavior.

1 0

Small API addition: unique now has `equal_nan=False` keyword argument
by Sebastian Berg 01 Jun '22

01 Jun '22

Hi all, this has been discussed before, so mainly a brief announcement that we merged a PR to add the `equal_nan` kwarg to `np.unique`. If set to False, multiple `NaN`s will be reported multiple times (which was the behavior prior to NumPy 1.21). The keyword argument name was chosen to match that of `np.array_equal` and the testing functions that. Since the actual release is a bit off and this has no backwards compatibility concerns, there is a chance that this may be backported into NumPy 1.23 (This is at Chucks discretion as the release manager). Cheers, Sebastian

1 0

overhead of numpy scalars
by Pieter Eendebak 01 Jun '22

01 Jun '22

Hi everyone, Operations such as np.sqrt or np.cos on numpy scalars are much slower than operations on an array of size 1 (benchmark below). The reason seems to be that a numpy scalar (e.g. np.float64(1.1)) is converted internally to an array, an array is created for the result of the operation and the result is converted back to a scalar (so three object constructions in total). Operating directly on an array creates an array for the result, which is returned (so one object construction in total). Has anyone looked into improving this performance before or has ideas how to tackle this? With kind regards, Pieter Eendebak Example benchmark: import numpy as np from numpy import sqrt import time v=np.array([1.1]) t0=time.perf_counter() x=np.float64(v) for kk in range(1_000_000): w1=sqrt(x) dt1=time.perf_counter()-t0 print(dt1) t0=time.perf_counter() x=v for kk in range(1_000_000): w2=sqrt(x) dt2=time.perf_counter()-t0 print(dt2) print(f'factor {dt1/dt2:.2f} faster') assert(float(w1)==float(w2)) Results in 1.0878291579974757 0.5115369699997245 factor 2.13 faster

2 2