Mailman 3 June 2020 - NumPy-Discussion

mixed mode arithmetic
by Neal Becker July 11, 2023

July 11, 2023

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

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

Feb. 18, 2023

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 … [View More]

5 4

Documentation Team meeting - Monday June 8th
by Melissa Mendonça Dec. 4, 2022

Dec. 4, 2022

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 … [View More]

6 74

[Feature Request] Add alias of np.concatenate as np.concat
by Iordanis Fostiropoulos May 11, 2022

May 11, 2022

In regard to Feature Request: https://github.com/numpy/numpy/issues/16469 It was suggested to sent to the mailing list. I think I can make a strong point as to why the support for this naming convention would make sense. Such as it would follow other frameworks that often work alongside numpy such as tensorflow. For backward compatibility, it can simply be an alias to np.concatenate I often convert portions of code from tf to np, it is as simple as changing the base module from tf to np. e.g. … [View More]

7 6

Re: [Numpy-discussion] example reading binary Fortran file
by Neil Martinsen-Burrell July 22, 2021

July 22, 2021

David Froger <david.froger.info <at> gmail.com> writes: > Hy,My question is about reading Fortran binary file (oh no this question > again...) I've posted this before, but I finally got it cleaned up for the Cookbook. For this purpose I use a subclass of file that has methods for reading unformatted Fortran data. See http://www.scipy.org/Cookbook/FortranIO/FortranFile. I'd gladly see this in numpy or scipy somewhere, but I'm not sure where it belongs. > program … [View More]makeArray > implicit none > integer,parameter:: nx=10,ny=20 > real(4),dimension(nx,ny):: ux,uy,p > integer :: i,j > open(11,file='uxuyp.bin',form='unformatted') > do i = 1,nx > do j = 1,ny > ux(i,j) = real(i*j) > uy(i,j) = real(i)/real(j) > p (i,j) = real(i) + real(j) > enddo > enddo > write(11) ux,uy > write(11) p > close(11) > end program makeArray When I run the above program compiled with gfortran on my Intel Mac, I can read it back with:: >>> import numpy as np >>> from fortranfile import FortranFile >>> f=FortranFile('uxuyp.bin', endian='<') >>> uxuy = f.readReals(prec='f') # 'f' for default reals >>> len(uxuy) 400 >>> ux = np.array(uxuy[:200]).reshape((20,10)).T >>> uy = np.array(uxuy[200:]).reshape((20,10)).T >>> p = f.readReals('f').reshape((20,10)).T >>> ux array([[ 1., 2., 3., 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20.], [ 2., 4., 6., 8., 10., 12., 14., 16., 18., 20., 22., 24., 26., 28., 30., 32., 34., 36., 38., 40.], [ 3., 6., 9., 12., 15., 18., 21., 24., 27., 30., 33., 36., 39., 42., 45., 48., 51., 54., 57., 60.], [ 4., 8., 12., 16., 20., 24., 28., 32., 36., 40., 44., 48., 52., 56., 60., 64., 68., 72., 76., 80.], [ 5., 10., 15., 20., 25., 30., 35., 40., 45., 50., 55., 60., 65., 70., 75., 80., 85., 90., 95., 100.], [ 6., 12., 18., 24., 30., 36., 42., 48., 54., 60., 66., 72., 78., 84., 90., 96., 102., 108., 114., 120.], [ 7.,Proxy-Connection: keep-alive Cache-Control: max-age=0 14., 21., 28., 35., 42., 49., 56., 63., 70., 77., 84., 91., 98., 105., 112., 119., 126., 133., 140.], [ 8., 16., 24., 32., 40., 48., 56., 64., 72., 80., 88., 96., 104., 112., 120., 128., 136., 144., 152., 160.], [ 9., 18., 27., 36., 45., 54., 63., 72., 81., 90., 99., 108., 117., 126., 135., 144., 153., 162., 171., 180.], [ 10., 20., 30., 40., 50., 60., 70., 80., 90., 100., 110., 120., 130., 140., 150., 160., 170., 180., 190., 200.]]) >>> uy array([[ 1. , 0.5 , 0.33333334, 0.25 , 0.2 , 0.16666667, 0.14285715, 0.125 , 0.11111111, 0.1 , 0.09090909, 0.08333334, 0.07692308, 0.07142857, 0.06666667, 0.0625 , 0.05882353, 0.05555556, 0.05263158, 0.05 ], [ 2. , 1. , 0.66666669, 0.5 , 0.40000001, 0.33333334, 0.2857143 , 0.25 , 0.22222222, 0.2 , 0.18181819, 0.16666667, 0.15384616, 0.14285715, 0.13333334, 0.125 , 0.11764706, 0.11111111, 0.10526316, 0.1 ], [ 3. , 1.5 , 1. , 0.75 , 0.60000002, 0.5 , 0.42857143, 0.375 , 0.33333334, 0.30000001, 0.27272728, 0.25 , 0.23076923, 0.21428572, 0.2 , 0.1875 , 0.17647059, 0.16666667, 0.15789473, 0.15000001], [ 4. , 2. , 1.33333337, 1. , 0.80000001, 0.66666669, 0.5714286 , 0.5 , 0.44444445, 0.40000001, 0.36363637, 0.33333334, 0.30769232, 0.2857143 , 0.26666668, 0.25 , 0.23529412, 0.22222222, 0.21052632, 0.2 ], [ 5. , 2.5 , 1.66666663, 1.25 , 1. , 0.83333331, 0.71428573, 0.625 , 0.55555558, 0.5 , 0.45454547, 0.41666666, 0.38461539, 0.35714287, 0.33333334, 0.3125 , 0.29411766, 0.27777779, 0.2631579 , 0.25 ], [ 6. , 3. , 2. , 1.5 , 1.20000005, 1. , 0.85714287, 0.75 , 0.66666669, 0.60000002, 0.54545456, 0.5 , 0.46153846, 0.42857143, 0.40000001, 0.375 , 0.35294119, 0.33333334, 0.31578946, 0.30000001], [ 7. , 3.5 , 2.33333325, 1.75 , 1.39999998, 1.16666663, 1. , 0.875 , 0.77777779, 0.69999999, 0.63636363, 0.58333331, 0.53846157, 0.5 , 0.46666667, 0.4375 , 0.41176471, 0.3888889 , 0.36842105, 0.34999999], [ 8. , 4. , 2.66666675, 2. , 1.60000002, 1.33333337, 1.14285719, 1. , 0.8888889 , 0.80000001, 0.72727275, 0.66666669, 0.61538464, 0.5714286 , 0.53333336, 0.5 , 0.47058824, 0.44444445, 0.42105263, 0.40000001], [ 9. , 4.5 , 3. , 2.25 , 1.79999995, 1.5 , 1.28571427, 1.125 , 1. , 0.89999998, 0.81818181, 0.75 , 0.69230771, 0.64285713, 0.60000002, 0.5625 , 0.52941179, 0.5 , 0.47368422, 0.44999999], [ 10. , 5. , 3.33333325, 2.5 , 2. , 1.66666663, 1.42857146, 1.25 , 1.11111116, 1. , 0.90909094, 0.83333331, 0.76923078, 0.71428573, 0.66666669, 0.625 , 0.58823532, 0.55555558, 0.52631581, 0.5 ]]) >>> p array([[ 2., 3., 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21.], [ 3., 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22.], [ 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23.], [ 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24.], [ 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25.], [ 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26.], [ 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27.], [ 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27., 28.], [ 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27., 28., 29.], [ 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27., 28., 29., 30.]]) Note that you have to provide the shape information for ux and uy because fortran writes them together as a stream of 400 numbers. -Neil [View Less]

10 10

Numpy FFT normalization options issue (addition of new option)
by cvav July 12, 2020

July 12, 2020

Issue #16126: https://github.com/numpy/numpy/issues/16126 PR #16476: https://github.com/numpy/numpy/pull/16476 numpy.fft docs (v1.18): https://numpy.org/doc/1.18/reference/routines.fft.html Hello all, I was advised to write on the numpy mailing list, after this week's community meeting led to some general discussions on the normalization schemes used in the FFT functions. My post has to do with issue #16126, which asks for the addition of a new option for the "norm" argument for the FFT … [View More]

10 14

reseed random generator (1.19)
by Neal Becker July 4, 2020

July 4, 2020

Consider the following: from numpy.random import default_rng rs = default_rng() Now how do I re-seed the generator? I thought perhaps rs.bit_generator.seed(), but there is no such attribute. Thanks, Neal -- *Those who don't understand recursion are doomed to repeat it*

5 16

Improving Complex Comparison/Ordering in Numpy
by Rakesh Vasudevan July 2, 2020

July 2, 2020

Hi all, As a follow up to gh-15981 <https://github.com/numpy/numpy/issues/15981>, I would like to propose a change to bring complex dtype(s) comparison operators and related functions, in line with respective cpython implementations. The current state of complex dtype comparisons/ordering as summarised in the issue is as follows: # In python >> cnum = 1 + 2j >> cnum_two = 1 + 3j # Doing a comparision yields >> cnum > cnum_two TypeError: '>' not supported … [View More]between instances of 'complex' and 'complex' # Doing the same in Numpy scalar comparision >> np.array(cnum) > np.array(cnum_two) # Yields False *NOTE*: only >, <, >= , <= do not work on complex numbers in python , equality (==) does work similarly sorting uses comparison operators behind to sort complex values. Again this behavior diverges from the default python behavior. # In native python >> clist = [cnum, cnum_2] >> sorted(clist, key=lambda c: (c.real, c.imag)) [(1+2j), (1+3j)] # In numpy >> np.sort(clist) #Uses the default comparision order # Yields same result # To get a cpython like sorting call we can do the following in numpy np.take_along_axis(clist, np.lexsort((clist.real, clist.imag), 0), 0) This proposal aims to bring parity between default python handling of complex numbers and handling complex types in numpy This is a two-step process 1. Sort complex numbers in a pythonic way , accepting key arguments, and deprecate usage of sort() on complex numbers without key argument 1. Possibly extend this to max(), min(), if it makes sense to do so. 2. Since sort() is being updated for complex numbers, searchsorted() is also a good candidate for implementing this change. 2. Once this is done, we can deprecate the usage of comparison operators (>, <, >= , <=) on complex dtypes *Handling sort() for complex numbers* There are two approaches we can take for this 1. update sort() method, to have a ‘key’ kwarg. When key value is passed, use lexsort to get indices and continue sorting of it. We could support lambda function keys like python, but that is likely to be very slow. 2. Create a new wrapper function sort_by() (placeholder name, Requesting name suggestions/feedback)That essentially acts like a syntactic sugar for 1. np.take_along_axis(clist, np.lexsort((clist.real, clist.imag), 0), 0) 1. Improve the existing sort_complex() method with the new key search functionality (Though the change will only reflect for complex dtypes). We could choose either method, both have pros and cons , approach 1 makes the sort function signature, closer to its python counterpart, while using approach 2 provides a better distinction between the two approaches for sorting. The performance on approach 1 function would vary, due to the key being an optional argument. Would love the community’s thoughts on this. *Handling min() and max() for complex numbers* Since min and max are essentially a set of comparisons, in python they are not allowed on complex numbers >> clist = [cnum, cnum_2] >>> min(clist) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: '<' not supported between instances of 'complex' and 'complex' # But using keys argument again works min(clist, key=lambda c: (c.real, c.imag)) We could use a similar key kwarg for min() and max() in python, but question remains how we handle the keys, in this use case , naive way would be to sort() on keys and take last or first element, which is likely going to be slow. Requesting suggestions on approaching this. *Comments on isclose()* Both python and numpy use the absolute value/magnitude for comparing if two values are close enough. Hence I do not see this change affecting this function. Requesting feedback and suggestions on the above. Thank you, Rakesh [View Less]

4 6

NumPy Development Meeting Tomorrow - Triage Focus
by Sebastian Berg July 1, 2020

July 1, 2020

Hi all, Our bi-weekly triage-focused NumPy development meeting is tomorrow (Wednesday, July 1st) 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

ANN: SfePy 2020.2
by Robert Cimrman June 30, 2020

June 30, 2020

I am pleased to announce the release of SfePy 2020.2. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by finite element methods. It is distributed under the new BSD license. Home page: https://sfepy.org Mailing list: https://mail.python.org/mm3/mailman3/lists/sfepy.python.org/ Git (source) repository, issue tracker: https://github.com/sfepy/sfepy Highlights of this release -------------------------… [View More]

1 0

Re: [Numpy-discussion] Google Summer of Docs Faq and Tutorial Proposed Structure .
by Saber Tooth June 25, 2020

June 25, 2020

Hello Melissa , I have altered and built upon my previous proposal , if you could take a few minutes to read it it would be great . I have tried to explain the sections we had discussed in the meeting on 22 June . Moreover as per your feedback , I would like to start contributing to the docs and start building the docs in my Linux environment . Best , Mrinal Tyagi On Wed, 24 Jun 2020 at 2:36 PM, Saber Tooth <sabertooth2022(a)gmail.com> wrote: > Hello Melissa and all the Mentors , … [View More]

1 0

About the apply in GSoD
by Christian Nakata June 25, 2020

June 25, 2020

Hello members of Numpy Community My name is Christian Takashi Nakata Currently, I'm working with computer vision in my master's degree and your project ideas for the GSoD caught my attention. I've always wanted to work on open source projects, especially in libraries that I usually use. I would like to begin contributing to the Numpy documentation. However, I never worked with open source projects and I wanted to know where I should begin to write a GSoD project proposal. I would like to … [View More]

2 2

new NumPy logo design - cast your vote!
by Inessa Pawson June 25, 2020

June 25, 2020

One of the most discussed and commented issues in the recent history of NumPy is about to be closed. Don’t forget to cast your vote via reaction on the new NumPy logo design by this Friday, June 26th. Here are the three candidates: https://github.com/numpy/numpy.org/issues/326 https://github.com/numpy/numpy.org/issues/327 https://github.com/numpy/numpy.org/issues/328 For further info please refer to github.com/numpy/numpy.org/issues/37 -- Every good wish, *Inessa Pawson* Albus Code inessa(a)albuscode.org

2 1

ANN: randomgen 1.19.0 release
by Kevin Sheppard June 24, 2020

June 24, 2020

randomgen 1.19.0 has been released with bug fixes and new features. *New Features* - A helper class that lets users define custom bit generators in Python (slow) or numba (fast). This simplifies experimenting with alternative configurations. The UserBitGenerator can be used with numpy.random.Generator to produce variants from a wide range of distributions. https://bashtage.github.io/randomgen/custom-bit-generators.html - New bit generators: - PCG64DXSM - The cheap-… [View More]

1 0

NumPy Community Meeting Wednesday
by Sebastian Berg June 24, 2020

June 24, 2020

Hi all, There will be a NumPy Community meeting Wednesday May 27th 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

Guidelines for NumPy tutorials
by Ben Nathanson June 22, 2020

June 22, 2020

I've submitted PR #11 in the new numpy-tutorials repo (https://github.com/numpy/numpy-tutorials/pull/11) to provide a checklist and standard style for writing tutorials. Added tutorial content is an objective of NEP 44. We're expecting part of the content to come from new contributors (for instance, through Ryan Cooper's generous offer to get his students involved, https://mail.python.org/pipermail/numpy-discussion/2020-May/080715.htmll). The PR will provide a guide for all contributors to … [View More]

2 1

ANN: SciPy 1.5.0
by Tyler Reddy June 22, 2020

June 22, 2020

Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.5.0. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.5.0 One of a few ways to install this release with pip: pip install scipy==1.5.0 ========================== SciPy 1.5.0 Release Notes ========================== SciPy 1.5.0 is the culmination of 6 months of hard work. It contains many new features, numerous bug-… [View More]

2 1

NumPy 1.19.0 released
by Charles R Harris June 20, 2020

June 20, 2020

Hi All, On behalf of the NumPy team I am pleased to announce that NumPy 1.19.0 has been released. This NumPy release supports Python 3.6-3.8 and is marked by the removal of much technical debt: support for Python 2 has been removed, many deprecations have been expired, and documentation has been improved. The polishing of the random module continues apace with bug fixes and better usability from Cython. Perhaps the most interesting thing for users will be the availability of wheels for aarch64 … [View More]and PyPY. Downstream developers should use Cython >= 0.29.16 for Python 3.8 support and OpenBLAS >= 3.7 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.0/>, source archives, release notes, and wheel hashes are available from Github <https://github.com/numpy/numpy/releases/tag/v1.19.0>. Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. *Contributors* A total of 126 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Alex Henrie - Alexandre de Siqueira + - Andras Deak - Andrea Sangalli + - Andreas Klöckner + - Andrei Shirobokov + - Anirudh Subramanian + - Anne Bonner - Anton Ritter-Gogerly + - Benjamin Trendelkamp-Schroer + - Bharat Raghunathan - Brandt Bucher + - Brian Wignall - Bui Duc Minh + - Changqing Li + - Charles Harris - Chris Barker - Chris Holland + - Christian Kastner + - Chunlin + - Chunlin Fang + - Damien Caliste + - Dan Allan - Daniel Hrisca - Daniel Povey + - Dustan Levenstein + - Emmanuelle Gouillart + - Eric Larson - Eric M. Bray - Eric Mariasis + - Eric Wieser - Erik Welch + - Fabio Zeiser + - Gabriel Gerlero + - Ganesh Kathiresan + - Gengxin Xie + - Guilherme Leobas - Guillaume Peillex + - Hameer Abbasi - Hao Jin + - Harshal Prakash Patankar + - Heshy Roskes + - Himanshu Garg + - Huon Wilson + - John Han + - John Kirkham - Jon Dufresne - Jon Morris + - Josh Wilson - Justus Magin - Kai Striega - Kerem Hallaç + - Kevin Sheppard - Kirill Zinovjev + - Marcin Podhajski + - Mark Harfouche - Marten van Kerkwijk - Martin Michlmayr + - Masashi Kishimoto + - Mathieu Lamarre - Matt Hancock + - MatteoRaso + - Matthew Harrigan - Matthias Bussonnier - Matti Picus - Max Balandat + - Maximilian Konrad + - Maxwell Aladago - Maxwell Bileschi + - Melissa Weber Mendonça + - Michael Felt - Michael Hirsch + - Mike Taves - Nico Schlömer - Pan Jan + - Paul Rougieux + - Pauli Virtanen - Peter Andreas Entschev - Petre-Flaviu Gostin + - Pierre de Buyl - Piotr Gaiński + - Przemyslaw Bartosik + - Raghuveer Devulapalli - Rakesh Vasudevan + - Ralf Gommers - RenaRuirui + - Robert Kern - Roman Yurchak - Ross Barnowski + - Ryan + - Ryan Soklaski - Sanjeev Kumar + - SanthoshBala18 + - Sayed Adel + - Sebastian Berg - Seth Troisi - Sha Liu + - Siba Smarak Panigrahi + - Simon Gasse + - Stephan Hoyer - Steve Dower + - Thomas A Caswell - Till Hoffmann + - Tim Hoffmann - Tina Oberoi + - Tirth Patel - Tyler Reddy - Warren Weckesser - Wojciech Rzadkowski + - Xavier Thomas + - Yilin LI + - Zac Hatfield-Dodds + - Zé Vinícius + - @Adam + - @Anthony + - @Jim + - @bartosz-grabowski + - @dojafrat + - @gamboon + - @jfbu + - @keremh + - @mayeut + - @ndunnewind + - @nglinh + - @shreepads + - @sslivkoff + Cheers, Charles Harris [View Less]

1 0

NumPy 1.19.0 release coming this weekend.
by Charles R Harris June 20, 2020

June 20, 2020

Hi All, Just a heads up. There are no open PRs or issues with the 1.19.0 milestone and no reported problems with the 1.10.0rc2 release that I am aware of. Let me know if I have missed anything. Chuck

1 0

NumPy team update
by Ralf Gommers June 19, 2020

June 19, 2020

Hi all, The NumPy team is growing, and it's awesome to see everything that is going on. Hard to keep up with, but that's a good thing! I think it's a good time for an update on people who gained commit rights, or joined one of the teams we now have. For those who haven't seen it yet, we have a team gallery at https://numpy.org/gallery/team.html. It isn't yet updated for the changes in this email, but gives a good picture of the current state. Matti Picus joined the Steering Council. He has … [View More]been one of the driving forces behind NumPy for well over two years now, and we're very glad to have him join the council. Ross Barnowski, Melissa Weber Mendonça, Josh Wilson and Bas van Beek gained commit rights. Ross has worked on the docs and reviewed lots of doc PRs for the last six months. Melissa has led the doc structuring and tutorial writing effort and has done a good amount of f2py maintenance as well. Josh and Bas have been pushing the type annotation work forward, first in the numpy-stubs repo and now in master. It's great to have experts in all these topics join the team. Furthermore, we now have 10+ people in the community calls, the triage calls and the docs team calls (all bi-weekly and on the NumPy community calendar [1] - everyone is welcome). And there's more going on - I feel like I should mention some of the other excellent work going on: A lot of work is going into SIMD optimizations. Sayed Adel has made very nice progress on implementing universal intrinsics (NEP 38), and Raghuveer Devulapalli, Chunlin Fang and others have contributed SSE/AVX and ARM Neon implementations for many functions. For the website, Shaloo Shalini has continued working on new case studies, we're about to merge a really nice one on tracking animal movement. Ben Nathanson has contributed his technical writing and editing skills to improve our website and documentation content. And Isabela Presedo-Floyd has taken up the challenge of redesigning the NumPy logo, and we're nearing the end of the process there. The survey team has also been working hard. Inessa Pawson, Xiaoyi Deng, Stephanie Mendoza, Ross Barnowski, Sebastian Berg and a number of volunteers for translations are getting a really well-designed survey together. And then of course there's both old hands and new people doing the regular maintenance and enhancement work on the main repo. Writing this email started with "we just gave out some commit rights, we should put that on the mailing list". Then I realized there's lots of other people and activities that deserve a shout out. And probably more that I forgot (if so, apologies!). I'll stop here - thanks everyone for all you do! Cheers, Ralf [1] https://calendar.google.com/calendar?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyam… [View Less]

4 3

`np.array()`, array-likes, nested sequences and subclasses
by Sebastian Berg June 18, 2020

June 18, 2020

Hi all, tl;dr: `np.array()` is somewhat ill-defined, also creating issues for Quantities. In a recent PR I am cementing, and slightly broadening, its definition. So we have to decide how we wish to handle code such as in the long run: np.array([array-like, array-like]) --- Traditionally, we have two meanings of "array-like" as understood by `np.array()` (In the text I use array-like for the second point here): 1. Nested sequences of scalars. 2. A single array-like object, … [View More]meaning a buffer-interface, an array subclass, a pandas dataframe (`__array__()`), etc. However, the boundaries between these are fuzzy, and over the years became more fuzzy. The reason is that a NumPy array (and many array- likes) are also nested sequences of scalars. I defined the current behaviour slightly clearer in my PR, but by that also subtly broadened it up [0]: 1. Any array-like embedded in the nested-sequences is converted to a NumPy array. [1] (Any array-like is never interpreted as a sequence) 2. Any array-like's elements will be elements of the output. We never enter array-likes recursively (including object arrays). 3. The `subok=True` parameter is implicitly ignored, unless the input is a single ndarray sublcass. Now to the issues at hand: * We should make sure those defintions are good, they mainly cement current behaviour, but if we want to roll back on features, we should do it now. * There are some issues around Quantity and masked arrays, because their "scalars" are (sometimes) 0-D arrays. And they currently rely on NumPy considering them to be scalars. This has its own set of long term issues [2]. For now, I can simply roll the changes to 0-D array behaviour back. But in the mid-to-long run, we have to make a decision, or perpetually live with array subclasses being subtly broken: 1. Define Quantity and Masked arrays as wrong. They must use a special DType, which consistently tells NumPy that the elements cannot simply be copied by converting the Quantity to an array. The up-side is, that it generalizes to N-D. 2. Independently, but partially addressing the Quantity issue, we have to decide what `np.array()` should actually do. A sequence containing array-likes, in most cases is better written using `np.stack()`, but due to the fuzzy boundaries, code like `np.array([dataframe, dataframe])` is probably common. We could try to deprecate though. The downsides to deprecation seem to me that I feel we have to reject viewing array-likes as sequences. To me doing that has its own set of issues. If just that `np.array([arraylike])` seems perfectly reasonable, but may be very slow. - Sebastian [0] It is hard to list how exactly it is broadened up, because the current behaviour has very subtle behaviours, such as actually iterating a `memoryview()`, which does always the same thing, but only works for 1-D memoryviews, and fails for both 0-D and N-D. [1] There are some subtleties which are not important here, such that I do anticipate the possibility of having array-likes which are considered scalars with respect to a given dtype, such as `np.array([poly], dtype=Polynomial)` where a poly object itself is an array-like. [2] Basically: np.array([0d_array], dtype=user_dtype) works, by ending up calling: res[0] = float(0d_array) # quantity.__float__ is used! which works nice for the typical float/int dtype, is tricky to get right for general dtypes (e.g. longdouble/clongdouble). This is a small issue now, but it could become a problem when more user-dtypes are defined. [View Less]

1 0

help translating Hindi into English
by Inessa Pawson June 18, 2020

June 18, 2020

The initial stage of the NumPy community survey project in partnership with the students and faculty from the Master’s program in Survey Methodology at the University of Michigan and the University of Maryland has been successfully completed. Currently, we are looking for a volunteer to help with the back translation of the Hindi version of the survey questionnaire (Hindi into English). If you are available, or you know someone who would be interested to help, please leave a comment here: … [View More]

2 2

NumPy Development Meeting Tomorrow - Triage Focus
by Sebastian Berg June 16, 2020

June 16, 2020

Hi all, Our bi-weekly triage-focused NumPy development meeting is tomorrow (Wednesday, June 17th) 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

ANN: SciPy 1.5.0rc2 -- please test
by Tyler Reddy June 14, 2020

June 14, 2020

Hi all, On behalf of the SciPy development team I'm pleased to announce the release candidate SciPy 1.5.0rc2. Please help us test this pre-release. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.5.0rc2 One of a few ways to install the release candidate with pip: pip install scipy==1.5.0rc2 ========================== SciPy 1.5.0 Release Notes ========================== .. note:: Scipy 1.5.0 is not released … [View More]

1 0

Deprecating python type aliases (np.int, np.long, np.str, ...)
by Sebastian Berg June 11, 2020

June 11, 2020

Hi all, In the pull request: https://github.com/numpy/numpy/pull/14882 Eric proposes to deprecate the type aliases which NumPy imports into its main namespace (e.g. np.int, np.bool, see table below [1]). Right now there seems to be a consensus to move this forward and I plan on doing that, so this is a heads-up in case anyone has a differing opinion. The deprecation should not be very noisy as such, but I expect it will require many projects to update their code in the long run (although … [View More]

1 1

Armv8 server donation
by ChunLin Fang June 11, 2020

June 11, 2020

Hi, all: I noticed that the shippable CI always skipped after PR submitted , The reason why it's skip seems to be "No active nodes found in shared node pool "shippable_shared_aarch64"" Potential bugs may buried through out numpy without shippable CI. I happened to own an idle armv8 server that can donate to numpy community, please let me know if that can improve numpy's CI/CD environment , also need somebody help me set up the CI/CD environment on that server. Best wishes Fang ChunLin.… [View More]

3 2

NumPy Community Meeting Wednesday
by Sebastian Berg June 9, 2020

June 9, 2020

Hi all, There will be a NumPy Community meeting Wednesday May 27th at 1pm Pacific Time (20:00 UTC [0]). 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

Re: [Numpy-discussion] Numpy Documentation: How-to content
by Ryan C. Cooper June 8, 2020

June 8, 2020

> This sounds fantastic. Great! > In what context would the students be creating the notebooks -- as > part of one of your existing ME courses, as a for-credit project, as a > supervised but non-credit project? These would be supervised projects either for work-study or credit. > What were your thoughts on submission workflow? You review initially, > then the student directly submits a PR? My plan was to mentor the initial idea and creation and help the students submit … [View More]

2 1

introducing autoreg and autoregnn
by rondall jones June 6, 2020

June 6, 2020

Hello! I have supported constrained solvers for linear matrix problems for about 10 years in C++, but have now switched to Python. I am going to submit a couple of new routines for linalg called autoreg(A,b) and autoregnn(A,b). They work just like lstsq(A,b) normally, but when they detect that the problem is dominated by noise they revert to an automatic regularization scheme that returns a better behaved result than one gets from lstsq. In addition, autoregnn enforces a nonnegativity … [View More]

3 2

Call for expertise: Blocked iteration
by Sebastian Berg June 5, 2020

June 5, 2020

Hi all, I am curious about exploring whether or not we could add simple blocked iteration to NumPy. It seems like a long standing small deficiency in NumPy that we do not support blocked iteration. I do not know how much speed gain we would actually have in real world code, but I assume some bad-memory-order copies could be drastically faster. Implementing blocked iteration for NumPy seems pretty complicated on first sight due to the complexity of the iterator and the fact that almost no-one … [View More]

1 0

Fixing fromfile to throw error when opening on gzip files
by Sidhant Bansal June 4, 2020

June 4, 2020

In regard to the issue: https://github.com/numpy/numpy/issues/7713 And my corresponding PR: https://github.com/numpy/numpy/pull/16221 I was advised to put this on the mailing list to get a general sense of how the issue is affecting people and to discuss how I can improve the current PR. I am still interested in resolving this issue, so will be glad to do some re-work to be able to get this merged and fix the issue. The currently proposed PR is a kind of band-aid solution which uses an if-… [View More]

1 0

(no subject)
by Charles R Harris June 4, 2020

June 4, 2020

Hi All, On behalf of the NumPy team I am pleased to announce that NumPy 1.19.0rc2 has been released. This NumPy release supports Python 3.6-3.8 and is marked by the removal of much technical debt: support for Python 2 has been removed, many deprecations have been expired, and documentation has been improved. The polishing of the random module continues apace with bug fixes and better usability from Cython. Perhaps the most interesting thing for users will be the availability of wheels for … [View More]aarch64 and PyPY. Downstream developers should use Cython >= 0.29.16 for Python 3.8 support and OpenBLAS >= 3.7 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.0rc2/>, source archives and release notes are available from Github <https://github.com/numpy/numpy/releases/tag/v1.19.0rc2>. *Contributors* A total of 124 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Alex Henrie - Alexandre de Siqueira + - Andras Deak - Andrea Sangalli + - Andreas Klöckner + - Andrei Shirobokov + - Anirudh Subramanian + - Anne Bonner - Anton Ritter-Gogerly + - Benjamin Trendelkamp-Schroer + - Bharat Raghunathan - Brandt Bucher + - Brian Wignall - Bui Duc Minh + - Changqing Li + - Charles Harris - Chris Barker - Chris Holland + - Christian Kastner + - Chunlin + - Chunlin Fang + - Damien Caliste + - Dan Allan - Daniel Hrisca - Daniel Povey + - Dustan Levenstein + - Emmanuelle Gouillart + - Eric Larson - Eric M. Bray - Eric Mariasis + - Eric Wieser - Erik Welch + - Fabio Zeiser + - Gabriel Gerlero + - Ganesh Kathiresan + - Gengxin Xie + - Guilherme Leobas - Guillaume Peillex + - Hameer Abbasi - Hao Jin + - Harshal Prakash Patankar + - Heshy Roskes + - Himanshu Garg + - Huon Wilson + - John Han + - John Kirkham - Jon Dufresne - Jon Morris + - Josh Wilson - Justus Magin - Kai Striega - Kerem Hallaç + - Kevin Sheppard - Kirill Zinovjev + - Marcin Podhajski + - Mark Harfouche - Marten van Kerkwijk - Martin Michlmayr + - Masashi Kishimoto + - Mathieu Lamarre - Matt Hancock + - MatteoRaso + - Matthew Harrigan - Matthias Bussonnier - Matti Picus - Max Balandat + - Maximilian Konrad + - Maxwell Aladago - Maxwell Bileschi + - Melissa Weber Mendonça + - Michael Felt - Mike Taves - Nico Schlömer - Pan Jan + - Paul Rougieux + - Pauli Virtanen - Peter Andreas Entschev - Petre-Flaviu Gostin + - Pierre de Buyl - Piotr Gaiński + - Przemyslaw Bartosik + - Raghuveer Devulapalli - Rakesh Vasudevan + - Ralf Gommers - RenaRuirui + - Roman Yurchak - Ross Barnowski + - Ryan + - Ryan Soklaski - Sanjeev Kumar + - SanthoshBala18 + - Sayed Adel + - Sebastian Berg - Seth Troisi - Sha Liu + - Siba Smarak Panigrahi + - Simon Gasse + - Stephan Hoyer - Steve Dower + - Thomas A Caswell - Till Hoffmann + - Tim Hoffmann - Tina Oberoi + - Tirth Patel - Tyler Reddy - Warren Weckesser - Wojciech Rzadkowski + - Xavier Thomas + - Yilin LI + - Zac Hatfield-Dodds + - Zé Vinícius + - @Adam + - @Anthony + - @Jim + - @bartosz-grabowski + - @dojafrat + - @gamboon + - @jfbu + - @keremh + - @mayeut + - @ndunnewind + - @nglinh + - @shreepads + - @sslivkoff + Cheers, Charles Harris [View Less]

4 8

NumPy 1.18.5 released
by Charles R Harris June 4, 2020

June 4, 2020

Hi All, On behalf of the NumPy team I am pleased to announce the release of NumPy 1.18.5. This is a short release to enable pickle protocol=5 to be used in Python3.5 and is motivated by the recent backport of pickle5 to Python3.5. The Python versions supported in this release are 3.5-3.8. Downstream developers should use Cython >= 0.29.15 for Python 3.8 support and OpenBLAS >= 3.7 to avoid errors on the Skylake architecture. Wheels for this release can be downloaded from PyPI <https:/… [View More]

1 0

NumPy Development Meeting Tomorrow - Triage Focus
by Sebastian Berg June 2, 2020

June 2, 2020

Hi all, Our bi-weekly triage-focused NumPy development meeting is tomorrow (Wednesday, June 3rd) 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

Reminder: June 01 Deadline for the 2020 John Hunter Excellence in Plotting contest!
by Madicken Munk June 1, 2020

June 1, 2020

Dear numpy community, My apologies for repeated in-list and cross-list posts! I'd like to remind everybody that the 2020 John Hunter Excellence in Plotting Contest submission deadline is June 01 -- only a few days away. We welcome and look forward to your submissions! In memory of John Hunter, we are pleased to announce the John Hunter Excellence in Plotting Contest for 2020. This open competition aims to highlight the importance of data visualization to scientific progress and showcase … [View More]the capabilities of open source software. Participants are invited to submit scientific plots to be judged by a panel. The winning entries will be announced and displayed at SciPy 2020 or announced in the John Hunter Excellence in Plotting Contest website and youtube channel. John Hunter’s family are graciously sponsoring cash prizes for the winners in the following amounts: - 1st prize: $1000 - 2nd prize: $750 - 3rd prize: $500 - Entries must be submitted by June 1st to the form at https://forms.gle/SrexmkDwiAmDc7ej7 - Winners will be announced at Scipy 2020 or publicly on the John Hunter Excellence in Plotting Contest website and youtube channel - Participants do not need to attend the Scipy conference. - Entries may take the definition of “visualization” rather broadly. Entries may be, for example, a traditional printed plot, an interactive visualization for the web, a dashboard, or an animation. - Source code for the plot must be provided, in the form of Python code and/or a Jupyter notebook, along with a rendering of the plot in a widely used format. The rendering may be, for example, PDF for print, standalone HTML and Javascript for an interactive plot, or MPEG-4 for a video. If the original data can not be shared for reasons of size or licensing, "fake" data may be substituted, along with an image of the plot using real data. - Each entry must include a 300-500 word abstract describing the plot and its importance for a general scientific audience. - Entries will be judged on their clarity, innovation and aesthetics, but most importantly for their effectiveness in communicating a real-world problem. Entrants are encouraged to submit plots that were used during the course of research or work, rather than merely being hypothetical. - SciPy and the John Hunter Excellence in Plotting Contest organizers reserves the right to display any and all entries, whether prize-winning or not, at the conference, use in any materials or on its website, with attribution to the original author(s). - Past entries can be found at https://jhepc.github.io/ - Questions regarding the contest can be sent to jhepc.organizers(a)gmail.com John Hunter Excellence in Plotting Contest Co-Chairs Madicken Munk Nelle Varoquaux [View Less]

1 1