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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 1