Mailman 3 January 2021 - 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. 3, 2022

Dec. 3, 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 10, 2022

May 10, 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

Unreliable crash when converting using numpy.asarray via C buffer interface
by Friedrich Romstedt March 29, 2021

March 29, 2021

Hi, This is with Python 3.8.2 64-bit and numpy 1.19.2 on Windows 10. I'd like to be able to convert some C++ extension type to a numpy array by using ``numpy.asarray``. The extension type implements the Python buffer interface to support this. The extension type, called "Image" here, holds some chunk of ``double``, C order, contiguous, 2 dimensions. It "owns" the buffer; the buffer is not shared with other objects. The following Python code crashes:: image = <... Image production .… [View More]

7 16

On the use of adding an expfit class in or next to the polynomial module
by Swan BOSC Jan. 30, 2021

Jan. 30, 2021

Hello people ! First-of-all, thank you for your great service to the Python community. I'm working for a project on porting some Octave code base towards Python. As you can imagine, it is a lot of fun, but I sometimes come across functions that are not (yet ?) available in the mighty NumPy package. Namely, the expfit function, as presented [here](https://octave.sourceforge.io/optim/function/expfit.html) (https://octave.sourceforge.io/optim/function/expfit.html) doesn't seem to exist. I'm … [View More]

2 2

NumPy 1.20.0 released
by Charles R Harris Jan. 30, 2021

Jan. 30, 2021

Hi All, On behalf of the NumPy team I am pleased to announce the release of NumPy 1.20.0rc2. This NumPy release is the largest to date, containing some 684 merged pull requests contributed by 184 people. See the list of highlights below. The Python versions supported for this release are 3.7-3.9, support for Python 3.6 has been dropped. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.20.0/>; source archives, release notes, and wheel hashes are available on Github … [View More]<https://github.com/numpy/numpy/releases/tag/v1.20.0>. Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. *Highlights* - Annotations for NumPy functions. This work is ongoing and improvements can be expected pending feedback from users. - Wider use of SIMD to increase execution speed of ufuncs. Much work has been done in introducing universal functions that will ease use of modern features across different hardware platforms. This work is ongoing. - Preliminary work in changing the dtype and casting implementations in order to provide an easier path to extending dtypes. This work is ongoing but enough has been done to allow experimentation and feedback. - Extensive documentation improvements comprising some 185 PR merges. This work is ongoing and part of the larger project to improve NumPy's online presence and usefulness to new users. - Further cleanups related to removing Python 2.7. This improves code readability and removes technical debt. - Preliminary support for the upcoming Cython 3.0. *Contributors* A total of 184 people contributed to this release. People with a "+" by their names contributed a patch for the first time. * Aaron Meurer + * Abhilash Barigidad + * Abhinav Reddy + * Abhishek Singh + * Al-Baraa El-Hag + * Albert Villanova del Moral + * Alex Leontiev + * Alex Rockhill + * Alex Rogozhnikov * Alexander Belopolsky * Alexander Kuhn-Regnier + * Allen Downey + * Andras Deak * Andrea Olivo + * Andrew Eckart + * Anirudh Subramanian * Anthony Byuraev + * Antonio Larrosa + * Ashutosh Singh + * Bangcheng Yang + * Bas van Beek + * Ben Derrett + * Ben Elliston + * Ben Nathanson + * Bernie Gray + * Bharat Medasani + * Bharat Raghunathan * Bijesh Mohan + * Bradley Dice + * Brandon David + * Brandt Bucher * Brian Soto + * Brigitta Sipocz * Cameron Blocker + * Carl Leake + * Charles Harris * Chris Brown + * Chris Vavaliaris + * Christoph Gohlke * Chunlin Fang * CloseChoice + * Daniel G. A. Smith + * Daniel Hrisca * Daniel Vanzo + * David Pitchford + * Davide Dal Bosco + * Derek Homeier * Dima Kogan + * Dmitry Kutlenkov + * Douglas Fenstermacher + * Dustin Spicuzza + * E. Madison Bray + * Elia Franzella + * Enrique Matías Sánchez + * Erfan Nariman | Veneficus + * Eric Larson * Eric Moore * Eric Wieser * Erik M. Bray * EthanCJ-git + * Etienne Guesnet + * FX Coudert + * Felix Divo * Frankie Robertson + * Ganesh Kathiresan * Gengxin Xie * Gerry Manoim + * Guilherme Leobas * Hassan Kibirige * Hugo Mendes + * Hugo van Kemenade * Ian Thomas + * InessaPawson + * Isabela Presedo-Floyd + * Isuru Fernando * Jakob Jakobson + * Jakub Wilk * James Myatt + * Jesse Li + * John Hagen + * John Zwinck * Joseph Fox-Rabinovitz * Josh Wilson * Jovial Joe Jayarson + * Julia Signell + * Jun Kudo + * Karan Dhir + * Kaspar Thommen + * Kerem Hallaç * Kevin Moore + * Kevin Sheppard * Klaus Zimmermann + * LSchroefl + * Laurie + * Laurie Stephey + * Levi Stovall + * Lisa Schwetlick + * Lukas Geiger + * Madhulika Jain Chambers + * Matthias Bussonnier * Matti Picus * Melissa Weber Mendonça * Michael Hirsch * Nick R. Papior * Nikola Forró * Noman Arshad + * Paul YS Lee + * Pauli Virtanen * Paweł Redzyński + * Peter Andreas Entschev * Peter Bell * Philippe Ombredanne + * Phoenix Meadowlark + * Piotr Gaiński * Raghav Khanna + * Raghuveer Devulapalli * Rajas Rade + * Rakesh Vasudevan * Ralf Gommers * Raphael Kruse + * Rashmi K A + * Robert Kern * Rohit Sanjay + * Roman Yurchak * Ross Barnowski * Royston E Tauro + * Ryan C Cooper + * Ryan Soklaski * Safouane Chergui + * Sahil Siddiq + * Sarthak Vineet Kumar + * Sayed Adel * Sebastian Berg * Sergei Vorfolomeev + * Seth Troisi * Sidhant Bansal + * Simon Gasse * Simon Graham + * Stefan Appelhoff + * Stefan Behnel + * Stefan van der Walt * Steve Dower * Steve Joachim + * Steven Pitman + * Stuart Archibald * Sturla Molden * Susan Chang + * Takanori H + * Tapajyoti Bose + * Thomas A Caswell * Tina Oberoi * Tirth Patel * Tobias Pitters + * Tomoki, Karatsu + * Tyler Reddy * Veniamin Petrenko + * Wansoo Kim + * Warren Weckesser * Wei Yang + * Wojciech Rzadkowski * Yang Hau + * Yogesh Raisinghani + * Yu Feng * Yuya Unno + * Zac Hatfield-Dodds * Zuhair Ali-Khan + * @abhilash42 + * @danbeibei + * @dojafrat * @dpitch40 + * @forfun + * @iamsoto + * @jbrockmendel + * @leeyspaul + * @mitch + * @prateek arora + * @serge-sans-paille + * @skywalker + * @stphnlyd + * @xoviat * @谭九鼎 + * @JMFT + * @Jack + * @Neal C + Cheers, Charles Harris [View Less]

1 0

PSF Scientific WG grants
by Stefan van der Walt Jan. 27, 2021

Jan. 27, 2021

Hi all, I'd like to make you aware of this call for funding from the PSF: https://pyfound.blogspot.com/2020/12/psf-scientific-working-group-announces… Funding is for up to 4000 USD. The deadline has been extended (the blog post will soon be updated accordingly); I recommend submitting requests within the next two weeks. Stéfan

1 0

Value based promotion and user DTypes
by Sebastian Berg Jan. 27, 2021

Jan. 27, 2021

Hi all, does anyone have a thought about how user DTypes (i.e. DTypes not currently part of NumPy) should interact with the "value based promotion" logic we currently have? For now I can just do anything, and we will find out later. And I will have to do something for now, basically with the hope that it all turns out all-right. But there are multiple options for both what to offer to user DTypes and where we want to move (I am using `bfloat16` as a potential DType here). 1. The "weak" … [View More]dtype option (this is what JAX does), where: np.array([1], dtype=bfloat16) + 4. returns a bfloat16, because 4. is "lower" than all floating point types. In this scheme the user defined `bfloat16` knows that the input is a Python float, but it does not know its value (if an overflow occurs during conversion, it could warn or error but not upcast). For example `np.array([1], dtype=uint4) + 2**5` will try `uint4(2**5)` assuming it works. NumPy is different `2.**300` would ensure the result is a `float64`. If a DType does not make use of this, it would get the behaviour of option 2. 2. The "default" DType option: np.array([1], dtype=bfloat16) + 4. is always the same as `bfloat16 + float64 -> float64`. 3. Use whatever NumPy considers the "smallest appropriate dtype". This will not always work correctly for unsigned integers, and for floats this would be float16, which doesn't help with bfloat16. 4. Try to expose the actual value. (I do not want to do this, but it is probably a plausible extension with most other options, since the other options can be the "default".) Within these options, there is one more difficulty. NumPy currently applies the same logic for: np.array([1], dtype=bfloat16) + np.array(4., dtype=np.float64) which in my opinion is wrong (the second array is typed). We do have the same issue with deciding what to do in the future for NumPy itself. Right now I feel that new (user) DTypes should live in the future (whatever that future is). I have said previously, that we could distinguish this for universal functions. But calls like `np.asarray(4.)` are common, and they would lose the information that `4.` was originally a Python float. So, recently, I was considering that a better option may be to limit this to math Python operators: +, -, /, **, ... Those are the places where it may make a difference to write: arr + 4. vs. arr + bfloat16(4.) int8_arr + 1 vs. int8_arr + np.int8(1) arr += 4. (in-place may be the most significant use-case) while: np.add(int8_arr, 1) vs. np.add(int8_arr, np.int8(1)) is maybe less significant. On the other hand, it would add a subtle difference between operators vs. direct ufunc calls... In general, it may not matter: We can choose option 1 (which the bfloat16 does not have to use), and modify it if we ever change the logic in NumPy itself. Basically, I will probably pick option 1 for now and press on, and we can reconsider later. And hope that it does not make things even more complicated than it is now. Or maybe better just limit it completely to always use the default for user DTypes? But I would be interested if the "limit to Python operators" is something we should aim for here. This does make a small difference, because user DTypes could "live" in the future if we have an idea of how that future may look like. Cheers, Sebastian [View Less]

3 7

Re: [Numpy-discussion] NumPy video content: creating a YouTube channel
by Joe Harrington Jan. 27, 2021

Jan. 27, 2021

On 1/25/21, 12:44 PM, Melissa Mendonça <melissawm(a)gmail.com> wrote: > The NumPy Documentation Team has been discussing video content as part > of our outreach and documentation efforts, in part inspired by the > excellent Spyder IDE channel [1]. At our last meeting, we realized > there is already a good amount of content about NumPy on YouTube (a > few examples [2, 3, 4]). We thought about creating a YouTube account > for NumPy and listing those videos in a … [View More]

2 1

Addition of new distributions: Polya-gamma
by Zolisa Bleki Jan. 27, 2021

Jan. 27, 2021

Hi All, I would like to know if Numpy accepts addition of new distributions since the implementation of the Generator interface. If so, what is the criteria for a particular distribution to be accepted? The reason why i'm asking is because I would like to propose adding the Polya-gamma distribution to numpy, for the following reasons: 1) Polya-gamma random variables are commonly used as auxiliary variables during data augmentation in Bayesian sampling algorithms, which have wide-spread usage … [View More]

5 5

NumPy Development Meeting Wednesday - Triage Focus
by Sebastian Berg Jan. 27, 2021

Jan. 27, 2021

Hi all, Our bi-weekly triage-focused NumPy development meeting is Wednesday, Jan 27th at 11 am Pacific Time (19: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, discussed, or reviewed. Best regards Sebastian

1 0

updated backwards compatibility and deprecation policy NEP
by Ralf Gommers Jan. 26, 2021

Jan. 26, 2021

Hi all, Here is a long overdue update of the draft NEP about backwards compatibility and deprecation policy: https://github.com/numpy/numpy/pull/18097 - This is NEP 23: https://numpy.org/neps/nep-0023-backwards-compatibility.html - Link to the previous mailing list discussion: https://mail.python.org/pipermail/numpy-discussion/2018-July/078432.html It would be nice to get this NEP to Accepted status. Main changes are: - Removed all examples that people objected to - Removed all content … [View More]regarding versioning - Restructured sections, and added "Strategies related to deprecations" (using suggestions by @njsmith and @shoyer). - Added concrete examples of deprecations, and a more thorough description of how to go about adding warnings incl. Sphinx directives, using `stacklevel`, etc. As always, feedback here or on the PR is very welcome! Cheers, Ralf Abstract -------- In this NEP we describe NumPy's approach to backwards compatibility, its deprecation and removal policy, and the trade-offs and decision processes for individual cases where breaking backwards compatibility is considered. Motivation and Scope -------------------- NumPy has a very large user base. Those users rely on NumPy being stable and the code they write that uses NumPy functionality to keep working. NumPy is also actively maintained and improved -- and sometimes improvements require, or are made much easier by, breaking backwards compatibility. Finally, there are trade-offs in stability for existing users vs. avoiding errors or having a better user experience for new users. These competing needs often give rise to long debates and to delays in accepting or rejecting contributions. This NEP tries to address that by providing a policy as well as examples and rationales for when it is or isn't a good idea to break backwards compatibility. In scope for this NEP are: - Principles of NumPy's approach to backwards compatibility. - How to deprecate functionality, and when to remove already deprecated functionality. - Decision making process for deprecations and removals. Out of scope are: - Making concrete decisions about deprecations of particular functionality. - NumPy's versioning scheme. General principles ------------------ When considering proposed changes that are backwards incompatible, the main principles the NumPy developers use when making a decision are: 1. Changes need to benefit users more than they harm them. 2. NumPy is widely used so breaking changes should by default be assumed to be fairly harmful. 3. Decisions should be based on data and actual effects on users and downstream packages rather than, e.g., appealing to the docs or for stylistic reasons. 4. Silently getting a wrong answer is much worse than getting a loud error. When assessing the costs of proposed changes, keep in mind that most users do not read the mailing list, do not look at deprecation warnings, and sometimes wait more than one or two years before upgrading from their old version. And that NumPy has millions of users, so "no one will do or use this" is very likely incorrect. Benefits include improved functionality, usability and performance, as well as lower maintenance cost and improved future extensibility. Fixes for clear bugs are exempt from this backwards compatibility policy. However in case of serious impact on users (e.g. a downstream library doesn't build anymore or would start giving incorrect results), even bug fixes may have to be delayed for one or more releases. Strategies related to deprecations ---------------------------------- Getting hard data on the impact of a deprecation of often difficult. Strategies that can be used to assess such impact include: - Use a code search engine ([1]_) or static ([2]_) or dynamic ([3]_) code analysis tools to determine where and how the functionality is used. - Testing prominent downstream libraries against a development build of NumPy containing the proposed change to get real-world data on its impact. - Making a change in master and reverting it, if needed, before a release. We do encourage other packages to test against NumPy's master branch, so this often turns up issues quickly. If the impact is unclear or significant, it is often good to consider alternatives to deprecations. For example discouraging use in documentation only, or moving the documentation for the functionality to a less prominent place or even removing it completely. Commenting on open issues related to it that they are low-prio or labeling them as "wontfix" will also be a signal to users, and reduce the maintenance effort needing to be spent. Implementing deprecations and removals -------------------------------------- Deprecation warnings are necessary in all cases where functionality will eventually be removed. If there is no intent to remove functionality, then it should not be deprecated either. A "please don't use this" in the documentation or other type of warning should be used instead. Deprecations: - shall include the version number of the release in which the functionality was deprecated. - shall include information on alternatives to the deprecated functionality, or a reason for the deprecation if no clear alternative is available. - shall use ``VisibleDeprecationWarning`` rather than ``DeprecationWarning`` for cases of relevance to end users. For cases only relevant to downstream libraries, a regular ``DeprecationWarning`` is fine. *Rationale: regular deprecation warnings are invisible by default; library authors should be aware how deprecations work and test for them, but we can't expect this from all users.* - shall be listed in the release notes of the release where the deprecation is first present. - shall set a ``stacklevel``, so the warning appears to come from the correct place. - shall be mentioned in the documentation for the functionality. A ``.. deprecated::`` directive can be used for this. Examples of good deprecation warnings: .. code-block:: python warnings.warn('np.asscalar(a) is deprecated since NumPy 1.16.0, use ' 'a.item() instead', DeprecationWarning, stacklevel=3) warnings.warn("Importing from numpy.testing.utils is deprecated " "since 1.15.0, import from numpy.testing instead.", DeprecationWarning, stacklevel=2) # A change in NumPy 1.14.0 for Python 3 loadtxt/genfromtext, slightly # tweaked in this NEP (original didn't have version number). warnings.warn( "Reading unicode strings without specifying the encoding " "argument is deprecated since NumPy 1.14.0. Set the encoding, " "use None for the system default.", np.VisibleDeprecationWarning, stacklevel=2) Removal of deprecated functionality: - shall be done after at least 2 releases (assuming the current 6-monthly release cycle; if that changes, there shall be at least 1 year between deprecation and removal). - shall be listed in the release notes of the release where the removal happened. - can be done in any minor (but not bugfix) release. For backwards incompatible changes that aren't "deprecate and remove" but for which code will start behaving differently, a ``FutureWarning`` should be used. Release notes, mentioning version number and using ``stacklevel`` should be done in the same way as for deprecation warnings. A ``.. versionchanged::`` directive can be used in the documentation to indicate when the behavior changed: .. code-block:: python def argsort(self, axis=np._NoValue, ...): """ Parameters ---------- axis : int, optional Axis along which to sort. If None, the default, the flattened array is used. .. versionchanged:: 1.13.0 Previously, the default was documented to be -1, but that was in error. At some future date, the default will change to -1, as originally intended. Until then, the axis should be given explicitly when ``arr.ndim > 1``, to avoid a FutureWarning. """ ... warnings.warn( "In the future the default for argsort will be axis=-1, not the " "current None, to match its documentation and np.argsort. " "Explicitly pass -1 or None to silence this warning.", MaskedArrayFutureWarning, stacklevel=3) Decision making ~~~~~~~~~~~~~~~ In concrete cases where this policy needs to be applied, decisions are made according to the `NumPy governance model <https://docs.scipy.org/doc/numpy/dev/governance/index.html>`_. All deprecations must be proposed on the mailing list, in order to give everyone with an interest in NumPy development to be able to comment. Removal of deprecated functionality does not need discussion on the mailing list. Functionality with more strict deprecation policies ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - ``numpy.random`` has its own backwards compatibility policy, see `NEP 19 <http://www.numpy.org/neps/nep-0019-rng-policy.html>`_. - The file format for ``.npy`` and ``.npz`` files must not be changed in a backwards incompatible way. Example cases ------------- We now discuss a few concrete examples from NumPy's history to illustrate typical issues and trade-offs. **Changing the behavior of a function** ``np.histogram`` is probably the most infamous example. First, a new keyword ``new=False`` was introduced, this was then switched over to None one release later, and finally it was removed again. Also, it has a ``normed`` keyword that had behavior that could be considered either suboptimal or broken (depending on ones opinion on the statistics). A new keyword ``density`` was introduced to replace it; ``normed`` started giving ``DeprecationWarning`` only in v.1.15.0. Evolution of ``histogram``:: def histogram(a, bins=10, range=None, normed=False): # v1.0.0 def histogram(a, bins=10, range=None, normed=False, weights=None, new=False): #v1.1.0 def histogram(a, bins=10, range=None, normed=False, weights=None, new=None): #v1.2.0 def histogram(a, bins=10, range=None, normed=False, weights=None): #v1.5.0 def histogram(a, bins=10, range=None, normed=False, weights=None, density=None): #v1.6.0 def histogram(a, bins=10, range=None, normed=None, weights=None, density=None): #v1.15.0 # v1.15.0 was the first release where `normed` started emitting # DeprecationWarnings The ``new`` keyword was planned from the start to be temporary. Such a plan forces users to change their code more than once, which is almost never the right thing to do. Instead, a better approach here would have been to deprecate ``histogram`` and introduce a new function ``hist`` in its place. **Disallowing indexing with floats** Indexing an array with floats is asking for something ambiguous, and can be a sign of a bug in user code. After some discussion, it was deemed a good idea to deprecate indexing with floats. This was first tried for the v1.8.0 release, however in pre-release testing it became clear that this would break many libraries that depend on NumPy. Therefore it was reverted before release, to give those libraries time to fix their code first. It was finally introduced for v1.11.0 and turned into a hard error for v1.12.0. This change was disruptive, however it did catch real bugs in, e.g., SciPy and scikit-learn. Overall the change was worth the cost, and introducing it in master first to allow testing, then removing it again before a release, is a useful strategy. Similar deprecations that also look like good examples of cleanups/improvements: - removing deprecated boolean indexing (in 2016, see `gh-8312 < https://github.com/numpy/numpy/pull/8312>`__) - deprecating truth testing on empty arrays (in 2017, see `gh-9718 < https://github.com/numpy/numpy/pull/9718>`__) **Removing the financial functions** The financial functions (e.g. ``np.pmt``) had short non-descriptive names, were present in the main NumPy namespace, and didn't really fit well within NumPy's scope. They were added in 2008 after `a discussion < https://mail.python.org/pipermail/numpy-discussion/2008-April/032353.html>`_ on the mailing list where opinion was divided (but a majority in favor). The financial functions didn't cause a lot of overhead, however there were still multiple issues and PRs a year for them which cost maintainer time to deal with. And they cluttered up the ``numpy`` namespace. Discussion on removing them happened in 2013 (gh-2880, rejected) and then again in 2019 (:ref:`NEP32`, accepted without significant complaints). Given that they were clearly outside of NumPy's scope, moving them to a separate ``numpy-financial`` package and removing them from NumPy after a deprecation period made sense. Alternatives ------------ **Being more aggressive with deprecations.** The goal of being more aggressive is to allow NumPy to move forward faster. This would avoid others inventing their own solutions (often in multiple places), as well as be a benefit to users without a legacy code base. We reject this alternative because of the place NumPy has in the scientific Python ecosystem - being fairly conservative is required in order to not increase the extra maintenance for downstream libraries and end users to an unacceptable level. Discussion ---------- - `Mailing list discussion on the first version of this NEP in 2018 < https://mail.python.org/pipermail/numpy-discussion/2018-July/078432.html>`__ References and Footnotes ------------------------ - `Issue requesting semantic versioning < https://github.com/numpy/numpy/issues/10156>`__ .. [1] https://searchcode.com/ .. [2] https://github.com/Quansight-Labs/python-api-inspect .. [3] https://github.com/data-apis/python-record-api [View Less]

5 9

Comment published in Nature Astronomy about The ecological impact of computing with Python
by PIERRE AUGIER Jan. 26, 2021

Jan. 26, 2021

Hi, I recently took a bit of time to study the comment "The ecological impact of high-performance computing in astrophysics" published in Nature Astronomy (Zwart, 2020, https://www.nature.com/articles/s41550-020-1208-y, https://arxiv.org/pdf/2009.11295.pdf), where it is stated that "Best however, for the environment is to abandon Python for a more environmentally friendly (compiled) programming language.". I wrote a simple Python-Numpy implementation of the problem used for this study (https:/… [View More]/www.nbabel.org) and, accelerated by Transonic-Pythran, it's very efficient. Here are some numbers (elapsed times in s, smaller is better): | # particles | Py | C++ | Fortran | Julia | |-------------|-----|-----|---------|-------| | 1024 | 29 | 55 | 41 | 45 | | 2048 | 123 | 231 | 166 | 173 | The code and a modified figure are here: https://github.com/paugier/nbabel (There is no check on the results for https://www.nbabel.org, so one still has to be very careful.) I think that the Numpy community should spend a bit of energy to show what can be done with the existing tools to get very high performance (and low CO2 production) with Python. This work could be the basis of a serious reply to the comment by Zwart (2020). Unfortunately the Python solution in https://www.nbabel.org is very bad in terms of performance (and therefore CO2 production). It is also true for most of the Python solutions for the Computer Language Benchmarks Game in https://benchmarksgame-team.pages.debian.net/benchmarksgame/ (codes here https://salsa.debian.org/benchmarksgame-team/benchmarksgame#what-else). We could try to fix this so that people see that in many cases, it is not necessary to "abandon Python for a more environmentally friendly (compiled) programming language". One of the longest and hardest task would be to implement the different cases of the Computer Language Benchmarks Game in standard and modern Python-Numpy. Then, optimizing and accelerating such code should be doable and we should be able to get very good performance at least for some cases. Good news for this project, (i) the first point can be done by anyone with good knowledge in Python-Numpy (many potential workers), (ii) for some cases, there are already good Python implementations and (iii) the work can easily be parallelized. It is not a criticism, but the (beautiful and very nice) new Numpy website https://numpy.org/ is not very convincing in terms of performance. It's written "Performant The core of NumPy is well-optimized C code. Enjoy the flexibility of Python with the speed of compiled code." It's true that the core of Numpy is well-optimized C code but to seriously compete with C++, Fortran or Julia in terms of numerical performance, one needs to use other tools to move the compiled-interpreted boundary outside the hot loops. So it could be reasonable to mention such tools (in particular Numba, Pythran, Cython and Transonic). Is there already something planned to answer to Zwart (2020)? Any opinions or suggestions on this potential project? Pierre PS: Of course, alternative Python interpreters (PyPy, GraalPython, Pyjion, Pyston, etc.) could also be used, especially if HPy (https://github.com/hpyproject/hpy) is successful (C core of Numpy written in HPy, Cython able to produce HPy code, etc.). However, I tend to be a bit skeptical in the ability of such technologies to reach very high performance for low-level Numpy code (performance that can be reached by replacing whole Python functions with optimized compiled code). Of course, I hope I'm wrong! IMHO, it does not remove the need for a successful HPy! -- Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels BP53, 38041 Grenoble Cedex, France tel:+33.4.56.52.86.16 [View Less]

12 22

accepting NEP 46 - sponsorship guidelines
by Ralf Gommers Jan. 26, 2021

Jan. 26, 2021

Hi all, The sponsorship guidelines PR ( https://numpy.org/neps/nep-0046-sponsorship-guidelines.html) was merged as Draft and everyone seems happy with it. I propose to change its status to Accepted. We'll merge a PR to do so unless there are objections within the next five days. Cheers, Ralf

1 0

NumPy video content: creating a YouTube channel
by Melissa Mendonça Jan. 26, 2021

Jan. 26, 2021

Hi all, The NumPy Documentation Team has been discussing video content as part of our outreach and documentation efforts, in part inspired by the excellent Spyder IDE channel [1]. At our last meeting, we realized there is already a good amount of content about NumPy on YouTube (a few examples [2, 3, 4]). We thought about creating a YouTube account for NumPy and listing those videos in a playlist, initially. Eventually, we can also add our own videos about how to contribute - we're still … [View More]

2 1

Compilation failures in f2py
by Samuel Dupree Jan. 25, 2021

Jan. 25, 2021

I'm attempting to wrap a Fortran-77 source member library using f2py. I'm running he Anaconda distribution for Python 3.7.6 on a Mac Pro (2019) under Mac OS X Big Sur (ver. 11.1). The version of Xcode.app I'm running is 12.3. The version of NumPy I'm running is 1.18.3. The errors I'm getting are from header files the compiler can't find as captured in the attached log file. A sample of the kind of errors I'm seeing are captured below. compile options: '-I/var/folders/2r/… [View More]

2 3

IRFFT of sound
by klark--kent＠yandex.ru Jan. 24, 2021

Jan. 24, 2021

2 1

NumPy Community Meeting Wednesday
by Sebastian Berg Jan. 20, 2021

Jan. 20, 2021

Hi all, There will be a NumPy Community meeting Wednesday January 20th at 12pm 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

UPD: Rivest-Floyd selection algorithm
by Виктория Малясова Jan. 16, 2021

Jan. 16, 2021

1 0

Subclassing vs. dispatch
by Israel, Daniel M Jan. 15, 2021

Jan. 15, 2021

I hope this is the right place to post this. The numpy documentation talks about two methods for making ndarray-like objects, subclassing and dispatching, but it is not clear to me which one is most appropriate for which purpose. Can someone provide, or point me to, some guidance, about this? I’m particularly interested in what happens if there are multiple layers of subclassing. Can you subclass from a subclass? Dispatch from a dispatch? Subclass from a dispatch and vice versa? My … [View More]

2 1

NumPy EOL Versions?
by Symphoni Bush - NOAA Affiliate Jan. 13, 2021

Jan. 13, 2021

I am trying to find out if there are any end-of-life versions for NumPy, and if so, when do these versions typically become EOL/unsupported? Thanks.

4 5

NumPy Development Meeting Wednesday - Triage Focus
by Sebastian Berg Jan. 13, 2021

Jan. 13, 2021

Hi all, Our bi-weekly triage-focused NumPy development meeting is tomorrow (Wednesday, Jan 13th) at 11 am Pacific Time (19: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, discussed, or reviewed. Best regards Sebastian

1 0

Re: [Numpy-discussion] numpy.linalg interference with matplot.lib
by Frederix96 Jan. 12, 2021

Jan. 12, 2021

Dear Kevin, Thanks for the suggestion. I do not have those Windows Versions. I have Microsoft Windows 10 Pro with Version 10.0.19041 Build 19041. Anyway I still tried upgrading to 1.19.5 with no changes. Thanks a lot! Best regards, Frederix96

1 0

using scalar input on np.PyArray_MultiIterNew2
by zoj613 Jan. 11, 2021

Jan. 11, 2021

Hi all, I am looking for a way to use `np.PyArray_MultiIterNew2` in Cython to broadcast parameters of a function. The requirement is that the two arguments can be scalar and/or sequences. Using the usual `np.broadcast` function works well but is slow when iterating over the broadcasted input in a tight loop. I want to achieve the same using the C API. Currently, if I used `(<double*>np.PyArray_MultiIter_DATA(bcast, i))[0]` to iterate over the input when one of them is a scalar, I get no … [View More]

2 5

How to speed up array generating
by klark--kent＠yandex.ru Jan. 11, 2021

Jan. 11, 2021

6 8

numpy.linalg interference with matplot.lib
by Frederix96 Jan. 11, 2021

Jan. 11, 2021

Dear numpy community, I am having an issue with numpy.linalg where a matrix inversion of a complex matrix using numpy.linalg.inv results in containing nan values when a plot of any kind was performed beforehand by matplotlib. For the specific details on the problem and what I have tried already see the stackoverflow post I started a month ago: https://stackoverflow.com/questions/65183984/why-does-plotting-something-wi… I know that this problem has to do with some specifics of the … [View More]

2 1

Welcome Chunlin to the NumPy development team.
by Charles R Harris Jan. 9, 2021

Jan. 9, 2021

Hi All, Welcome Chunlin Fang, aka Qiyu8, to the NumPy development team. He has made substantial contributions to the SIMD infrastructure, both code and reviews, and we look forward to his continuing work. Chuck

3 2

Sayed Adel has joined the developer team.
by Charles R Harris Jan. 9, 2021

Jan. 9, 2021

Hi All, Sayed Adel is now part of the developer team. His SIMD work has been substantial and ongoing, may it long continue. Welcome Sayed. Chuck

4 3

NEP 43 – How should ufunc (inner loops) be designed?
by Sebastian Berg Jan. 7, 2021

Jan. 7, 2021

Hi all, I would like to nudge a discuss on NEP 43. Right now, mainly the first part: That is everything up to "Promotion and dispatching". (This is because promotion and dispatching should be the last bigger step in refactoring NumPy.) The full text is at: https://numpy.org/neps/nep-0043-extensible-ufuncs.html which includes more information and gives some background to help understand what is going on. I personally believe that the `ArrayMethod` concept is pretty much necessary to group … [View More]dtype resolution with the loop functionality (and other things currently handled by the `ufunc` which may be specific to the dtypes involved, e.g. the `identity` could go here). But how exactly it should look like and especially how we want the inner-loop signature to be defined is flexible. So comments on all parts of the NEP are very welcome! My main focus would be on the `strided_inner_loop`. That is largely a continuation of this old, but pretty insightful discussion: https://github.com/numpy/numpy/issues/12518 My current proposal (C-API) is this: def strided_inner_loop( context, data, dimensions, strides, innerloop_data): return 0 # or -1 on error Where `context` is a structure holding some useful information: * The `ArrayMethod` itself (pretty much the `self`) * the dtypes/descriptors of all arrays * the original caller/ufunc (if applicable, useful for backcompat and error messages) * anything else that may come up in the future and should be passed here (e.g. the Python interpreter state). * (Possibly gufunc signature unless we duplicate it on the ArrayMethod.) Context may seem a bit weird, but passing dtypes is very convenient e.g. for strings, passing `self`, the ArrayMethod (so to speak) may also be necessary (e.g. for Python wrapping). And a struct means we could expand it in the future, with some care [1]. Admittedly, numeric ufuncs can simply ignore this completely. `data, dimensions, strides` is the main part of the existing signature. `innerloop_data` is a user allocated/defined struct that is passed in (and has its own "free" slot). We currently use this for casting in NumPy (so it does not need to be public right away, `context` should be good enough for most things). In the NEP I am considering that to pass `npy_intp *scratch_var = 0` when this is unused. That would allow persistent flags (e.g. whether a warning was already given), which otherwise would require a lot of additional complexity. How this `innerloop_data` should look like is maybe the thing I am least sold on myself. The current proposal just keeps around what is already there as private API. There are many more issues and potential future additions and I am happy to discuss those as well. I am singling out the signature a bit, because it seems particularly central and painful to change again in the future. Another example is how the signature of `get_loop()` should look like, since it would be nice to eventually make it public (or even allow overriding it) [2]. That is lower priority though, since we could get away with keeping it private API for a while. Cheers, Sebastian [1] That may need some thought: If others provide the struct (and not just consume it like a ufunc/dtype author), they would need to ensure ABI compatibility with NumPy and always "catch up" when NumPy extends the struct. I expect that can be managed, but I have not planned on how do achieve it. The thought is that e.g. sparse arrays could use the NumPy ArrayMethod/loops directly, and then they would have to provide the struct. (Those projects probably can easily catch up, but you would need to ensure a good error when a NumPy version happens to be too new and is thus incompatible.) [2] The things I am worried about there are: * How we do alignment, largest power-of-two alignment would seem nice, but that is really per-operand: https://github.com/numpy/numpy/issues/17359 * The `move_references` is probably useful flag for buffering of data that contains Python objects/references (it is used because the buffer can be cleared out immediately). For now we can say that this is only relevant for NumPy itself. But the mechanism itself does probably make sense in the context of buffered loops (i.e. casting) – I am honestly not certain that it is actually worth much in performance/memory to clear out buffers in one go. [View Less]

1 0

ANN: pvlib-0.8.1 released
by Dr. Mark Alexander Mikofski PhD Jan. 5, 2021

Jan. 5, 2021

Dear Pythonistas and solar power enthusiasts, On behalf of the maintainers, we're happy to announce a new release of pvlib python: software for simulating performance of photovoltaic solar energy systems. *See what's new for v0.8.1:* * https://pvlib-python.readthedocs.io/en/stable/whatsnew.html *Releases are available from PyPI and the conda-forge channel:* * https://pypi.org/project/pvlib/ * https://anaconda.org/conda-forge/pvlib-python *Read the Documentation:* * https://pvlib-python.… [View More]

1 0

NumPy Community Meeting Wednesday
by Sebastian Berg Jan. 5, 2021

Jan. 5, 2021

Hi all, There will be a NumPy Community meeting Wednesday January 6th at 12pm 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 1.19.5 released
by Charles R Harris Jan. 5, 2021

Jan. 5, 2021

Hi All, On behalf of the NumPy team I am pleased to announce the release of NumPy 1.19.5. NumPy 1.19.5 is a short bugfix release. Apart from fixing several bugs, the main improvement is an update to OpenBLAS 0.3.13 that works around the Windows 2004 fmod bug while not breaking execution on other platforms. This release supports Python 3.6-3.9 and is planned to be the last release in the 1.19.x cycle. NumPy Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.19.5/>, … [View More]

1 0

Speedups for intersect1d in numpy.lib
by Stamm, Felix Jan. 4, 2021

Jan. 4, 2021

Hello mailing list, I would like to open a PR that improves the speed of intersect1d in particular for large arrays of potentially unequal sizes. As parts of the change would involve a new keyword I think I should write to this mailing list first (correct me if I am wrong). Lets start with the current implementation of intersect1d. The steps are (roughly): I) concatenate both arrays II) sort that large array and III) keep only duplicates. This is a simple but not necessary fast … [View More]

1 0

proposal for NumPy sponsorship guidelines (NEP 46)
by Ralf Gommers Jan. 3, 2021

Jan. 3, 2021

Hi all, I just opened https://github.com/numpy/numpy/pull/18084, "NumPy Sponsorship Guidelines". Below are the most important parts for review (for Related Work, References, etc. see the PR). Please bring up broader points here, and small/textual feedback on the PR. Cheers, Ralf Abstract -------- This NEP provides guidelines on how the NumPy project will acknowledge financial and in-kind support. Motivation and Scope -------------------- In the past few years the NumPy project has … [View More]gotten significant financial support, as well as dedicated work time for maintainers to work on NumPy. There is a need to acknowledge that support - funders and organizations expect or require it, it's helpful when looking for new funding, and it's the right thing to do. Furthermore, having a clear policy for how NumPy acknowledges support is helpful when searching for new support. This NEP is aimed at both the NumPy community - who can use it when looking for support and acknowledging existing support - and at past, current and prospective sponsors, who often want or need to know what they get in return for their support (other than a healthier NumPy). The scope of this proposal includes: - direct financial support, employers providing paid time for NumPy maintainers and regular contributors, and in-kind support such as free hardware resources or services. - where and how NumPy acknowledges support (e.g., logo placement on the website). - the amount and duration of support which leads to acknowledgement. - who in the NumPy project is responsible for sponsorship related topics, and how to contact them. How NumPy will acknowledge support ---------------------------------- There will be two different ways to acknowledge financial and in-kind support, one to recognize significant active support, and another one to recognize support received in the past and smaller amounts of support. Entities who fall under "significant active supporter" we'll call Sponsor. The minimum level of support given to NumPy to be considered a Sponsor are: - $30,000/yr for unrestricted financial contributions - $60,000/yr for financial contributions for a particular purpose - $100,000/yr for in-kind contributions The rationale for the above levels is that unrestricted financial contributions are typically the most valuable for the project, and the hardest to obtain. The opposite is true for in-kind contributions. The dollar value of the levels also reflect that NumPy's needs have grown to the point where we need at least a few paid developers in order to effectively support our user base and continue to move the project forward. Financial support at or above these levels is needed to be able to make a significant difference. Sponsors will get acknowledged through: - a small logo displayed on the front page of the NumPy website - prominent logo placement on https://numpy.org/about/ - logos displayed in talks about NumPy by maintainers - announcements of the sponsorship on the NumPy mailing list and the numpy-team Twitter account In addition to Sponsors, we already have the concept of Institutional Partner (defined in NumPy's `governance document <https://numpy.org/devdocs/dev/governance/index.html >`__), for entities who employ a NumPy maintainer and let them work on NumPy as part of their official duties. The governance document doesn't currently define a minimum amount of paid maintainer time needed to be considered for partnership. Therefore we propose that level here, roughly in line with the sponsorship levels: - 6 person-months/yr of paid work time for one or more NumPy maintainers or regular contributors Institutional Partners get the same benefits as Sponsors, in addition to what is specified in the NumPy governance document. Finally, a new page on the website (https://numpy.org/funding/, linked from the About page) will be added to acknowledge all current and previous sponsors, partners, and any other entities and individuals who provided $5,000 or more of financial or in-kind support. This page will include relevant details of support (dates, amounts, names and purpose); no logos will be used on this page. The rationale for the $5,000 minimum level is to keep the amount of work maintaining the page reasonable; the level is the equivalent of, e.g., one GSoC or a person-week's worth of engineering time in a Western country, which seems like a reasonable lower limit. Implementation -------------- The following content changes need to be made: - Add a section with small logos towards the bottom of the `numpy.org <https://numpy.org/>`__ website. - Create a full list of historical and current support and deploy it to https://numpy.org/funding. - Update the NumPy governance document for changes to Institutional Partner eligibility requirements and benefits. - Update https://numpy.org/about with details on how to get in touch with the NumPy project about sponsorship related matters (see next section). A NumPy Funding Team ~~~~~~~~~~~~~~~~~~~~ At the moment NumPy has only one official body, the Steering Council, and no good way to get in touch with either that body or any person or group responsible for funding and sponsorship related matters. The way this is typically done now is to somehow find the personal email of a maintainer, and email them in private. There is a need to organize this more transparently - a potential sponsor isn't likely to inquire through the mailing list, nor is it easy for a potential sponsor to know if they're reaching out to the right person in private. https://numpy.org/about/ already says that NumPy has a "funding and grants" team, however that is not the case. We propose to organize this team, name team members on it, and add the names of those team members plus a dedicated email address for the team to the About page. Status before this proposal --------------------------- Acknowledgement of support ~~~~~~~~~~~~~~~~~~~~~~~~~~ At the time of writing (Dec 2020), the logos of the four largest financial sponsors and two institutional partners are displayed on https://numpy.org/about/. The `Nature paper about NumPy < https://www.nature.com/articles/s41586-020-2649-2>`__ mentions some early funding. No comprehensive list of received funding and in-kind support is published anywhere. Decisions on which logos to list on the website have been made mostly by the website team. Decisions on which entities to recognize as Institutional Partner have been made by the NumPy Steering Council. NumPy governance, decision-making and financial oversight ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *This section is meant as context for the reader, to help put the rest of this NEP in perspective, and perhaps answer questions the reader has when reading this as a potential sponsor.* NumPy has a formal governance structure defined in `this governance document < https://numpy.org/devdocs/dev/governance/index.html>`__). Decisions are made by consensus among all active participants in a discussion (typically on the mailing list), and if consensus cannot be reached then the Steering Council takes the decision (also by consensus). NumPy is a sponsored project of NumFOCUS, a US-based 501(c)3 nonprofit. NumFOCUS administers NumPy funds, and ensures they are spent in accordance with its mission and nonprofit status. In practice, NumPy has a NumFOCUS subcommittee (with its members named in the NumPy governance document) who can authorize financial transactions. Those transactions, for example paying a contractor for a particular activity or deliverable, are decided on by the NumPy Steering Council. Alternatives ------------ *Tiered sponsorship levels.* We considered using tiered sponsorship levels, and rejected this alternative because it would be more complex, and not necessarily communicate the right intent - the minimum levels are for us to determine how to acknowledge support that we receive, not a commercial value proposition. Entities typically will support NumPy because they rely on the project or want to help advance it, and not to get brand awareness through logo placement. *Listing all donations*. Note that in the past we have received many smaller donations, mostly from individuals through NumFOCUS. It would be great to list all of those contributions, but given the way we receive information on those donations right now, that would be quite labor-intensive. If we manage to move to a more suitable platform, such as `Open Collective < https://opencollective.com/>`__, in the future, we should reconsider listing all individual donations. [View Less]

2 2