Mailman 3 July 2020 - NumPy-Discussion

mixed mode arithmetic
by Neal Becker 11 Jul '23

11 Jul '23

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

04 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

Why does fancy indexing work like this?
by Aaron Meurer 24 Aug '20

24 Aug '20

Why does fancy indexing have this behavior? >>> a = np.empty((0, 1, 2)) >>> b = np.empty((1, 1, 2)) >>> a[np.array([10, 10])] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: index 10 is out of bounds for axis 0 with size 0 >>> a[:, np.array([10, 10])] array([], shape=(0, 2, 2), dtype=float64) >>> a[:, :, np.array([10, 10])] array([], shape=(0, 1, 2), dtype=float64) >>> b[np.array([10, 10])] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: index 10 is out of bounds for axis 0 with size 1 >>> b[:, np.array([10, 10])] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: index 10 is out of bounds for axis 1 with size 1 >>> b[:, :, np.array([10, 10])] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: index 10 is out of bounds for axis 2 with size 2 As far as I can tell, the behavior is that if an array has a 0 dimension and an integer array index indexes an axis that isn't 0, there are no bounds checks. Why does it do this? It seems to be inconsistent with the behavior of shape () fancy indices (integer indices). I couldn't find any reference to this behavior in https://numpy.org/doc/stable/reference/arrays.indexing.html. Aaron Meurer

2 12

What is up with raw boolean indices (like a[False])?
by Aaron Meurer 21 Aug '20

21 Aug '20

I've been trying to figure out this behavior. It doesn't seem to be documented at https://numpy.org/doc/stable/reference/arrays.indexing.html >>> a = np.empty((2, 3)) >>> a.shape (2, 5) >>> a[True].shape (1, 2, 5) >>> a[False].shape (0, 2, 5) It seems like indexing with a raw boolean (True or False) adds an axis with a dimension 1 or 0, resp. Except it only works once: >>> a[:,False] array([], shape=(2, 0, 3), dtype=float64) >>> a[:,False, False] array([], shape=(2, 0, 3), dtype=float64) >>> a[:,False,True].shape (2, 0, 3) >>> a[:,True,False].shape (2, 0, 3) The docs say "A single boolean index array is practically identical to x[obj.nonzero()]". I have a hard time seeing this as an extension of that, since indexing by `np.nonzero(False)` or `np.nonzero(True)` *replaces* the given axis. >>> a[np.nonzero(True)].shape (1, 3) >>> a[np.nonzero(False)].shape (0, 3) I think at best this behavior should be documented. I'm trying to understand the motivation for it, or if it's even intentional. And in particular, why do multiple boolean indices not insert multiple axes? It would actually be useful to be able to generically add length 0 axes using an index, similar to how `newaxis` adds a length 1 axis. Aaron Meurer

2 11

a summary function to get a quick glimpse on the contents of a numpy array
by Peter Steinbach 01 Aug '20

01 Aug '20

Dear numpy devs and interested readers, as a day-to-day user, it occurred to me that having a quick look into the contents and extents of arrays is well doable with numpy. numpy offers a rich set of methods for this. However, very often I oversee myself and others that one just wants to see if the values of an array have a certain min/max or mean or how wide the range of values are. I hence sat down to write a summary function that returns a string of hand-packed summary statistics for a quick inspection. I propose to include it into numpy and would love to have your feedback on this idea before I submit a PR. Here is the core functionality: Examples -------- >>> a = np.random.normal(size=20) >>> print(summary(a)) min 25perc mean stdev median 75perc max -2.289870 -2.265757 -0.083213 1.115033 -0.162885 -2.217532 1.639802 >>> a = np.reshape(a, newshape=(4,5)) >>> print(summary(a,axis=1)) min 25perc mean stdev median 75perc max 0 -0.976279 -0.974090 0.293003 1.009383 0.466814 -0.969712 1.519695 1 -0.468854 -0.467739 0.184139 0.649378 -0.036762 -0.465510 1.303144 2 -2.289870 -2.276455 -0.324450 1.230031 -0.289008 -2.249625 1.111107 3 -1.782239 -1.777304 -0.485546 1.259598 -1.236190 -1.767434 1.639802 So you see, it is merely a tiny helper function that can aid practitioners and data scientists to get a quick insight on what an array contains. first off, here is the code: https://github.com/psteinb/numpy/blob/summary-function/numpy/lib/utils.py#L… I put it there as I am not sure at this point, if the community would appreciate such a function or not. Judging from the tests, lib/utils.py appears to a be place for undocumented functions. So to resolve this and prepare a proper PR, please let me know where this summary function could reside! Second, please give me your thoughts on the summary function's output? Should the number of digits be configurable? Should the columns be configurable? Is is ok to honor the axis parameter which is found in so many numpy functions? Last but not least, let me stress that this is my first time contribution to numpy. I love the library and would like to contribute something back. So bear with me, if my code violates best practices in your community for now. I'll bite my teeth into the formalities of a github PR once I get support from the community and the core devs. I think that a summary function would be a valuable addition to numpy! Best, Peter

2 1

Re: [Numpy-discussion] Documentation Team meeting - Monday August 3
by Melissa Mendonça 31 Jul '20

31 Jul '20

Thanks, you too! On Fri, Jul 31, 2020 at 12:21 PM olzhas robo.ai <o(a)roboai.net> wrote: > Thank you, Melissa! Have a great weekend :) > > On Fri, 31 Jul 2020 at 13:10, Melissa Mendonça <melissawm(a)gmail.com> > wrote: > >> Hi all! >> >> This is a reminder that our next Documentation Team meeting will be on *Monday, >> August 3* 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 (still being >> updated in the next few days!): >> >> 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! >> >> ** You can click this link to get the correct time at your timezone: >> https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Documentati… >> >> *** You can add the NumPy community calendar to your google calendar by >> clicking this link: >> https://calendar.google.com/calendar/r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMy… >> >> - Melissa >> >

1 0

NumPy Development Meeting Today - Triage Focus
by Warren Weckesser 29 Jul '20

29 Jul '20

Hi all, Sorry for the short notice--Sebastian is off this week, and the rest of us forgot to send the email reminder. Our bi-weekly triage-focused NumPy development meeting is in 10 minutes (today, Wednesday, July 29th, 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 Warren

1 0

NumPy dtype API improvement suggestion
by Eyal Kutz 27 Jul '20

27 Jul '20

I am interested in suggesting an API improvement for NumPy. I wish to make it so that the following code: @np.dtype class Point: x: np.int16 y: np.int16 would be equivalent to the following code: Point = np.dtype([('x', np.int16), ('y', np.int16)]) I am willing to submit the code changes required to make this happen.

4 3

Journey with NumPy in Docs Development
by Saber Tooth 27 Jul '20

27 Jul '20

Hello @Melissa Mendonça <melissawm(a)gmail.com> @Ralf Gommers <ralf.gommers(a)gmail.com> @Matti Picus <matti.picus(a)gmail.com> , My journey working with NumPy Docs team has been nothing short of Progressive , the insights that i have gained attending the Docs meeting has helped me refine my proposal . Attending the past 3 meetings have helped me remove some of redundant features in my proposal , letting me structure the Explanations , How-To's ,Tutorials in a better way keeping in mind the requirements as highlighted by NEP-44 and the mentors . I have really tried to work upon NumPy community bonding , i have been a part of some really good discussions , contributed to some ideas , raised some queries ☺ which so far i can say has been really progressive for me to start contributing , as today i understand what NumPy Docs is trying to deliver . I have really been enticed by the workflow of the community which encourages me to think and contribute to as much as I can. I have been mining the NumPy Discussion mailing list since last meeting using the archive as mentioned in Hackmd doc by @Ralf Gommers <ralf.gommers(a)gmail.com> , collecting topics for which we can frame Tutorials , How To's and Explanations . Discussion around Explanations has been really fruitful with @Melissa Mendonça <melissawm(a)gmail.com> and the community . Moreover I am working on a how-to nowadays for which I will soon open a PR . Contributing to NumPy in such a manner I believe will help me get started with Official Documentation Period in a more Efficient manner , as i had already worked upon Community Bonding which will continue to strengthen in upcoming days . Thank You for your encouragement and having me , I am looking into delivering much more and contributing to my GSoD Proposal and beyond that too . Thanks , Mrinal Tyagi

1 0

Re: [Numpy-discussion] NumPy dtype API improvement suggestion
by Eyal Kutz 26 Jul '20

26 Jul '20

*Kevin Sheppard, I agree with you but* I don't know how to do this. do you?

1 0

ANN: SciPy 1.5.2
by Tyler Reddy 24 Jul '20

24 Jul '20

Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.5.2, which is a bug fix release. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.5.2 One of a few ways to install this release with pip: pip install scipy==1.5.2 ========================== SciPy 1.5.2 Release Notes ========================== SciPy 1.5.2 is a bug-fix release with no new features compared to 1.5.1. Authors ====== * Peter Bell * Tobias Biester + * Evgeni Burovski * Thomas A Caswell * Ralf Gommers * Sturla Molden * Andrew Nelson * ofirr + * Sambit Panda * Ilhan Polat * Tyler Reddy * Atsushi Sakai * Pauli Virtanen A total of 13 people contributed to this release. People with a "+" by their names contributed a patch for the first time. This list of names is automatically generated, and may not be fully complete. Issues closed for 1.5.2 ------------------------------ * `#3847 <https://github.com/scipy/scipy/issues/3847>`__: Crash of interpolate.splprep(task=-1) * `#7395 <https://github.com/scipy/scipy/issues/7395>`__: splprep segfaults if fixed knots are specified * `#10761 <https://github.com/scipy/scipy/issues/10761>`__: scipy.signal.convolve2d produces incorrect values for large arrays * `#11971 <https://github.com/scipy/scipy/issues/11971>`__: DOC: search in devdocs returns wrong link * `#12155 <https://github.com/scipy/scipy/issues/12155>`__: BUG: Fix permutation of distance matrices in scipy.stats.multiscale_graphcorr * `#12203 <https://github.com/scipy/scipy/issues/12203>`__: Unable to install on PyPy 7.3.1 (Python 3.6.9) * `#12316 <https://github.com/scipy/scipy/issues/12316>`__: negative scipy.spatial.distance.correlation * `#12422 <https://github.com/scipy/scipy/issues/12422>`__: BUG: slsqp: ValueError: failed to initialize intent(inout) array... * `#12428 <https://github.com/scipy/scipy/issues/12428>`__: stats.truncnorm.rvs() never returns a scalar in 1.5 * `#12441 <https://github.com/scipy/scipy/issues/12441>`__: eigvalsh inconsistent eigvals= subset_by_index= * `#12445 <https://github.com/scipy/scipy/issues/12445>`__: DOC: scipy.linalg.eigh * `#12449 <https://github.com/scipy/scipy/issues/12449>`__: Warnings are not filtered in csr_matrix.sum() * `#12469 <https://github.com/scipy/scipy/issues/12469>`__: SciPy 1.9 exception in LSQSphereBivariateSpline * `#12487 <https://github.com/scipy/scipy/issues/12487>`__: BUG: optimize: incorrect result from approx_fprime * `#12493 <https://github.com/scipy/scipy/issues/12493>`__: CI: GitHub Actions for maintenance branches * `#12533 <https://github.com/scipy/scipy/issues/12533>`__: eigh gives incorrect results * `#12579 <https://github.com/scipy/scipy/issues/12579>`__: BLD, MAINT: distutils issues in wheels repo Pull requests for 1.5.2 ------------------------------- * `#12156 <https://github.com/scipy/scipy/pull/12156>`__: BUG: Fix permutation of distance matrices in scipy.stats.multiscale_graphcorr * `#12238 <https://github.com/scipy/scipy/pull/12238>`__: BUG: Use 64-bit indexing in convolve2d to avoid overflow * `#12256 <https://github.com/scipy/scipy/pull/12256>`__: BLD: Build lsap as a single extension instead of extension +... * `#12320 <https://github.com/scipy/scipy/pull/12320>`__: BUG: spatial: avoid returning negative correlation distance * `#12383 <https://github.com/scipy/scipy/pull/12383>`__: ENH: Make cKDTree.tree more efficient * `#12392 <https://github.com/scipy/scipy/pull/12392>`__: DOC: update scipy-sphinx-theme * `#12430 <https://github.com/scipy/scipy/pull/12430>`__: BUG: truncnorm and geninvgauss never return scalars from rvs * `#12437 <https://github.com/scipy/scipy/pull/12437>`__: BUG: optimize: cast bounds to floats in new_bounds_to_old/old_bounds_to_new * `#12442 <https://github.com/scipy/scipy/pull/12442>`__: MAINT:linalg: Fix for input args of eigvalsh * `#12461 <https://github.com/scipy/scipy/pull/12461>`__: MAINT: sparse: write matrix/asmatrix wrappers without warning... * `#12478 <https://github.com/scipy/scipy/pull/12478>`__: BUG: fix array_like input defects and add tests for all functions... * `#12488 <https://github.com/scipy/scipy/pull/12488>`__: BUG: fix approx_derivative step size. Closes #12487 * `#12500 <https://github.com/scipy/scipy/pull/12500>`__: CI: actions branch trigger fix * `#12501 <https://github.com/scipy/scipy/pull/12501>`__: CI: actions branch trigger fix * `#12504 <https://github.com/scipy/scipy/pull/12504>`__: BUG: cKDTreeNode use after free * `#12529 <https://github.com/scipy/scipy/pull/12529>`__: MAINT: allow graceful docs re-upload * `#12538 <https://github.com/scipy/scipy/pull/12538>`__: BUG:linalg: eigh type parameter handling corrected * `#12560 <https://github.com/scipy/scipy/pull/12560>`__: MAINT: truncnorm.rvs compatibility for \`Generator\` * `#12562 <https://github.com/scipy/scipy/pull/12562>`__: redo gh-12188: fix segfaults in splprep with fixed knots * `#12586 <https://github.com/scipy/scipy/pull/12586>`__: BLD: Add -std=c99 to sigtools to compile with C99 * `#12590 <https://github.com/scipy/scipy/pull/12590>`__: CI: Add GCC 4.8 entry to travis build matrix * `#12591 <https://github.com/scipy/scipy/pull/12591>`__: BLD: fix cython error on master-branch cython Checksums ========= MD5 ~~~ 2e046d26cdc4241a6a5b2907d57528df scipy-1.5.2-cp36-cp36m-macosx_10_9_x86_64.whl 902dea66453e2fa0616e9479970986f5 scipy-1.5.2-cp36-cp36m-manylinux1_i686.whl e130db080706d9f4ce22d8493c8e1ce2 scipy-1.5.2-cp36-cp36m-manylinux1_x86_64.whl 721f16bae600731e479a5b4e98ce9a97 scipy-1.5.2-cp36-cp36m-win32.whl a3171cfe38618d51acbfb8d1b39ac612 scipy-1.5.2-cp36-cp36m-win_amd64.whl c9f733d4d2e82c098c08760963dafaf8 scipy-1.5.2-cp37-cp37m-macosx_10_9_x86_64.whl 53ba6c502d09145b38e0e857b2d4a273 scipy-1.5.2-cp37-cp37m-manylinux1_i686.whl b9db33944ac4147936a7f42df8e95ad2 scipy-1.5.2-cp37-cp37m-manylinux1_x86_64.whl be9e8bfdf0e5e0914d1e1605be26d9c0 scipy-1.5.2-cp37-cp37m-win32.whl 848fa7b82a25d0ce36710ccc47ebc2ca scipy-1.5.2-cp37-cp37m-win_amd64.whl 590cd3b70a2dc8664896d6b9e2e5fc6d scipy-1.5.2-cp38-cp38-macosx_10_9_x86_64.whl 7fdbb19c15702b98319ea4ea32df8458 scipy-1.5.2-cp38-cp38-manylinux1_i686.whl 301f3a873e1bfef70d6f594c489fafe8 scipy-1.5.2-cp38-cp38-manylinux1_x86_64.whl 8c08ac0f55810e89e336eb3bf5a7b337 scipy-1.5.2-cp38-cp38-win32.whl 711f5c47c801dc79bead7d40669fd8c9 scipy-1.5.2-cp38-cp38-win_amd64.whl 620fc39f371e04a76af5d0290f8d3753 scipy-1.5.2.tar.gz 5bc188f21054a2ecff74fae40dd298da scipy-1.5.2.tar.xz 17bc80802955d100f6c1335594eda29a scipy-1.5.2.zip SHA256 ~~~~~~ cca9fce15109a36a0a9f9cfc64f870f1c140cb235ddf27fe0328e6afb44dfed0 scipy-1.5.2-cp36-cp36m-macosx_10_9_x86_64.whl 1c7564a4810c1cd77fcdee7fa726d7d39d4e2695ad252d7c86c3ea9d85b7fb8f scipy-1.5.2-cp36-cp36m-manylinux1_i686.whl 07e52b316b40a4f001667d1ad4eb5f2318738de34597bd91537851365b6c61f1 scipy-1.5.2-cp36-cp36m-manylinux1_x86_64.whl d56b10d8ed72ec1be76bf10508446df60954f08a41c2d40778bc29a3a9ad9bce scipy-1.5.2-cp36-cp36m-win32.whl 8e28e74b97fc8d6aa0454989db3b5d36fc27e69cef39a7ee5eaf8174ca1123cb scipy-1.5.2-cp36-cp36m-win_amd64.whl 6e86c873fe1335d88b7a4bfa09d021f27a9e753758fd75f3f92d714aa4093768 scipy-1.5.2-cp37-cp37m-macosx_10_9_x86_64.whl a0afbb967fd2c98efad5f4c24439a640d39463282040a88e8e928db647d8ac3d scipy-1.5.2-cp37-cp37m-manylinux1_i686.whl eecf40fa87eeda53e8e11d265ff2254729d04000cd40bae648e76ff268885d66 scipy-1.5.2-cp37-cp37m-manylinux1_x86_64.whl 315aa2165aca31375f4e26c230188db192ed901761390be908c9b21d8b07df62 scipy-1.5.2-cp37-cp37m-win32.whl ec5fe57e46828d034775b00cd625c4a7b5c7d2e354c3b258d820c6c72212a6ec scipy-1.5.2-cp37-cp37m-win_amd64.whl fc98f3eac993b9bfdd392e675dfe19850cc8c7246a8fd2b42443e506344be7d9 scipy-1.5.2-cp38-cp38-macosx_10_9_x86_64.whl a785409c0fa51764766840185a34f96a0a93527a0ff0230484d33a8ed085c8f8 scipy-1.5.2-cp38-cp38-manylinux1_i686.whl 0a0e9a4e58a4734c2eba917f834b25b7e3b6dc333901ce7784fd31aefbd37b2f scipy-1.5.2-cp38-cp38-manylinux1_x86_64.whl dac09281a0eacd59974e24525a3bc90fa39b4e95177e638a31b14db60d3fa806 scipy-1.5.2-cp38-cp38-win32.whl 92eb04041d371fea828858e4fff182453c25ae3eaa8782d9b6c32b25857d23bc scipy-1.5.2-cp38-cp38-win_amd64.whl 066c513d90eb3fd7567a9e150828d39111ebd88d3e924cdfc9f8ce19ab6f90c9 scipy-1.5.2.tar.gz 28d5d2e9af6ca5c0352cd83fb64191f2d8e883ab5287a221ba7a175c8cc2ccbe scipy-1.5.2.tar.xz a9054595a370f24d68f7a694037316b69ae80f5837323d567f76cde055189c08 scipy-1.5.2.zip

1 0

NumPy 1.19.1 released.
by Charles R Harris 21 Jul '20

21 Jul '20

Hi All, On behalf of the NumPy team I am pleased to announce that NumPy 1.19.1 has been released. This release supports Python 3.6-3.8 and may be built with the latest Python 3.9 beta. It fixes several bugs found in the 1.19.0 release, replaces several functions deprecated in the upcoming Python-3.9 release, has improved support for AIX, and has a number of development related updates to keep CI working with recent upstream changes. Downstream developers should use Cython >= 0.29.21 when building for Python 3.9 and Cython >= 0.29.16 when building for Python 3.8. OpenBLAS >= 3.7 is needed to avoid wrong results on the Skylake architecture. The NumPy Wheels for this release can be downloaded from PyPI <https://pypi.org/project/numpy/1.19.1/>, source archives, release notes, and wheel hashes are available from Github <https://github.com/numpy/numpy/releases/tag/v1.19.1>. Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. *Contributors* A total of 15 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Abhinav Reddy + - Anirudh Subramanian - Antonio Larrosa + - Charles Harris - Chunlin Fang - Eric Wieser - Etienne Guesnet + - Kevin Sheppard - Matti Picus - Raghuveer Devulapalli - Roman Yurchak - Ross Barnowski - Sayed Adel - Sebastian Berg - Tyler Reddy *Pull requests merged* A total of 25 pull requests were merged for this release. - #16649: MAINT, CI: disable Shippable cache - #16652: MAINT: Replace PyUString_GET_SIZE with PyUnicode_GetLength. - #16654: REL: Fix outdated docs link - #16656: BUG: raise IEEE exception on AIX - #16672: BUG: Fix bug in AVX complex absolute while processing array of... - #16693: TST: Add extra debugging information to CPU features detection - #16703: BLD: Add CPU entry for Emscripten / WebAssembly - #16705: TST: Disable Python 3.9-dev testing. - #16714: MAINT: Disable use_hugepages in case of ValueError - #16724: BUG: Fix PyArray_SearchSorted signature. - #16768: MAINT: Fixes for deprecated functions in scalartypes.c.src - #16772: MAINT: Remove unneeded call to PyUnicode_READY - #16776: MAINT: Fix deprecated functions in scalarapi.c - #16779: BLD, ENH: Add RPATH support for AIX - #16780: BUG: Fix default fallback in genfromtxt - #16784: BUG: Added missing return after raising error in methods.c - #16795: BLD: update cython to 0.29.21 - #16832: MAINT: setuptools 49.2.0 emits a warning, avoid it - #16872: BUG: Validate output size in bin- and multinomial - #16875: BLD, MAINT: Pin setuptools - #16904: DOC: Reconstruct Testing Guideline. - #16905: TST, BUG: Re-raise MemoryError exception in test_large_zip's... - #16906: BUG, DOC: Fix bad MPL kwarg. - #16916: BUG: Fix string/bytes to complex assignment - #16922: REL: Prepare for NumPy 1.19.1 release Cheers, Charles Harris

1 0

NumPy Community Meeting Wednesday
by Sebastian Berg 21 Jul '20

21 Jul '20

Hi all, There will be a NumPy Community meeting Wednesday July 22nd at 1pm Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in and edit the work-in-progress meeting topics and notes at: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian

1 0

Augment unique method
by Amin Sadeghi 16 Jul '20

16 Jul '20

It would be handy to add "atol" and "rtol" optional arguments to the "unique" method. I'm proposing this since uniqueness is a bit vague for floats. This change would be clearly backwards-compatible.

4 4

Discussion around How-to ,Tutorials.
by Saber Tooth 16 Jul '20

16 Jul '20

Hello Melissa , Are we having our Docs meeting on 20th July ? If yes , then could we have some discussion around the structure of tutorials ,how-to sections . I wanted to discuss how we are planning to distinguish between the two , should the How-to be straightforward solutions like here <https://matplotlib.org/3.2.2/gallery/lines_bars_and_markers/bar_stacked.htm…> or something else . Tutorials should be structured as in here <https://matplotlib.org/3.2.2/tutorials/introductory/usage.html#sphx-glr-tut…> or something else . The general belief is when we hear the word "How to" is that we are greeted to just the solution of the problem like above , while when we hear Tutorials we are greeted to Detailed solutions with explanations for most of the steps . Thanks , Mrinal

2 1

An alternative to vectorize that lets you access the array?
by Ram Rachum 15 Jul '20

15 Jul '20

Hi everyone, Here's a problem I've been dealing with. I wonder whether NumPy has a tool that will help me, or whether this could be a useful feature request. In the upcoming EuroPython 20200, I'll do a talk about live-coding a music synthesizer. It's going to be a fun talk, I'll use the sounddevice <https://github.com/spatialaudio/python-sounddevice/> module to make a program that plays music. Do attend, or watch it on YouTube when it's out :) There's a part in my talk that I could make simpler, and thus shave 3-4 minutes of cumbersome explanations. These 3-4 minutes matter a great deal to me. But for that I need to do something with NumPy and I don't know whether it's possible or not. The sounddevice library takes an ndarray of sound data and plays it. Currently I use `vectorize` to produce that array: output_array = np.vectorize(f, otypes='d')(input_array) And I'd like to replace it with this code, which is supposed to give the same output: output_array = np.ndarray(input_array.shape, dtype='d') for i, item in enumerate(input_array): output_array[i] = f(item) The reason I want the second version is that I can then have sounddevice start playing `output_array` in a separate thread, while it's being calculated. (Yes, I know about the GIL, I believe that sounddevice releases it.) Unfortunately, the for loop is very slow, even when I'm not processing the data on separate thread. I benchmarked it on both CPython and PyPy3, which is my target platform. On CPython it's 3 times slower than vectorize, and on PyPy3 it's 67 times slower than vectorize! That's despite the fact that the Numpy documentation says "The `vectorize` function is provided primarily for convenience, not for performance. The implementation is essentially a `for` loop." So here are a few questions: 1. Is there something like `vectorize`, except you get to access the output array before it's finished? If not, what do you think about adding that as an option to `vectorize`? 2. Is there a more efficient way of writing the `for` loop I've written above? Or any other kind of solution to my problem? Thanks for your help, Ram Rachum.

4 6

NumPy Development Meeting Today - Triage Focus
by Sebastian Berg 15 Jul '20

15 Jul '20

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

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

Collection of Questions for Explanations
by Saber Tooth 11 Jul '20

11 Jul '20

Hi Mentors , In the last Docs meeting , we discussed about Explanations and ways we could use to gather relevant topics for which we could provide explanations . The light was shed upon mining of questions firstly from numpy communities via Discussion like groups , then move to other sources . We can mine such topics from the NumPy community via mining email threads of numpy-discussion(a)python.org for Questions . Apart from doing this I am thinking of opening an issue , the track of which will be kept by me and other contributors if they wish . We can write relevant topics for explanations over there . The link to this issue can be shared with numpy-discussion(a)python.org and other NumPy community forums , where contributors can comment their questions or queries which they wish to get documented . This way we can avoid multiple Github issues by using one Github issue , moreover this issue will populate queries from the community which will be visible to everyone and may give rise to ideas regarding explanations which we haven't thought about , in fact we can close other such issues later by moving their queries to this issue . In this manner we can have enough data within a month or two to document an Explanations page . Then we could frame explanations from this pool of data in this single Github issue , Do suggest your ideas/advice for the following and also if we should be doing something else . Thanks , Mrinal Tyagi

2 3

NumPy Sprint on the weekend
by Sebastian Berg 10 Jul '20

10 Jul '20

Hi all, since there is the SciPy sprints going on we will also be joining the event and sprinting as well. The kickoff for the SciPy sprint session is at 9:00 CST (7:00 PST, 16:00 CET), with the start of the sprints around 9:30. We are gathering all information at the hackmd: https://hackmd.io/r4pcf4CQRMOUY2VXOWk5_Q so that we can be flexible with organization (e.g. which video software to use). Note that attendance may pick up only a few hours later, but we will try to be around most of the time. Currently, we have a few documentation fixed listed to be worked on, but it will be a good time to just chat or ask for help setting up a getting started. Another bigger topic is website translations, but more will be added certainly and input is welcome! If you plan on coming, feel free to write yourself into the hackmd so that we know when you are going to be around. Hope you drop in, if just to say hi! Cheers, Sebastian

1 0

NumPy Documentation Gallery structure
by Saber Tooth 08 Jul '20

08 Jul '20

Hello Melissa and Ralf , I was just wondering if we haven't had much discussion on the structuring of tutorials , while we have had some discussion on Explanations . I have been analysing the Tutorials of some other communities too , say Matplotlib : they have basically structured the tutorials page like a Gallery where examples have been arranged in the order of experience level . Link to Matplotlib tutorials : https://matplotlib.org/3.2.2/tutorials/index.html Here is SunPy Documentation. They have tried to structure their How-TO examples in the same way like a Gallery . Link to SunPy Gallery Examples : https://docs.sunpy.org/en/v2.0.1/generated/gallery/index.html# Please have a Look , maybe we can also get some new ideas for our Documentation . I think it will help us to structure the Tutorials page of NumPy too . Thanks , Mrinal Tyagi

3 3

NumPy Community Meeting Wednesday
by Sebastian Berg 07 Jul '20

07 Jul '20

Hi all, There will be a NumPy Community meeting Wednesday July 8th at 1pm Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in and edit the work-in-progress meeting topics and notes at: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian

1 0

GSoD application technical limitations
by Saber Tooth 07 Jul '20

07 Jul '20

Hello Melissa , Today I was writing my GSoD proposal application , while I tried to copy / paste my exact Google docs proposal in the application description , but even after clearing all the formatting , the application form is stating that the " response is too large , try shortening some answers " Now many people have complained regarding this issue on the season of docs channel , so it means the issue is upsetting everyone . So I wanted to request if it's fine I also mention the link to my google docs Proposal where it is explained in much more detail. In application I have almost shortened half of my proposal therefore it has started to lose its minute explanatory details . Thanks , Mrinal Tyagi

2 1

Parlez-vous français?
by Inessa Pawson 06 Jul '20

06 Jul '20

As most of you know, the inaugural NumPy community survey <https://umdsurvey.umd.edu/jfe/form/SV_8bJrXjbhXf7saAl> is currently underway. Fabrice Silva kindly offered his help to translate the survey questionnaire into French to maximize the participation of NumPy users and developers from the French-speaking countries. He has already completed his part of the translation (in less than 24 hours!). We are looking for another French-speaking volunteer to finalize the translation process of this document. If you are available, please email me at inessa(a)albuscode.org. -- Every good wish, Inessa Pawson NumPy survey team inessa(a)albuscode.org

1 0

ANN: SciPy 1.5.1
by Tyler Reddy 04 Jul '20

04 Jul '20

Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.5.1, which is a bug fix release. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.5.1 One of a few ways to install this release with pip: pip install scipy==1.5.1 ========================== SciPy 1.5.1 Release Notes ========================== SciPy 1.5.1 is a bug-fix release with no new features compared to 1.5.0. In particular, an issue where DLL loading can fail for SciPy wheels on Windows with Python 3.6 has been fixed. Authors ======= * Peter Bell * Loïc Estève * Philipp Thölke + * Tyler Reddy * Paul van Mulbregt * Pauli Virtanen * Warren Weckesser A total of 7 people contributed to this release. People with a "+" by their names contributed a patch for the first time. This list of names is automatically generated, and may not be fully complete. Issues closed for 1.5.1 -------------------------------- * `#9108 <https://github.com/scipy/scipy/issues/9108>`__: documentation: scipy.spatial.KDTree vs. scipy.spatial.cKDTree * `#12218 <https://github.com/scipy/scipy/issues/12218>`__: Type error in stats.ks_2samp when alternative != 'two-sided- * `#12406 <https://github.com/scipy/scipy/issues/12406>`__: DOC: Docstring in stats.anderson function not properly formatted * `#12418 <https://github.com/scipy/scipy/issues/12418>`__: Regression in hierarchy.dendogram Pull requests for 1.5.1 -------------------------------- * `#12280 <https://github.com/scipy/scipy/pull/12280>`__: BUG: Fixes gh-12218, TypeError converting int to float inside... * `#12336 <https://github.com/scipy/scipy/pull/12336>`__: BUG: KDTree should reject complex input points * `#12344 <https://github.com/scipy/scipy/pull/12344>`__: MAINT: Don't use numpy's aliases of Python builtin objects. * `#12407 <https://github.com/scipy/scipy/pull/12407>`__: DOC: Fix docstring for dist param in anderson function * `#12410 <https://github.com/scipy/scipy/pull/12410>`__: CI: Run the Azure Windows Python36 32bit tests with mode 'fast' * `#12421 <https://github.com/scipy/scipy/pull/12421>`__: Fix regression in scipy 1.5.0 in dendogram when labels is a numpy... * `#12462 <https://github.com/scipy/scipy/pull/12462>`__: MAINT: move distributor_init import after __config__ import Checksums ========= MD5 ~~~ b71e8115d61c604cc65e5ecc556131f6 scipy-1.5.1-cp36-cp36m-macosx_10_9_x86_64.whl 0190c11f75ed28a7e56050182ca95a18 scipy-1.5.1-cp36-cp36m-manylinux1_i686.whl c4dd717a3a0c3fe64380039e4fda663f scipy-1.5.1-cp36-cp36m-manylinux1_x86_64.whl baad02c954e85e7fd3d4a9fd49fc6359 scipy-1.5.1-cp36-cp36m-win32.whl 9edc3a9aedf6bffccb17101c905126d0 scipy-1.5.1-cp36-cp36m-win_amd64.whl 83479a6de66a6bc2da0990fa71cf3cec scipy-1.5.1-cp37-cp37m-macosx_10_9_x86_64.whl f2d5c8713b087545c5ec19cc8e46212c scipy-1.5.1-cp37-cp37m-manylinux1_i686.whl 6a18a9636342574ae55d3a80136c550c scipy-1.5.1-cp37-cp37m-manylinux1_x86_64.whl 5da68faf5b32c539d1cb5390df010cc8 scipy-1.5.1-cp37-cp37m-win32.whl 2ca8c59a6712e91ac78b8540ab694b53 scipy-1.5.1-cp37-cp37m-win_amd64.whl cceb059d0cf6a70e62452deb5571ba00 scipy-1.5.1-cp38-cp38-macosx_10_9_x86_64.whl 8a65b30ccd72409704d3300922da2b7f scipy-1.5.1-cp38-cp38-manylinux1_i686.whl 00181f52a7917d1c3d50e42a76a6df96 scipy-1.5.1-cp38-cp38-manylinux1_x86_64.whl 2aa8b6ddceaebe7b33d71dbad0e208cc scipy-1.5.1-cp38-cp38-win32.whl a626585d08b0991c8f2df0caacdf9997 scipy-1.5.1-cp38-cp38-win_amd64.whl f6986798b7d22ffc5f80b749d7ec27ca scipy-1.5.1.tar.gz e126a1a0ff954b924a8273faa7437fe3 scipy-1.5.1.tar.xz 3bce82b23d45d1a96ee270f23176746a scipy-1.5.1.zip SHA256 ~~~~~~ 058e84930407927f71963a4ad8c1dc96c4d2d075636a68578195648c81f78810 scipy-1.5.1-cp36-cp36m-macosx_10_9_x86_64.whl 7908c85854c5b5b6d3ce7fefafac1ca3e23ff9ac41edabc2d46ae5dc9fa070ac scipy-1.5.1-cp36-cp36m-manylinux1_i686.whl 8302d69fb1528ea7c7f2a1ea640d354c981b6eb8192d1c175349874209397604 scipy-1.5.1-cp36-cp36m-manylinux1_x86_64.whl 35d042d6499caf1a5d171baed0ebf01eb665b7af2ad98a8ff1b0e6e783654540 scipy-1.5.1-cp36-cp36m-win32.whl 5e0bb43ff581811ab7f27425f6b96c1ddf7591ccad2e486c9af0b910c18f7185 scipy-1.5.1-cp36-cp36m-win_amd64.whl b4858ccbd88f4b53950fb9fc0069c1d9fea83d7cff2382e1d8b023d3f4883014 scipy-1.5.1-cp37-cp37m-macosx_10_9_x86_64.whl eb46d8b5947ca27b0bc972cecfba8130f088a83ab3d08c1a6033d9070b3046b3 scipy-1.5.1-cp37-cp37m-manylinux1_i686.whl fff15df01bef1243468be60c55178ed7576270b200aab08a7ffd5b8e0bbc340c scipy-1.5.1-cp37-cp37m-manylinux1_x86_64.whl 81859ed3aad620752dd2c07c32b5d3a80a0d47c5e3813904621954a78a0ae899 scipy-1.5.1-cp37-cp37m-win32.whl c05c6fe76228cc13c5214e9faf5f2a871a1da54473bc417ab9da310d0e5fff8b scipy-1.5.1-cp37-cp37m-win_amd64.whl 71742889393a724dfce755b6b61228677873d269a4234e51ddaf08b998433c91 scipy-1.5.1-cp38-cp38-macosx_10_9_x86_64.whl 9323d268775991b79690f7b9a28a4e8b8c4f2b160ed9f8a90123127314e2d3c1 scipy-1.5.1-cp38-cp38-manylinux1_i686.whl 06b19a650471781056c1a2172eeeeb777b8b516e9434005dd392a4559e0938b9 scipy-1.5.1-cp38-cp38-manylinux1_x86_64.whl 57a0f2be3063dbe1e3daf31ec9005576e8fd1022a28159d0db71d14566899d16 scipy-1.5.1-cp38-cp38-win32.whl c06e731aa46c0dfc563cc636155758178ebc019ef78b9b0f4370effe2ac0f0e6 scipy-1.5.1-cp38-cp38-win_amd64.whl 039572f0ca9578a466683558c5bf1e65d442860ec6e13307d528749cfe6d07b8 scipy-1.5.1.tar.gz 0728bd66a5251cfeff17a72280ae5a40ec14add217f94868d1415b3c469b610a scipy-1.5.1.tar.xz 6dfa9d1e718588f48731e865674b3270130f7736d6c7dc5ceaeb048f55ed793a scipy-1.5.1.zip

1 0

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

Google Summer of Docs Faq and Tutorial Proposed Structure .
by Ben Nathanson 04 Jul '20

04 Jul '20

Let me first say I'm a volunteer and not a member of the group that will evaluate proposals. But I can tell you how I would choose. A right-sized proposal is stronger than an overambitious one. I'd scale back and pick a single target. From your listed experience, this would be your first significant docs work. Before you can overhaul an entire site, you need to get a feel for the pace of the work. The review process alone guarantees the site can't be transformed in three months. For argument's sake, let's say you focus on mining the internet for how-to subjects. This is not a bad GSoD idea, because it's open-ended: No matter how fast you write, you'll never exhaust the supply of topics, and if work proceeds more slowly than you'd hoped, you will have established a methodology, and any how-tos we get are more than we have now. Apart from appropriate scope, a proposal needs credibility. GSoD tech writers are a coveted resource, so a project wants to be confident that the writer they pick will deliver the goods. We're scientists and engineers, yourself included, so we look for evidence. Put evidence in your proposal. Assuming you pick how-tos, show the NumPy team how thoroughly you've considered the issues, explain your methodology and its strengths and shortcomings, and, most importantly, give samples of how-tos you've transformed. It's like a job interview, but harder: Not only do you have to provide the answers, you have to anticipate the questions. Does that mean you have to do work upfront that you might do during GSoD? Yes. You're staking capital. The more you put on the table, the more confident the team can be in your sincerity and skill. That said, you do stand to lose it all if someone else is chosen. That can happen even if you send in a proposal that everyone agrees looks good. Your effort will not be a waste; you'll have developed skill in drafting a competitive proposal -- useful in grant writing, calls for papers, and next year's GSoD. Again, this is peer review, not official guidance. And to be clear, I myself am not participating in GSoD; I thought I might but chose instead to simply volunteer.

1 1

Re: [Numpy-discussion] Help us to make NumPy better
by Inessa Pawson 04 Jul '20

04 Jul '20

On Fri, Jul 3, 2020 at 5:45 PM <numpy-discussion-request(a)python.org> wrote: > > ---------- Forwarded message ---------- > From: Inessa Pawson <albuscode(a)gmail.com> > To: numpy-discussion(a)python.org > Cc: > Bcc: > Date: Fri, 3 Jul 2020 12:12:00 +1000 > Subject: [Numpy-discussion] Help us to make NumPy better > > Yes, it’s a survey. But it’s very important. > > Having limited human and financial resources is a common challenge for > open source projects. NumPy is not an exception. Please join this > structured dialogue with the NumPy leadership team to better guide and > prioritize decision-making about the development of NumPy as software and a > community. > > What started as a humble project by a dedicated core of user-developers > has since transformed into a foundational component of the widely-adopted > scientific Python ecosystem used by millions worldwide. To engage > non-English speaking stakeholders, the inaugural NumPy community survey is > offered in 7 additional languages: Bangla, Hindi, Japanese, Mandarin, > Portuguese, Russian, and Spanish. > > The survey will take about 15 minutes of your time and close on July 17th. Click > here <https://umdsurvey.umd.edu/jfe/form/SV_8bJrXjbhXf7saAl> to get > started. > > Inessa Pawson > > NumPy Survey Team > Thank you to everyone who took the time to participate in the inaugural NumPy community survey in the first 24 hours! It is an effort of a group of volunteers who showed a remarkable dedication to the project amidst the COVID-19 pandemic. I’d like to take this opportunity to acknowledge everyone involved. Survey team (in alphabetical order) Ross Barnowski Sebastian Berg Xiaoyi Deng Ralf Gommers Stephanie Mendoza Inessa Pawson Translations team (in alphabetical order) Yuki Dunn Kiko Correoso Garcia Jose Guzman Paul Ivanov Siddhartha Kapoor Tetsuo Koyama Guilherme Leobas Dayane Machado Mahfuza Humayra Mohona Aerik Pawson Zijie Poh Sumera Priyadarsini Shaloo Shalini Kriti Singh Alexandre de Siqueira Special thanks Prof. Frederick Conrad (Survey Research Center, Institute for Social Research, University of Michigan) Prof. Jim Lepkowski (Survey Research Center, Institute for Social Research, University of Michigan) Prof. Michael Traugott (Survey Research Center, Institute for Social Research, University of Michigan) Deji Suolang Mame Fatou Thiam -- Every good wish, *Inessa Pawson* Albus Code inessa(a)albuscode.org

1 0

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

03 Jul '20

Hi Melissa , I have been trying to follow https://numpy.org/devdocs/dev/index.html and build docs , i am not able to execute the building albeit following the exact guidelines. Is there a slack channel for this as i'd be able to better explain / resolve it there , till then : I have tried make html command after adhering to the above link Error when i haven't switched it to required git version : installed numpy 32f514f546 != current repo git version '3cf4c28906' use "make dist" or "GITVER=32f514f546 make html ..." Makefile:93: recipe for target 'version-check' failed make: *** [version-check] Error 1 Now when i make it work as per my installed numpy version : There are quite a lot of warnings and many problems like : document isn't included in any toctree failed to import 'numpy.polynomial.set_default_printstyle': no module named numpy.polynomial.set_default_printstyle WARNING: autodoc: failed to import module 'typing' from module 'numpy'; the following exception was raised: No module named 'numpy.typing' Many modules were missing which gave a warning , Now maybe the errors are coming in just my workspace , but I have tried reinstalling everything , got the latest version of cython too . It would be really helpful for me if you are able to give me some advice , or a workaround for the problem On Fri, 26 Jun 2020 at 01:39, Melissa Mendonça <melissawm(a)gmail.com> wrote: > Hello Mrinal, > > I don't think I have any other specific issues to comment on your > proposal. The mentors will analyze all proposals after July 9th. > > If you want to start contributing to the docs, you are welcome. You can > check the Contributor Guide (https://numpy.org/devdocs/dev/index.html), > How to contribute documentation ( > https://numpy.org/devdocs/dev/howto-docs.html) and the current > documentation. > > Thanks, > > Melissa > > On Thu, Jun 25, 2020 at 2:27 PM Saber Tooth <sabertooth2022(a)gmail.com> > wrote: > >> 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 >>> >>

2 2

Re: [Numpy-discussion] Python for Climate Action session at SciPy'20
by Inessa Pawson 03 Jul '20

03 Jul '20

Juan, I’ve scheduled the “Python for Climate Action” session for July 8th at 5 - 6 p.m. CDT. Mark, it would be great if someone from pvlib could moderate it. The networking sessions at SciPy'20 will be hosted in a format similar to unconferences. We will be using Zoom to make it easier for the moderators to oversee their sessions. Don't hesitate to contact me if you have any further questions regarding this session. ---------- Forwarded message ---------- > From: "Dr. Mark Alexander Mikofski PhD" <mikofski(a)berkeley.edu> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Cc: > Bcc: > Date: Thu, 2 Jul 2020 09:09:32 -0700 > Subject: Re: [Numpy-discussion] Python for Climate Action session at > SciPy'20 > I can repost this on pvlib (solar energy photovoltaic library) Python > Google group (https://groups.google.com/forum/m/#!forum/pvlib-python). We > have plenty of both climate and atmospheric scientists, and we are avid > users of Numpy, SciPy, and the scientific stack. We would love to share > constructive uses of Python in climate science. > > On Thu, Jul 2, 2020, 7:18 AM Juan Nunez-Iglesias <jni(a)fastmail.com> wrote: > >> Hi Inessa, >> >> Thanks for offering! I definitely want to participate but I would *love >> it* if an actual climate scientist or even *any* atmospheric scientist >> would step up to chair the session! I have not thought all that deeply >> about this problem, and mostly I feel helpless and frustrated. >> >> If no one else volunteers though I'm happy to do it. >> >> I much prefer the Wednesday session. Let's book it in! >> >> Thank you all, >> >> Juan. >> >> On 2 Jul 2020, at 8:38 pm, Inessa Pawson <albuscode(a)gmail.com> wrote: >> >> Hi, Juan! >> I’m still in the process of scheduling live networking sessions at >> SciPy’20 and would be happy to set up one on the topic of Python for >> Climate Action. We could host it on July 8th or 10th at 5 - 6 p.m. CDT. >> Would you be available to moderate it? >> >> -- Every good wish, *Inessa Pawson* Albus Code inessa(a)albuscode.org

1 0

Proposal to add clause to license prohibiting use by oil and gas extraction companies
by John Preston 03 Jul '20

03 Jul '20

Hello all, The following proposal was originally issue #16722 on GitHub but at the request of Matti Picus I am moving the discussion to this list. "NumPy is the fundamental package needed for scientific computing with Python." I am asking the NumPy project to leverage its position as a core dependency among statistical, numerical, and ML projects, in the pursuit of climate justice. It is easy to identify open-source software used by the oil and gas industry which relies on NumPy [1] [2] , and it is highly likely that NumPy is used in closed-source and in-house software at oil and gas extraction companies such as Aramco, ExxonMobil, BP, Shell, and others. I believe it is possible to use software licensing to discourage the use of NumPy and dependent packages by companies such as these, and that doing so would frustrate the ability of these companies to identify and extract new oil and gas reserves. I propose NumPy's current BSD 3-Clause license be extended to include the following conditions, in line with the Climate Strike License [3] : * The Software may not be used in applications and services that are used for or aid in the exploration, extraction, refinement, processing, or transportation of fossil fuels. * The Software may not be used by companies that rely on fossil fuel extraction as their primary means of revenue. This includes but is not limited to the companies listed at https://climatestrike.software/blocklist I accept that there are issues around adopting such a proposal, including that: addition of such clauses violates the Open Source Initiative's canonical Open Source Definition, which explicitly excludes licenses that limit re-use "in a specific field of endeavor", and therefore if these clauses were adopted NumPy would no longer "be open-source" by this definition; there may be collateral damage among the wider user base and project sponsorship, due to the vague nature of the first clause, and this may affect the longevity of the project and its standing within the Python, numerical, statistical, and ML communities. My intention with the opening of this issue is to promote constructive discussion of the use of software licensing -- and other measures -- for working towards climate justice -- and other forms of justice -- in the context of NumPy and other popular open-source libraries. Some people will say that NumPy is "just a tool" and that it sits independent of how it is used, but due to its utility and its influence as a major open-source library, I think it is essential that we consider the position of the Climate Strike License authors, that "as tech workers, we should take responsibility in how our software is used". Many thanks to all of the contributors who have put so much time and energy into NumPy. ✨ ❤️ 😃 [1] https://github.com/gazprom-neft/petroflow [2] https://github.com/climate-strike/analysis [3] https://github.com/climate-strike/license

12 12

Help us to make NumPy better
by Inessa Pawson 03 Jul '20

03 Jul '20

Yes, it’s a survey. But it’s very important. Having limited human and financial resources is a common challenge for open source projects. NumPy is not an exception. Please join this structured dialogue with the NumPy leadership team to better guide and prioritize decision-making about the development of NumPy as software and a community. What started as a humble project by a dedicated core of user-developers has since transformed into a foundational component of the widely-adopted scientific Python ecosystem used by millions worldwide. To engage non-English speaking stakeholders, the inaugural NumPy community survey is offered in 7 additional languages: Bangla, Hindi, Japanese, Mandarin, Portuguese, Russian, and Spanish. The survey will take about 15 minutes of your time and close on July 17th. Click here <https://umdsurvey.umd.edu/jfe/form/SV_8bJrXjbhXf7saAl> to get started. Inessa Pawson NumPy Survey Team

1 0

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

Re: [Numpy-discussion] Python for Climate Action session at SciPy'20
by Inessa Pawson 02 Jul '20

02 Jul '20

Hi, Juan! I’m still in the process of scheduling live networking sessions at SciPy’20 and would be happy to set up one on the topic of Python for Climate Action. We could host it on July 8th or 10th at 5 - 6 p.m. CDT. Would you be available to moderate it? > ---------- Forwarded message ---------- > From: Juan Nunez-Iglesias <jni(a)fastmail.com> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Cc: > Bcc: > Date: Thu, 2 Jul 2020 18:58:11 +1000 > Subject: Re: [Numpy-discussion] Proposal to add clause to license > prohibiting use by oil and gas extraction companies > Hi everyone, > > If you live in Australia, this has been a rough year to think about > climate change. After the hottest and driest year on record, over 20% of > the forest surface area of the south east was burned in the bushfires. > Although I was hundreds of kilometres from the nearest fire, the air > quality was rated as hazardous for several days in my city. This brought > home for me two points. > > One, that "4ºC" is not about taking off a jumper and going to the beach > more often, but actually represents a complete transformation of our > planet. 4ºC is what separates us from the last ice age, so we can expect > our planet in 80 years to be as unrecognisable from today as today is from > the ice age. > > Two, that climate change is already with us, and we can't just continue to > ignore the problem and enjoy whatever years of climate peace we thought we > had left. Greta has it right, we are running out of time and absolutely > drastic action is needed. > > All this is a prelude to add my voice to everyone who has already said > that *messing with the NumPy license is absolutely *not* the drastic > action needed*, and will be counter-productive, as many have noted. > > Having said this, I'm happy that the community is getting involved and > getting active and coming up with creative ideas to do their part. If > someone wants to start a "Pythonistas for Climate Action" user group, I'll > be the first to join. I had planned to give a lightning talk in the vein of > the above at SciPy, which, and believe me that I hate to hate on my > favourite conference, recently loudly thanked Shell [1] for being a > platinum sponsor. (Not to mention that Enthought derives about a third of > its income from fossil fuel companies.) Unfortunately and for obvious > reasons I won't make it to SciPy after all, but again, I'm happy to see the > community rising. > > Perhaps this is derailing the discussion, but, anyone up for a "Python for > Climate Action" BoF at the conference? I can probably make the > late-afternoon BoFs given the time difference. > > Juan. > > [1]: https://twitter.com/SciPyConf/status/1276898138977193984 > > > -- Every good wish, *Inessa Pawson* Albus Code inessa(a)albuscode.org

3 2