Mailman 3 June 2020 - NumPy-Discussion

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

18 Feb '23

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 03 Dec '22

03 Dec '22

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 10 May '22

10 May '22

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 22 Jul '21

22 Jul '21

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

Numpy FFT normalization options issue (addition of new option)
by cvav 12 Jul '20

12 Jul '20

Issue #16126: https://github.com/numpy/numpy/issues/16126 PR #16476: https://github.com/numpy/numpy/pull/16476 numpy.fft docs (v1.18): https://numpy.org/doc/1.18/reference/routines.fft.html Hello all, I was advised to write on the numpy mailing list, after this week's community meeting led to some general discussions on the normalization schemes used in the FFT functions. My post has to do with issue #16126, which asks for the addition of a new option for the "norm" argument for the FFT functions; "norm" controls the way the forward (direct) and backward (inverse) transforms are normalized, and the two currently supported options are "norm=None" (default) and "norm=ortho". The "ortho" option uses the orthonormal Fourier basis functions, which translates to both the forward and backward transforms being scaled by 1/sqrt(n), where n is the number of Fourier modes (and data points). The default "None" option scales the forward transform by 1 (unscaled) and the backward by 1/n. The new added option, called for now "norm=inverse", is the exact opposite of the default option; i.e. it scales the forward transform by 1/n and the backward by 1. In terms of using the FFT for spectral methods or approximation problems, these are the three scaling schemes one encounters; the transform itself is the same, with only a constant factor being the difference. But having all three scaling options built in the fft and ifft functions makes the code cleaner and it's easier to stay consistent. I've submitted a PR for this change, and would be happy to get comments and feedback on the implementation and anything else that hasn't been considered. Thanks! Chris -- Sent from: http://numpy-discussion.10968.n7.nabble.com/

10 14

reseed random generator (1.19)
by Neal Becker 04 Jul '20

04 Jul '20

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

5 16

Improving Complex Comparison/Ordering in Numpy
by Rakesh Vasudevan 02 Jul '20

02 Jul '20

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

4 6

NumPy Development Meeting Tomorrow - Triage Focus
by Sebastian Berg 30 Jun '20

30 Jun '20

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

1 0

ANN: SfePy 2020.2
by Robert Cimrman 30 Jun '20

30 Jun '20

I am pleased to announce the release of SfePy 2020.2. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by finite element methods. It is distributed under the new BSD license. Home page: https://sfepy.org Mailing list: https://mail.python.org/mm3/mailman3/lists/sfepy.python.org/ Git (source) repository, issue tracker: https://github.com/sfepy/sfepy Highlights of this release -------------------------- - discontinuous Galerkin method implementation and examples - new website look - memory usage improvements For full release notes see [1]. Cheers, Robert Cimrman [1] http://docs.sfepy.org/doc/release_notes.html#id1 --- Contributors to this release in alphabetical order: Robert Cimrman Jan Heczko Lubos Kejzlar Vladimir Lukes Tomáš Zítka

1 0

Re: [Numpy-discussion] Google Summer of Docs Faq and Tutorial Proposed Structure .
by Saber Tooth 25 Jun '20

25 Jun '20

Hello Melissa , I have altered and built upon my previous proposal , if you could take a few minutes to read it it would be great . I have tried to explain the sections we had discussed in the meeting on 22 June . Moreover as per your feedback , I would like to start contributing to the docs and start building the docs in my Linux environment . Best , Mrinal Tyagi On Wed, 24 Jun 2020 at 2:36 PM, Saber Tooth <sabertooth2022(a)gmail.com> wrote: > Hello Melissa and all the Mentors , > > In the last meeting of NumPy Docs held on June 22nd , I had Proposed > Tutorial and Faqs structure , where it was discussed how we should include > them in the new structured Documentation . > Now after a lot of Googling I have been able to provide a > structured solution > It is very important for us to include the FAQs section , but why ? > If we see how many views some questions on Stack overflow > https://stackoverflow.com/questions/tagged/numpy?tab=frequent&page=1&pagesi… > have got the answer is obvious , the 1st page itself has garnered some 4-5 *million > *views and there are really many questions . It means if we are able to > answer some of these questions ,not necessarily the exact questions , it > would be really good for the Docs . > > I have tried to break the FAQs page into sections so that everything is > not cramped onto one page and we have good docs as per SEO guidelines . > I have structured based on best practices for the FAQs section : > https://www.shivarweb.com/9665/faq-page-best-practices/ . > > I have improved further upon my previous proposal , please have a look. > Eagerly waiting @Melissa Mendonça <melissawm(a)gmail.com> @Ralf Gommers > <ralf.gommers(a)gmail.com> for your feedback on the same , I would be > obliged if you have some ideas which could be incorporated with the same or > built upon these . > > > > Link to Proposal : > https://docs.google.com/document/d/1q-BYO-GqlBIsMizCzjbANORz6OOaC-6oEzuE1_H… > > > Link to FAQs Proposed structure : > https://docs.google.com/document/d/1q-BYO-GqlBIsMizCzjbANORz6OOaC-6oEzuE1_H… > > Link to Tutorials Proposed structure : > https://docs.google.com/document/d/1q-BYO-GqlBIsMizCzjbANORz6OOaC-6oEzuE1_H… > > Thanks , > Mrinal Tyagi >

1 0

NumPy-Discussion June 2020