Mailman 3 September 2020 - NumPy-Discussion

Docs team meeting - zoom link
by Melissa Mendonça Sept. 28, 2020

Sept. 28, 2020

Hi all, Due to a change in zoom setting the link to the Documentation team meeting happening now has changed: https://zoom.us/j/91539509177?pwd=dFlqSGxBQURBOXh4alRBVWgvcTZUUT09 Cheers, Melissa

1 0

Request for comments on PEP 637 - Support for indexing with keyword arguments
by Stefano Borini Sept. 25, 2020

Sept. 25, 2020

Dear all, I would like to know your opinion on how to address a specific need of the new PEP 637: https://github.com/python/peps/blob/master/pep-0637.txt Such PEP would make a syntax like the following valid obj[2, x=23] obj[2, 4, x=23] Which would resolve to a call in the form type(obj).__getitem__(obj, 2, x=23) type(obj).__getitem__(obj, (2, 4), x=23) and similar for set and del. After discussion, we currently have one open point we are unsure how to address, that is what to pass when no positional index is passed, that is: obj[x=23] We are unsure if we should resolve this call with None or the empty tuple in the positional index: type(obj).__getitem__(obj, None, x=23) type(obj).__getitem__(obj, (), x=23) You can see a detailed discussion in the PEP at L913 https://github.com/python/peps/blob/1fb19ac3a57c9793669ea9532fb840861d4d756… One of the commenters on python-ideas reported that using None might introduce an issue in numpy, as None is used to create new axes, hence the proposal for rejection of None as a solution. However, we are unsure how strongly this would affect numpy and similar packages, as well as what developer will find more natural to receive in that case. We would like to hear your opinion on the topic. Thank you for your help. -- Kind regards, Stefano Borini

6 5

NumPy Development Meeting Today - Triage Focus
by Sebastian Berg Sept. 22, 2020

Sept. 22, 2020

Hi all, Our bi-weekly triage-focused NumPy development meeting is tomorrow (Wednesday, September 9th) at 11 am Pacific Time (18:00 UTC). Everyone is invited to join in and edit the work-in-progress meeting topics and notes: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg I encourage everyone to notify us of issues or PRs that you feel should be prioritized or simply discussed briefly. Just comment on it so we can label it, or add your PR/issue to this weeks topics for discussion. Best regards Sebastian

1 0

Sprint leaders wanted for SciPy Japan
by Juan Nunez-Iglesias Sept. 22, 2020

Sept. 22, 2020

Hi NumPythonistas, and apologies cross-posting. I am sprints chair for the upcoming SciPy Japan virtual conference [1]. It’s running Oct 30-31 (main conference) and Nov 1-2 (sprints). This is the second SciPy Japan conference and the first with sprints. The sprints officially run from 9am to 5pm Tokyo time, which corresponds to 11am-7pm Australia Eastern time and 4pm-midnight Sat-Sun USA West Coast. (I won’t bother with the Europe time. 😂) We currently have sprints confirmed for CuPy, dask-image, Apache Arrow, scikit-image, Sphinx, and napari. I’ve asked the scikit-learn team if they would like to lead a sprint, and would like to ask the same for NumPy and SciPy devs. (I won’t cross post to SciPy due to large overlap — please help me spread the word!) If anyone from the core teams is willing to lead a sprint on those dates, please let me know! Thank you, Juan. [1]: https://www.scipyjapan.scipy.org

1 0

PR 14700
by Lee Johnston Sept. 21, 2020

Sept. 21, 2020

Hi, PR 14700 <https://github.com/numpy/numpy/pull/14700> that adds datetime64 and timedelta64 support to linspace has not been worked on since December 2019. I would like this feature sooner rather than never and have implemented the support and all recommended tests in my fork. Is there interest in supporting this feature and should I submit my PR? Lee

2 1

the NumPy paper is out!
by Ralf Gommers Sept. 18, 2020

Sept. 18, 2020

Hi all, Nature published our first official paper: https://www.nature.com/articles/s41586-020-2649-2 And here is the Twitter announcement: https://twitter.com/numpy_team/status/1306268442450972674 Thanks to everyone who contributed to this milestone! A few special mentions: Chuck, for many years of tireless labour keeping our code base in good shape, and being the top committer on the NumPy project by now with more than twice the commits (says `git shortlog -sn`) as the number two committer. This is why Chuck is the first author on the paper. Travis, for creating NumPy. This is why Travis is the last author on the paper, as our "elder statesman". Jarrod and Stéfan, for spending a ton of time on making this the best possible paper we could possibly produce on NumPy. Cheers, Ralf

9 8

NumPy Community Meeting Wednesday
by Sebastian Berg Sept. 15, 2020

Sept. 15, 2020

Hi all, There will be a NumPy Community meeting Wednesday September 16th at 1pm Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in and edit the work-in-progress meeting topics and notes at: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian

1 0

Numpy wheels with Python 3.9 support.
by Charles R Harris Sept. 10, 2020

Sept. 10, 2020

Hi All, There are numpy pre-wheels for Python 3.9 available on the x86_64, i686, and aarch64 platforms. They use manylinux2010 and manylinux2014, so you need a recent pip to get them. Chuck

1 0

NumPy 1.19.2 released
by Charles R Harris Sept. 10, 2020

Sept. 10, 2020

Hi All, On behalf of the NumPy team I am pleased to announce that NumPy 1.19.2 has been released. This release fixes several bugs, prepares for the upcoming Cython 3.x release. and pins setuptools to keep distutils working while upstream modifications are ongoing. The aarch64 wheels are built with the latest manylinux2014 release that fixes the problem of differing page sizes used by different Linux distros. There is a known problem with Windows 10 version=2004 and OpenBLAS svd that we are trying to debug. If you are running that Windows version you should use a NumPy version that links to the MKL library, earlier Windows versions are fine. This release supports Python 3.6-3.8. Downstream developers should use Cython >= 0.29.21 when building for Python 3.9 and Cython >= 0.29.16 when building for Python 3.8. OpenBLAS >= 3.7 is needed to avoid wrong results on the Skylake architecture. The NumPy Wheels for this release can be downloaded from PyPI <https://pypi.org/project/numpy/1.19.2/>, source archives, release notes, and wheel hashes are available from Github <https://github.com/numpy/numpy/releases/tag/v1.19.2>. Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. *Contributors* A total of 8 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Charles Harris - Matti Picus - Pauli Virtanen - Philippe Ombredanne + - Sebastian Berg - Stefan Behnel + - Stephan Loyd + - Zac Hatfield-Dodds *Pull requests merged* A total of 9 pull requests were merged for this release. - #16959: TST: Change aarch64 to arm64 in travis.yml. - #16998: MAINT: Configure hypothesis in ``np.test()`` for determinism,... - #17000: BLD: pin setuptools < 49.2.0 - #17015: ENH: Add NumPy declarations to be used by Cython 3.0+ - #17125: BUG: Remove non-threadsafe sigint handling from fft calculation - #17243: BUG: core: fix ilp64 blas dot/vdot/... for strides > int32 max - #17244: DOC: Use SPDX license expressions with correct license - #17245: DOC: Fix the link to the quick-start in the old API functions - #17272: BUG: fix pickling of arrays larger than 2GiB Cheers, Charles Harris

1 0

number datetime64 dtypes
by Dr. Mark Alexander Mikofski PhD Sept. 10, 2020

Sept. 10, 2020

Hi, Thank you for your time. A colleague asked me about creating a range of numpy datetime64 at 15-day increments. This works: np.arange(np.datetime64('2008-04-01'), np.datetime64('2020-09-01'), np.timedelta64(15, 'D')) but then they also showed me this, which leads to some very strange responses: np.arange(np.datetime64('2008-04-01'), np.datetime64('2020-09-01'), dtype="datetime64[15D]") Out[50]: array(['2008-03-27', '2008-04-11', '2008-04-26', '2008-05-11', '2008-05-26', '2008-06-10', '2008-06-25', '2008-07-10', ... '2020-05-23', '2020-06-07', '2020-06-22', '2020-07-07', '2020-07-22', '2020-08-06'], dtype='datetime64[15D]') See how the 1st day is March 27th? I couldn't find a reference to this dtype ( "datetime64[15D]" ) in the numpy docs, but I think it's a common pattern in Pandas, that is using a number to get an increment of the frequency, for example "5T" is 5-minutes, etc. There is a reference to using arange with dtype on the datetimes & timedelta doc page () but the datetime is 1-day or "datetime64[D]" Is this the intended outcome? Or is it a side effect? I wonder if others have tried to adapt Pandas patterns to Numpy datetimes, and if it's an issue for anyone else. I've advised my colleague not to use Numpy datetimes like this, assuming based on the docs that Pandas-style offsets do not translate into Numpy style datetimes. thanks! -- Mark Mikofski, PhD (2005) *Fiat Lux*

2 2