Mailman 3 May 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 do I avoid these messages to appear? I know that I could in principle use numpy.seterr. However, I do NOT want to remove these warnings for other potential divide/multiply/sqrt etc errors. Only when I am using a "where", to in fact avoid such warnings! Note that the warnings only happen once, but since I am going to release that code, I would like to avoid the user to get such messages which are irrelevant here (because I am testing, with the where, when NOT to divide by zero or take a sqrt of a negative number). thanks! Eric

5 4

Documentation Team meeting - Monday June 8th
by Melissa Mendonça 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 can click this link to get the correct time at your timezone: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Documentati… - Melissa

6 74

[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. np.expand_dims -> tf.expand_dims. This is done either in debugging (e.g. converting tf to np without eager execution to debug portion of the code), or during prototyping, e.g. develop in numpy and convert in tf. I find myself more than at one occasion to getting syntax errors because of this particular function np.concatenate. It is unnecessarily long. I imagine there are more people that also run into the same problems. Pandas uses concat (torch on the other extreme uses simply cat, which I don't think is as descriptive).

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 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

10 10

Add smallest_normal and smallest_subnormal attributes to finfo
by Stephannie Jiménez Gacha July 19, 2021

July 19, 2021

Good afternoon, Given the discussions happened in the Data API consortium when looking into the attributes of `finfo` used in the wild, we found that `tiny` is used regularly but in a good amount of cases not for its intended purpose but rather as "just give me a small number". Following this we are proposing the addition of `smallest_normal` and `smallest_subnormal` attributes. Personally, I think that the `tiny` name is a little bit odd and misleading, so it will be great to leave that as an alias but have a clear name in this class. Right now the PR: https://github.com/numpy/numpy/pull/18536 has all the changes and all the values added were checked against IEEE-754 standard. One of the main concerns is the support of subnormal numbers in certain architectures, where the values can't be calculated accurately. Given the state of the discussion, we don't know if the best alternative is to not add the `smallest_subnormal` attribute and just add the `smallest_number` attribute as an alias to `tiny`. We open this to discussion to see what way we can go in order to get this PR merged. *Stephannie Jimenez Gacha*Software developer *Quansight* | Your Data Experts w: www.quansight.com e: sgacha(a)quansight.com <https://www.linkedin.com/company/quansight> <https://twitter.com/quansightai>

2 1

Proposal to accept NEP 49: Data allocation strategies
by Matti Picus July 18, 2021

July 18, 2021

Here is the current rendering of the NEP:https://numpy.org/neps/nep-0049.html The mailing list discussion, started on April 20 did not bring up any objections to the proposal, nor were there objections in the discussion around the text of the NEP. There were questions around details of the implementation, thank you reviewers for carefully looking at them and suggesting improvements. If there are no substantive objections within 7 days from this email, then the NEP will be accepted; see NEP 0 for more details. Matti

5 13

EHN: Discusions about 'add numpy.topk'
by kangkai＠mail.ustc.edu.cn May 31, 2021

May 31, 2021

Hi all, Finding topk elements is widely used in several fields, but missed in NumPy. I implement this functionality named as numpy.topk using core numpy functions and open a PR: https://github.com/numpy/numpy/pull/19117 Any discussion are welcome. Best wishes, Kang Kai

11 16

NumPy Community Meeting Wednesday
by Sebastian Berg May 25, 2021

May 25, 2021

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

The status of DType Refactor
by Sebastian Berg May 24, 2021

May 24, 2021

Hi all, I thought I would give a brief update on where we are with new DTypes. Partially for Matti who is braving the brunt of the review, but also for anyone else interested. Please don't hesitate to ask for clarifications, any questions, or to schedule a meeting to discuss! Recap The past year, has seen most of the "big picture" changes merged into NumPy, a good chunk already part of 1.20: * dtype instances are not instances of np.dtype subclasses. I usually write DType for those. But DTypeType is also a good name :). * Array coercion using np.array(...) was completely rewritten, which was necessary to allow new user DTypes. * Introduced the ArrayMethod concept to unif casting and ufuncs as much as possible (NEP 42/43):Casting was first fixed up to support error returns."can-cast" logic was rewritten in terms of ArrayMethod (i.e. casting safety checks are integrated into Arraymethod)Casting largely reorganized around the ArrayMethod concept, including the casting safety. (Also this) * Promotion was implemented and later integrated everywhere, e.g. for np.result_type(...). * A larger refactor of UFuncs and a few smaller PRs set the stage for the ufunc refactor (see currently in progress) With the exception of universal functions, the above list covers all major areas of change in NumPy that are required to change. It also implements many of the things that new user DTypes will need and currently cannot do. Previously, these were either unavailable or limited in various ways; especially when it comes to parametric DTypes such as units or strings. Currently in Progress The current main reamining points are the universal functions. Since, a majority of NumPy features are organized as universal functions, and universal functions inheritently did not support parametric user defined DTypes. These need a major change. This change is proposed in NEP 43 (although that will need some smaller updates). The work on implemeting it, is mostly settling in the following PR and the following branch (I hope these will move in very soon): * PR 18905: Implements new promotion, dispatching and use for most ufuncs. * My developement branch extends this to the reductions. In parallel, the new DType API is only useful for users once it is exposed, I have a branch here to experiment with that: * The expermental DType API exposure branch. * And a repository with (currently cython) examples using it. This currently includes a very simplicitic Units DType and ufuncs for strings (previous difficult or not really possible). The exact way to write a new DType probably needs some alternative. But note that this should largely be limited to the boilerplate code. Future The main step still remaining is figuring out how to exactly expose the DType API best (ABI compatibility is the major concern) and finishing the NEP 43 (or most of it) as closing up. After that there are still some things that need to be done (although, this is unlikely to be exhaustive): * The way users should define new DTypes has to be decided (this seems tricky, unfortunately). * Some functionality is defined in the "old style" API that should be removed/discouraged. This includes things like sorting functions. (The old way could be allowed for a transition period.) To be specific, these are the ((PyArray_Descr *)descr)->f->funcs. * Some small parts of the new API are missing right now. E.g. ensure_nbo() in current NumPy code, has to use the ensure_canonical() as defined by NEP 42. Similarly, some parts will need tweaking. * Part of the API should be public, but it would also be nice to clean them up before doing so; An example for this is the get_loop() for/of ufuncs. For most use-cases, this is probably not too important, but the API is a bit awkward currently. (It would be possible to accept the awkward API and replace it in the future with a new get_loop(), deprecating the old one slowly) * There should be some new API for "reference counting" (more generally, any item with memory management). Cleaning up the split between the current transfer to NULL and PyArray_XDECREF. That is, we should unify it as much as possible (probably by using the transfer to NULL path). And then expose that also to custom DTypes. * Some utility functionality is missing at this time. For example a way for a Unit DType to fall back to the normal math implemented by NumPy (after figuring out the unit part). * A Python API is not on my explicit roadmap right now (although probably not hard). But most importantly, whatever comes up when potential users start exploring the API, hopefully soon! Otherwise, there are a couple of related improvements, that I think would make sense. Such as considering storing the actual power-of-two alignment in the array flags (they are getting a bit cramped if we assume int can be 16 bits though). Also the discussion about removing value based casting/promotion is one that would help with DTypes and pushing it forward probably makes sense as soon as the items that are "currently in progress" are largely settled and the next NumPy version is released. Cheers, Sebastian

1 0

Understanding Our Contributors - NumFOCUS survey
by Melissa Mendonça May 24, 2021

May 24, 2021

Hi all, NumPy is participating in a research project being conducted by NumFOCUS <https://numfocus.org/>, our fiscal sponsorship organization. The research is looking into understanding the diversity, inclusion and barriers to participation within NumFOCUS-sponsored projects and the wider open source community. The survey <https://numfocus.typeform.com/to/W6Bax8eq> will take 15-20 min to complete. We’d appreciate your contribution by May 31, 2021. The results of this survey will help NumFOCUS work closely with our projects to develop practices that will lead to project success around diversity, inclusion and sustainability. Click here to participate in the survey <https://numfocus.typeform.com/to/W6Bax8eq> Thank you for your participation! - Melissa

1 0

NumPy 1.21.0rc1 has been released.
by Charles R Harris May 24, 2021

May 24, 2021

Hi All, On behalf of the NumPy team I am pleased to announce the release of NumPy 1.21.0rc1. The highlights are - continued SIMD work covering more functions and platforms, - initial work on the new dtype infrastructure and casting, - improved documentation, - improved annotations, - the new ``PCG64DXSM`` bitgenerator for random numbers. This NumPy release is the result of 561 merged pull requests contributed by 171 people. The Python versions supported for this release are 3.7-3.9, support for Python 3.10 will be added after Python 3.10 is released. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.21.0rc1/>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v1.21.0rc1>. Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. *Contributors* A total of 171 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - @8bitmp3 + - @DWesl + - @Endolith - @Illviljan + - @Lbogula + - @Lisa + - @Patrick + - @Scian + - @h-vetinari + - @h6197627 + - @jbCodeHub + - @legoffant + - @sfolje0 + - @tautaus + - @yetanothercheer + - Abhay Raghuvanshi + - Adrian Price-Whelan + - Aerik Pawson + - Agbonze Osazuwa + - Aitik Gupta + - Al-Baraa El-Hag - Alex Henrie - Alexander Hunt + - Alizé Papp + - Allan Haldane - Amarnath1904 + - Amrit Krishnan + - Andras Deak - AngelGris + - Anne Archibald - Anthony Vo + - Antony Lee - Atharva-Vidwans + - Ayush Verma + - Bas van Beek - Bharat Raghunathan - Bhargav V + - Brian Soto - Carl Michal + - Charles Harris - Charles Stern + - Chiara Marmo + - Chris Barnes + - Chris Vavaliaris - Christina Hedges + - Christoph Gohlke - Christopher Dahlin + - Christos Efstathiou + - Chunlin Fang - Constanza Fierro + - Daniel Evans + - Daniel Montes + - Dario Mory + - David Carlier + - David Stansby - Deepyaman Datta + - Derek Homeier - Dong Keun Oh + - Dylan Cutler + - Eric Larson - Eric Wieser - Eva Jau + - Evgeni Burovski - FX Coudert + - Faris A Chugthai + - Filip Ter + - Filip Trojan + - François Le Lay + - Ganesh Kathiresan - Giannis Zapantis + - Giulio Procopio + - Greg Lucas + - Hollow Man + - Holly Corbett + - Inessa Pawson - Isabela Presedo-Floyd - Ismael Jimenez + - Isuru Fernando - Jakob Jakobson - James Gerity + - Jamie Macey + - Jasmin Classen + - Jody Klymak + - Joseph Fox-Rabinovitz - Jérome Eertmans + - Kamil Choudhury + - Kasia Leszek + - Keller Meier + - Kevin Sheppard - Kulin Seth + - Kumud Lakara + - Laura Kopf + - Laura Martens + - Leo Singer + - Leonardus Chen + - Lima Tango + - Lumir Balhar + - Maia Kaplan + - Mainak Debnath + - Marco Aurélio da Costa + - Marta Lemanczyk + - Marten van Kerkwijk - Mary Conley + - Marysia Winkels + - Mateusz Sokół + - Matt Haberland - Matt Hall + - Matt Ord + - Matthew Badin + - Matthias Bussonnier - Matthias Geier - Matti Picus - Matías Ríos + - Maxim Belkin + - Melissa Weber Mendonça - Meltem Eren Copur + - Michael Dubravski + - Michael Lamparski - Michal W. Tarnowski + - Michał Górny + - Mike Boyle + - Mike Toews - Misal Raj + - Mitchell Faas + - Mukulikaa Parhari + - Neil Girdhar + - Nicholas McKibben + - Nico Schlömer - Nicolas Hug + - Nilo Kruchelski + - Nirjas Jakilim + - Ohad Ravid + - Olivier Grisel - Pamphile ROY + - Panos Mavrogiorgos + - Patrick T. Komiske III + - Pearu Peterson - Raghuveer Devulapalli - Ralf Gommers - Raúl Montón Pinillos + - Rin Arakaki + - Robert Kern - Rohit Sanjay - Roman Yurchak - Ronan Lamy - Ross Barnowski - Ryan C Cooper - Ryan Polley + - Ryan Soklaski - Sabrina Simao + - Sayed Adel - Sebastian Berg - Shen Zhou + - Stefan van der Walt - Sylwester Arabas + - Takanori Hirano - Tania Allard + - Thomas J. Fan + - Thomas Orgis + - Tim Hoffmann - Tomoki, Karatsu + - Tong Zou + - Touqir Sajed + - Tyler Reddy - Wansoo Kim - Warren Weckesser - Weh Andreas + - Yang Hau - Yashasvi Misra + - Zolboo Erdenebaatar + - Zolisa Bleki Cheers, Charles Harris

1 0

Indexing question
by Neal Becker May 20, 2021

May 20, 2021

This seems like something that can be done with indexing, but I haven't found the solution. out is a 2D array is initialized to zeros. x is a 1D array whose values correspond to the columns of out. For each row in out, set out[row,x[row]] = 1. Here is working code: def orthogonal_mod (x, nbits): out = np.zeros ((len(x), 1<<nbits), dtype=complex) for e in range (len (x)): out[e,x[e]] = 1 return out Any idea to do this without an explicit python loop? -- Those who don't understand recursion are doomed to repeat it

4 5

interval wrapping / remainder / angle normalization
by Thomas Hilger May 20, 2021

May 20, 2021

Hi everyone! I was wondering if it is a possible addition to numpy to have a function to wrap values to an interval. Typically, it is desired to limit an angle to [0, 2pi) or [-pi ,pi), either by letting it "overflow" or by "bouncing" hence and forth. The function which does this is actually really simple. However, whenever I am facing this task I tend to work a while on this until I get it correct. I have a small and handy function (it is small because it just uses np.divmod) at hand which does this, including also the left-open or closed cases, and some tests. In case this is of interest, I can contribute. Best regards, Thomas.

2 2

NumPy Development Meeting Wednesday - Triage Focus
by Sebastian Berg May 18, 2021

May 18, 2021

Hi all, Our bi-weekly triage-focused NumPy development meeting is Wednesday, May 19th 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, discussed, or reviewed. Best regards Sebastian

1 0

Deprecate four `ndarray.ctypes` implementation artifacts
by bas van beek May 18, 2021

May 18, 2021

Hi all, The `ndarray.ctypes` object currently contains four (undocumented) methods that are essentially leftover implementation artifacts, kept around for the sake of backwards compatibility. As this was three years ago it is, in my opinion, a suitable time now to properly deprecate them, my question being if anyone would have objections to this. The methods in question are: * `get_data` (use the `data` property instead) * `get_shape` (use the `shape` property instead) * `get_strides` (use the `ctypes.strides` property instead) * `get_as_parameter` (use the `_as_parameter_` property instead) For those interested, a PR implementing their deprecation is currently up at https://github.com/numpy/numpy/pull/19031 Regards, Bas van Beek

1 0

linalg.det for fractions
by Shashwat Jaiswal May 16, 2021

May 16, 2021

How about having linalg.det returning a fraction object when passed a numpy matrix of fractions?

3 2

Re: [Numpy-discussion] Google Season of Docs
by Mukulika Pahari May 15, 2021

May 15, 2021

Thank you so much for this opportunity! I am so excited to get started with this project. I really appreciate all the help and encouragement from the community. It is going to be so much fun to work with you all! Cheers, Mukulika On Sat, May 15, 2021 at 2:18 AM <numpy-discussion-request(a)python.org> wrote: > Send NumPy-Discussion mailing list submissions to > numpy-discussion(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/numpy-discussion > or, via email, send a message with subject or body 'help' to > numpy-discussion-request(a)python.org > > You can reach the person managing the list at > numpy-discussion-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NumPy-Discussion digest..." > > > Today's Topics: > > 1. Google Season of Docs (Melissa Mendon?a) > 2. Re: Google Season of Docs (Stefan van der Walt) > 3. Re: Google Season of Docs (Ralf Gommers) > 4. Re: bad CRC errors when using np.savez, only sometimes > though! (Isaac Gerg) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 14 May 2021 15:41:56 -0300 > From: Melissa Mendon?a <melissawm(a)gmail.com> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Subject: [Numpy-discussion] Google Season of Docs > Message-ID: > < > CAC7J6VZZVKLuhC14F1emvo1Vh40y+QhXfEYL8whxk9-BPiNp0Q(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello, all! > > I am happy to announce we found our technical writer for the Google Season > of Docs program. After looking at all submitted proposals we have decided > to hire Mukulika. You can see her Statement of Interest here: > https://mail.python.org/pipermail/numpy-discussion/2021-May/081746.html > > We are very glad to participate again this year and sincerely thank all the > technical writers who took an interest in our project and that contacted us > about it. If you want to keep contributing to NumPy, you are all most > welcome! > > Mukulika has already started doing some contributions to NumPy and we wish > her a successful project. Me and Ross will be the mentors for this proposal > but the community is also encouraged to participate with suggestions and > comments. You can check out the timeline and more details about GSoD here: > https://developers.google.com/season-of-docs/docs/timeline > > Cheers, > > Melissa >

1 0

bad CRC errors when using np.savez, only sometimes though!
by Isaac Gerg May 14, 2021

May 14, 2021

I am using 1.19.5 on Windows 10 using Python 3.8.6 (tags/v3.8.6:db45529, Sep 23 2020, 15:52:53) [MSC v.1927 64 bit (AMD64)]. I have two python processes running (i.e. no threads) which do independent processing jobs and NOT writing to the same directories. Each process runs for 5-10 hours and then writes out a ~900MB npz file containing 4 arrays. When I go back to read in the npz files, I will sporadically get bad CRC errors which are related to npz using ziplib. I cannot figure out why this is happening. Looking through online forums, other folks have had CRC problems but they seem to be isolated to specifically using ziblib, not numpy. I have found a few mentions though of ziplib causing headaches if the same file pointer is used across calls when one uses the file handle interface to ziblib as opposed to passing in a filename.' I have verified with 7zip that the files do in fact have a CRC error so its not an artifact of the ziblib. I have also used the file handle interface to np.load and still get the error. Aside from writing my own numpy storage file container, I am stumped as to how to fix this, or reproduce this in a consistent manner. Any suggestions would be greatly appreciated! Thank you, Isaac

3 5

Google Season of Docs
by Melissa Mendonça May 14, 2021

May 14, 2021

Hello, all! I am happy to announce we found our technical writer for the Google Season of Docs program. After looking at all submitted proposals we have decided to hire Mukulika. You can see her Statement of Interest here: https://mail.python.org/pipermail/numpy-discussion/2021-May/081746.html We are very glad to participate again this year and sincerely thank all the technical writers who took an interest in our project and that contacted us about it. If you want to keep contributing to NumPy, you are all most welcome! Mukulika has already started doing some contributions to NumPy and we wish her a successful project. Me and Ross will be the mentors for this proposal but the community is also encouraged to participate with suggestions and comments. You can check out the timeline and more details about GSoD here: https://developers.google.com/season-of-docs/docs/timeline Cheers, Melissa

3 2

Re: [Numpy-discussion] bad CRC errors when using np.savez, only sometimes though!
by Stefano Miccoli May 14, 2021

May 14, 2021

If changing the on-disk format is an option, I would suggest h5py <https://docs.h5py.org/en/stable/> which allows to save numpy arrays in HDF5 format. Stefano On 14 May 2021, at 16:22, numpy-discussion-request(a)python.org<mailto:numpy-discussion-request@python.org> wrote: Aside from writing my own numpy storage file container, I am stumped as to how to fix this, or reproduce this in a consistent manner. Any suggestions would be greatly appreciated! Thank you, Isaac

1 0

GSOD 2021
by 1DS19IS109_Sujal May 13, 2021

May 13, 2021

Can I still apply for GSOD'21?

2 1

NumPy Community Meeting Wednesday
by Sebastian Berg May 11, 2021

May 11, 2021

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

NEP 42 status
by Lee Johnston May 11, 2021

May 11, 2021

Is the work on NEP 42 custom DTypes far enough along to experiment with? Lee

2 6

NumPy 1.20.3 release
by Charles R Harris May 10, 2021

May 10, 2021

Hi All, On behalf of the NumPy team I am pleased to announce the release of NumPy 1.20.3. NumPy 1,20.3 is a bugfix release containing several fixes merged to the main branch after the NumPy 1.20.2 release. The Python versions supported for this release are 3.7-3.9. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.20.3/>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v1.20.3>. Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. *Contributors* A total of 7 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Anne Archibald - Bas van Beek - Charles Harris - Dong Keun Oh + - Kamil Choudhury + - Sayed Adel - Sebastian Berg *Pull requests merged* A total of 15 pull requests were merged for this release. - #18763: BUG: Correct ``datetime64`` missing type overload for ``datetime.date``... - #18764: MAINT: Remove ``__all__`` in favor of explicit re-exports - #18768: BLD: Strip extra newline when dumping gfortran version on MacOS - #18769: BUG: fix segfault in object/longdouble operations - #18794: MAINT: Use towncrier build explicitly - #18887: MAINT: Relax certain integer-type constraints - #18915: MAINT: Remove unsafe unions and ABCs from return-annotations - #18921: MAINT: Allow more recursion depth for scalar tests. - #18922: BUG: Initialize the full nditer buffer in case of error - #18923: BLD: remove unnecessary flag ``-faltivec`` on macOS - #18924: MAINT, CI: treats _SIMD module build warnings as errors through... - #18925: BUG: for MINGW, threads.h existence test requires GLIBC > 2.12 - #18941: BUG: Make changelog recognize gh- as a PR number prefix. - #18948: REL, DOC: Prepare for the NumPy 1.20.3 release. - #18953: BUG: Fix failing mypy test in 1.20.x. Cheers, Charles Harris

1 0

GSoD 2021 - Statement of Interest
by Mahesh S May 10, 2021

May 10, 2021

Hello, I am Mahesh from India. I am interested in doing Google Season of Docs with NumPy on the project HIGH-LEVEL RESTRUCTURING AND END-USER FOCUS - NumPy I have past experience in documentation writing with WordPress and have completed *Google Summer of Code 2018 *with KDE. I have been an open source enthusiast and contributor since 2017.My past experience with coding ,code documentation , understanding code bases ,will help achieve this task without much input from your end. I have about four years experience working with Open-Source and currently working as a *Quality Assurance specialis*t . I have delivered technical talks at international conferences (KDE-Akademy) and was *mentor of Google Code-In* also. All these makes me the best candidate for the project. I am attaching a brief proposal for the work along with this mail. A more in-depth A more in depth proposal with timelines , all planned strategies , document structures will be submitted after more discussion with the mentors and community. I am ready to start the work as soon as possible and will be able work 7 to 9 hours per day including weekends. I strongly wish to be part of the NumPy community even after the project. Hope to hear from you soon -- Thank you Mahesh S Nair

2 7

GSoD'21- Submitting first draft of the Statement of Interest.
by Ayush Verma May 10, 2021

May 10, 2021

Hello everyone, I have attached my Statement of Interest for GSoD'21 below. I will also be adding a couple more links to the statement within a day or two. Till then, I would love to get reviews from the community on the proposed changes. Cheers. Ayush.

2 2

Open for contribution
by Anthony Le Goff May 7, 2021

May 7, 2021

Hi, I'm Anthony from Brest, Brittany, France. I've done my first PR for a documentation fix, and i'm still learning the workflow of github. I'm looking for to participate a open source project, i'm also a free software enthousiast. I discovered numpy while I try to find a solution in engineering computational science for hobbyist to replace MATLAB where i'm against the politic of licensing. I have a degree in mechanical & design engineering and i'm a self-taugh programmer. I'm still learning python and i know the language C. I get some knowledge in system administration in linux. I hope i can help to contribute on the code or the documentation. I never try to change a piece of code in a project, it would be my first time. I'm little bit confuse to do something wrong with a shitty code and broke something. I thing it is normal just try. My next step after python is learning data structure and algorithm then design pattern. I large program and i do that alone on my free time. I'm looking for a full time jobs also. I've seen numpy library is also coded in C. It's a good point to my knowledge. I was looking for some "first issue" but i'm not sure it's easy with 27 comments after 5 years on some issues. I'm open for large project to get experience in programming. Regards Anthony Le Goff

1 0

Accept NEP 35 as final
by Charles R Harris May 6, 2021

May 6, 2021

Hi All, It is proposed to accept NEP 35 <https://github.com/numpy/numpy/blob/main/doc/neps/nep-0035-array-creation-d…> as final. It is discussed in issue #17075 <https://github.com/numpy/numpy/issues/17075>. If there is no opposition I will put up a pull request in a week. Chuck

1 0

Newcomer's Hour!
by Melissa Mendonça May 6, 2021

May 6, 2021

Hello, folks! I've added a new event to the NumPy community calendar: the Newcomer's Hour. This is an event we've been running for a few months and is a bi-weekly informal meeting for newcomers to the NumPy community. This is a place to ask questions, technical or otherwise, meet other contributors, and (hopefully) figure out how to contribute :) We are having one today at 8pm UTC - here's the zoom link: https://zoom.us/j/6345425936. To follow all the events and meetings related to NumPy and add them to your own Google calendar, you can use this link: https://calendar.google.com/calendar/r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMy… Cheers! Melissa

1 0

NumPy Development Meeting Wednesday - Triage Focus
by Sebastian Berg May 5, 2021

May 5, 2021

Hi all, Our bi-weekly triage-focused NumPy development meeting is Wednesday, May 5th 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, discussed, or reviewed. Best regards Sebastian

1 0

NumPy Proposal
by KiranKhanna May 4, 2021

May 4, 2021

2 2

Prospective technical writer for GSoD 2021 under NumPy
by Ronnie Gandhi May 4, 2021

May 4, 2021

Hello, I am Ronnie Gandhi, a Computer Science undergrad from IIT Roorkee in my final year.I am interested in working on NumPy's documentation problem statement "HIGH-LEVEL RESTRUCTURING AND END-USER FOCUS - NumPy". I have successfully completed *GSoD2020 <https://developers.google.com/season-of-docs/docs/2020/participants/project…>*(my display name is Krezhairo) under *LibreOffice*, I have done* GSoC 2019*, and *2020 *under CGAL, and I have been contributing to open-source development for quite a while. I have also done Data Science internships at *Microsoft*, Hyderabad in 2019 and 2020. I am very well versed with GitHub, git, and CLI tools. Also from my past GSoD2020 experience I know Sphinx, Markdown, reStructuredText, XML as well. In terms of technical writing experience, - Under the Season of Docs 2020 program, I was given an opportunity to populate the wiki pages for the Calc functions of LibreOffice. I updated and populated the wiki pages for 340 of Calc functions in many categories for which the documentation was quite shallow and incomplete on the wiki pages. - For some of the examples of previous technical writing that I have successfully completed in GSoD 2020 under LibreOffice where I edited/populated 340+ sparse wiki pages of Calc functions. Some of the examples are as follows: - https://wiki.documentfoundation.org/Documentation/Calc_Functions/YIELDDISC - https://wiki.documentfoundation.org/Documentation/Calc_Functions/CHIDIST - https://wiki.documentfoundation.org/Documentation/Calc_Functions/SIN - https://wiki.documentfoundation.org/Documentation/Calc_Functions/DAVERAGE - https://wiki.documentfoundation.org/Documentation/Calc_Functions/Guidelines If you want to look into more examples, you can find them here: https://wiki.documentfoundation.org/Documentation/Calc_Functions/List_of_Fu… (this is the new link where the "Find Functions" page is shifted sorry for the blank page) - I have also had created the developer docs as a part of my GSoC2019 and GsoC2020 program updating my progress under CGAL org. (some screenshots to the work since it is behind login wall <https://drive.google.com/drive/folders/1UtuD_6Hu59hJwdzqumSkVyRJeNcDxT5c?us…>)(although no important data) For my c++ experience, - My GSoC2019 <https://summerofcode.withgoogle.com/archive/2019/projects/4989489175330816/> and GSoC2020 <https://summerofcode.withgoogle.com/archive/2020/projects/5667696160538624/> projects were completely in C++ and Qt5 (my display name is Krezhairo). For my python experience, - As a data scientist intern at Microsoft, a large part of my work was in python and jupyter notebook. I have had multiple occasions to use NumPy. My GitHub link: https://github.com/RonnieGandhi I am attaching my detailed resume for your reference. Looking forward to hearing from you soon. Kind regards, Ronnie

2 1

GSoD '21 Statement of Interest
by Mukulika Pahari May 4, 2021

May 4, 2021

Hello everyone, I am attaching my Statement of Interest for GSoD 2021 below. I would love to know everyone's thoughts on it. Thank you!

2 1

Catching array shape errors using the type checker
by Matthew Rahtz May 4, 2021

May 4, 2021

Hi all, Tl;dr: come to our talk *Catching Tensor Shape Errors Using the Type Checker* at the PyCon 2021 Typing Summit next week! https://us.pycon.org/2021/summits/typing/ Longer version: over the past year a small group of us have been thinking about how to use Python's type system to make tensor/array shape information more visible, and to catch shape errors automatically using type checkers. In this talk we'll discuss our tentative solution, talking about a) how it works, b) some examples of what it looks like in practice, and c) what its limitations are. Hope to see you there! Matthew and Pradeep

2 1