From madicken.munk at gmail.com Mon Jun 1 01:53:52 2020 From: madicken.munk at gmail.com (Madicken Munk) Date: Mon, 1 Jun 2020 00:53:52 -0500 Subject: [Numpy-discussion] Extension: June 05 Deadline for the 2020 John Hunter Excellence in Plotting Contest! In-Reply-To: References: Message-ID: Hi all, We are extending the deadline of the contest to Friday, June 05. We look forward to receiving your submissions to the contest. John Hunter Excellence in Plotting Contest Co-Chairs Madicken Munk Nelle Varoquaux On Thu, May 28, 2020 at 12:18 AM Madicken Munk wrote: > Dear numpy community, > > > My apologies for repeated in-list and cross-list posts! > > > I'd like to remind everybody that the 2020 John Hunter Excellence in > Plotting Contest submission deadline is June 01 -- only a few days away. We > welcome and look forward to your submissions! > > > In memory of John Hunter, we are pleased to announce the John Hunter > Excellence in Plotting Contest for 2020. This open competition aims to > highlight the importance of data visualization to scientific progress and > showcase the capabilities of open source software. > > Participants are invited to submit scientific plots to be judged by a > panel. The winning entries will be announced and displayed at SciPy 2020 or > announced in the John Hunter Excellence in Plotting Contest website and > youtube channel. > > John Hunter?s family are graciously sponsoring cash prizes for the winners > in the following amounts: > > > - > > 1st prize: $1000 > - > > 2nd prize: $750 > - > > 3rd prize: $500 > > > > - > > Entries must be submitted by June 1st to the form at > https://forms.gle/SrexmkDwiAmDc7ej7 > - > > Winners will be announced at Scipy 2020 or publicly on the John Hunter > Excellence in Plotting Contest website and youtube channel > - > > Participants do not need to attend the Scipy conference. > - > > Entries may take the definition of ?visualization? rather broadly. > Entries may be, for example, a traditional printed plot, an interactive > visualization for the web, a dashboard, or an animation. > - > > Source code for the plot must be provided, in the form of Python code > and/or a Jupyter notebook, along with a rendering of the plot in a widely > used format. The rendering may be, for example, PDF for print, standalone > HTML and Javascript for an interactive plot, or MPEG-4 for a video. If the > original data can not be shared for reasons of size or licensing, "fake" > data may be substituted, along with an image of the plot using real data. > - > > Each entry must include a 300-500 word abstract describing the plot > and its importance for a general scientific audience. > - > > Entries will be judged on their clarity, innovation and aesthetics, > but most importantly for their effectiveness in communicating a real-world > problem. Entrants are encouraged to submit plots that were used during the > course of research or work, rather than merely being hypothetical. > - > > SciPy and the John Hunter Excellence in Plotting Contest organizers > reserves the right to display any and all entries, whether prize-winning or > not, at the conference, use in any materials or on its website, with > attribution to the original author(s). > - > > Past entries can be found at https://jhepc.github.io/ > - > > Questions regarding the contest can be sent to > jhepc.organizers at gmail.com > > > John Hunter Excellence in Plotting Contest Co-Chairs > > Madicken Munk > > Nelle Varoquaux > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.c.cooper at uconn.edu Mon Jun 1 14:17:55 2020 From: ryan.c.cooper at uconn.edu (Ryan C. Cooper) Date: Mon, 1 Jun 2020 14:17:55 -0400 (EDT) Subject: [Numpy-discussion] Numpy Documentation: How-to content Message-ID: > This sounds fantastic. Great! > In what context would the students be creating the notebooks -- as > part of one of your existing ME courses, as a for-credit project, as a > supervised but non-credit project? These would be supervised projects either for work-study or credit. > What were your thoughts on submission workflow? You review initially, > then the student directly submits a PR? My plan was to mentor the initial idea and creation and help the students submit PRs. For most, this will be their first interaction with Github. > Suppose several students want to create a notebook on the same topic. > Would you steer them to another topic, allow them to work > independently and both submit (and we merge best of both), urge them > to collaborate? My hope would be students that are passionate about the same topic could collaborate. I've had students collaborate on topic ideas for small projects that worked very well. > Were you planning to keep the mechanical engineering context for these > problems, or present abstractly? I?would plan to keep the How-to as an engineering application. It shouldn't detract from the underlying numerical work. From danny.fostiropoulos at gmail.com Mon Jun 1 14:22:25 2020 From: danny.fostiropoulos at gmail.com (Iordanis Fostiropoulos) Date: Mon, 1 Jun 2020 11:22:25 -0700 Subject: [Numpy-discussion] [Feature Request] Add alias of np.concatenate as np.concat Message-ID: 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). -------------- next part -------------- An HTML attachment was scrubbed... URL: From morph at debian.org Tue Jun 2 01:13:21 2020 From: morph at debian.org (Sandro Tosi) Date: Tue, 2 Jun 2020 01:13:21 -0400 Subject: [Numpy-discussion] (no subject) In-Reply-To: References: Message-ID: hey! On Sun, May 31, 2020 at 7:52 PM Charles R Harris wrote: > Downstream developers should use Cython >= 0.29.16 for Python 3.8 support and OpenBLAS >= 3.7 to avoid wrong results on the Skylake architecture. The NumPy Wheels for this release can be downloaded from PyPI, source archives and release notes are available from Github. just so that i can re-configure (if necessary) our automation in Debian, is this going to be the future setting for releasing numpy? wheels via PyPI and source via github? I stumbled upon this since there's no source release available on PyPI for 1.19.0rc2 Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi From ralf.gommers at gmail.com Tue Jun 2 03:29:41 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 2 Jun 2020 09:29:41 +0200 Subject: [Numpy-discussion] (no subject) In-Reply-To: References: Message-ID: On Tue, Jun 2, 2020 at 7:14 AM Sandro Tosi wrote: > hey! > > On Sun, May 31, 2020 at 7:52 PM Charles R Harris > wrote: > > Downstream developers should use Cython >= 0.29.16 for Python 3.8 > support and OpenBLAS >= 3.7 to avoid wrong results on the Skylake > architecture. The NumPy Wheels for this release can be downloaded from > PyPI, source archives and release notes are available from Github. > > just so that i can re-configure (if necessary) our automation in > Debian, is this going to be the future setting for releasing numpy? > wheels via PyPI and source via github? I stumbled upon this since > there's no source release available on PyPI for 1.19.0rc2 > That looks like a mistake. An sdist must be uploaded to PyPI, after the wheels are uploaded. That just seems to have been forgotten for rc2. Also, I had expected the sdist to be the .tar.gz format, I can't find it back but IIRC that's what we decided in the past. It's smaller, and it's what pretty much all other projects do. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Tue Jun 2 11:59:18 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 02 Jun 2020 10:59:18 -0500 Subject: [Numpy-discussion] NumPy Development Meeting Tomorrow - Triage Focus Message-ID: <8403224dcd3498473b53110b511b0849399a8ca2.camel@sipsolutions.net> Hi all, Our bi-weekly triage-focused NumPy development meeting is tomorrow (Wednesday, June 3rd) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From charlesr.harris at gmail.com Tue Jun 2 17:15:42 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 2 Jun 2020 15:15:42 -0600 Subject: [Numpy-discussion] (no subject) In-Reply-To: References: Message-ID: On Tue, Jun 2, 2020 at 1:31 AM Ralf Gommers wrote: > > > On Tue, Jun 2, 2020 at 7:14 AM Sandro Tosi wrote: > >> hey! >> >> On Sun, May 31, 2020 at 7:52 PM Charles R Harris >> wrote: >> > Downstream developers should use Cython >= 0.29.16 for Python 3.8 >> support and OpenBLAS >= 3.7 to avoid wrong results on the Skylake >> architecture. The NumPy Wheels for this release can be downloaded from >> PyPI, source archives and release notes are available from Github. >> >> just so that i can re-configure (if necessary) our automation in >> Debian, is this going to be the future setting for releasing numpy? >> wheels via PyPI and source via github? I stumbled upon this since >> there's no source release available on PyPI for 1.19.0rc2 >> > > That looks like a mistake. An sdist must be uploaded to PyPI, after the > wheels are uploaded. That just seems to have been forgotten for rc2. > > Also, I had expected the sdist to be the .tar.gz format, I can't find it > back but IIRC that's what we decided in the past. It's smaller, and it's > what pretty much all other projects do. > > NumPy has always used zip since PyPI limited the number of source releases. We did that before SciPy. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Tue Jun 2 17:19:11 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 2 Jun 2020 15:19:11 -0600 Subject: [Numpy-discussion] (no subject) In-Reply-To: References: Message-ID: On Tue, Jun 2, 2020 at 3:15 PM Charles R Harris wrote: > > > On Tue, Jun 2, 2020 at 1:31 AM Ralf Gommers > wrote: > >> >> >> On Tue, Jun 2, 2020 at 7:14 AM Sandro Tosi wrote: >> >>> hey! >>> >>> On Sun, May 31, 2020 at 7:52 PM Charles R Harris >>> wrote: >>> > Downstream developers should use Cython >= 0.29.16 for Python 3.8 >>> support and OpenBLAS >= 3.7 to avoid wrong results on the Skylake >>> architecture. The NumPy Wheels for this release can be downloaded from >>> PyPI, source archives and release notes are available from Github. >>> >>> just so that i can re-configure (if necessary) our automation in >>> Debian, is this going to be the future setting for releasing numpy? >>> wheels via PyPI and source via github? I stumbled upon this since >>> there's no source release available on PyPI for 1.19.0rc2 >>> >> >> That looks like a mistake. An sdist must be uploaded to PyPI, after the >> wheels are uploaded. That just seems to have been forgotten for rc2. >> >> Also, I had expected the sdist to be the .tar.gz format, I can't find it >> back but IIRC that's what we decided in the past. It's smaller, and it's >> what pretty much all other projects do. >> >> > NumPy has always used zip since PyPI limited the number of source > releases. We did that before SciPy. > > And I did upload the source file 947 twine upload release/installers/*.whl 948 twine upload release/installers/*.zip Wonder what happened to it? Maybe I missed an upload failure? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Tue Jun 2 20:26:48 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 2 Jun 2020 18:26:48 -0600 Subject: [Numpy-discussion] (no subject) In-Reply-To: References: Message-ID: On Tue, Jun 2, 2020 at 3:19 PM Charles R Harris wrote: > > > On Tue, Jun 2, 2020 at 3:15 PM Charles R Harris > wrote: > >> >> >> On Tue, Jun 2, 2020 at 1:31 AM Ralf Gommers >> wrote: >> >>> >>> >>> On Tue, Jun 2, 2020 at 7:14 AM Sandro Tosi wrote: >>> >>>> hey! >>>> >>>> On Sun, May 31, 2020 at 7:52 PM Charles R Harris >>>> wrote: >>>> > Downstream developers should use Cython >= 0.29.16 for Python 3.8 >>>> support and OpenBLAS >= 3.7 to avoid wrong results on the Skylake >>>> architecture. The NumPy Wheels for this release can be downloaded from >>>> PyPI, source archives and release notes are available from Github. >>>> >>>> just so that i can re-configure (if necessary) our automation in >>>> Debian, is this going to be the future setting for releasing numpy? >>>> wheels via PyPI and source via github? I stumbled upon this since >>>> there's no source release available on PyPI for 1.19.0rc2 >>>> >>> >>> That looks like a mistake. An sdist must be uploaded to PyPI, after the >>> wheels are uploaded. That just seems to have been forgotten for rc2. >>> >>> Also, I had expected the sdist to be the .tar.gz format, I can't find it >>> back but IIRC that's what we decided in the past. It's smaller, and it's >>> what pretty much all other projects do. >>> >>> >> NumPy has always used zip since PyPI limited the number of source >> releases. We did that before SciPy. >> >> > And I did upload the source file > > 947 twine upload release/installers/*.whl > 948 twine upload release/installers/*.zip > > Wonder what happened to it? Maybe I missed an upload failure? > > Should be fixed. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From morph at debian.org Tue Jun 2 21:28:20 2020 From: morph at debian.org (Sandro Tosi) Date: Tue, 2 Jun 2020 21:28:20 -0400 Subject: [Numpy-discussion] (no subject) In-Reply-To: References: Message-ID: > Should be fixed. indeed it is, thanks! -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi From derek at astro.physik.uni-goettingen.de Wed Jun 3 14:10:58 2020 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Wed, 3 Jun 2020 20:10:58 +0200 Subject: [Numpy-discussion] (no subject) In-Reply-To: References: Message-ID: On 2 Jun 2020, at 11:15 pm, Charles R Harris wrote: > >> Also, I had expected the sdist to be the .tar.gz format, I can't find it back but IIRC that's what we decided in the past. It's smaller, and it's what pretty much all other projects do. > > NumPy has always used zip since PyPI limited the number of source releases. We did that before SciPy. > The .tar.gz version (if file size really is an issue, why not using .tar.xz?) is also available from https://github.com/numpy/numpy/releases and already was before the PyPI upload was completed. Cheers, Derek From charlesr.harris at gmail.com Wed Jun 3 21:06:30 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Wed, 3 Jun 2020 19:06:30 -0600 Subject: [Numpy-discussion] NumPy 1.18.5 released Message-ID: Hi All, On behalf of the NumPy team I am pleased to announce the release of NumPy 1.18.5. This is a short release to enable pickle protocol=5 to be used in Python3.5 and is motivated by the recent backport of pickle5 to Python3.5. The Python versions supported in this release are 3.5-3.8. Downstream developers should use Cython >= 0.29.15 for Python 3.8 support and OpenBLAS >= 3.7 to avoid errors on the Skylake architecture. Wheels for this release can be downloaded from PyPI , source archives and release notes are available from Github . *Contributors* A total of 3 people contributed to this release. People with a \"+\" by their names contributed a patch for the first time. - Charles Harris - Matti Picus - Siyuan Zhuang + *Pull requests merged* A total of 2 pull requests were merged for this release. - #16439: ENH: enable pickle protocol 5 support for python3.5 - #16441: BUG: relpath fails for different drives on windows Cheers, Charles Harris -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Wed Jun 3 21:47:41 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Wed, 3 Jun 2020 19:47:41 -0600 Subject: [Numpy-discussion] (no subject) In-Reply-To: References: Message-ID: On Wed, Jun 3, 2020 at 12:34 PM Derek Homeier < derek at astro.physik.uni-goettingen.de> wrote: > On 2 Jun 2020, at 11:15 pm, Charles R Harris > wrote: > > > >> Also, I had expected the sdist to be the .tar.gz format, I can't find > it back but IIRC that's what we decided in the past. It's smaller, and it's > what pretty much all other projects do. > > > > NumPy has always used zip since PyPI limited the number of source > releases. We did that before SciPy. > > > The .tar.gz version (if file size really is an issue, why not using > .tar.xz?) is also available from > https://github.com/numpy/numpy/releases > and already was before the PyPI upload was completed. > The archive files automatically generated by Github are faulty and cannot be used, you need to use the ones uploaded later. I choose zip because it is universally available and since we can only put one source release on PyPI, that was my choice. Before PyPI adopted the single source policy we would upload both. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidhbansal at gmail.com Thu Jun 4 02:56:52 2020 From: sidhbansal at gmail.com (Sidhant Bansal) Date: Thu, 4 Jun 2020 14:56:52 +0800 Subject: [Numpy-discussion] Fixing fromfile to throw error when opening on gzip files Message-ID: In regard to the issue: https://github.com/numpy/numpy/issues/7713 And my corresponding PR: https://github.com/numpy/numpy/pull/16221 I was advised to put this on the mailing list to get a general sense of how the issue is affecting people and to discuss how I can improve the current PR. I am still interested in resolving this issue, so will be glad to do some re-work to be able to get this merged and fix the issue. The currently proposed PR is a kind of band-aid solution which uses an if-else chunk in the `fromfile` function's internal implementation to catch if the file opened is gzip type or not and throws an error. The drawback lies in the fact that we only are able to resolve gzip type issue and is not extendable to other high level file types which cant be opened. In my findings, I was unable to find a common distinguishing feature for those file types which cannot be opened using fromfile vs those which can be (ex. In a hypothetical situation one kind has the read method and other doesn't). Would love to hear what other people think and if they have any inputs about the what possible common distinguishing features can be there or if we should simply cross-check the file type against a hard-coded list of common high-level file types? Sidhant. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cv1038 at wildcats.unh.edu Thu Jun 4 10:01:36 2020 From: cv1038 at wildcats.unh.edu (cvav) Date: Thu, 4 Jun 2020 07:01:36 -0700 (MST) Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) Message-ID: <1591279296277-0.post@n7.nabble.com> 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/ From rakesh.nvasudev at gmail.com Fri Jun 5 00:15:03 2020 From: rakesh.nvasudev at gmail.com (Rakesh Vasudevan) Date: Thu, 4 Jun 2020 21:15:03 -0700 Subject: [Numpy-discussion] Improving Complex Comparison/Ordering in Numpy Message-ID: Hi all, As a follow up to gh-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 "", line 1, in 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbrockmendel at gmail.com Fri Jun 5 00:21:35 2020 From: jbrockmendel at gmail.com (Brock Mendel) Date: Thu, 4 Jun 2020 21:21:35 -0700 Subject: [Numpy-discussion] Improving Complex Comparison/Ordering in Numpy In-Reply-To: References: Message-ID: Corresponding pandas issue: https://github.com/pandas-dev/pandas/issues/28050 On Thu, Jun 4, 2020 at 9:17 PM Rakesh Vasudevan wrote: > Hi all, > > As a follow up to gh-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 "", line 1, in > 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 > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melissawm at gmail.com Fri Jun 5 12:33:44 2020 From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=) Date: Fri, 5 Jun 2020 13:33:44 -0300 Subject: [Numpy-discussion] Documentation Team meeting - Monday June 8th Message-ID: 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 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+Documentation+Team+Meeting&iso=20200608T15&p1=1440&ah=1 - Melissa -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Fri Jun 5 15:31:33 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Fri, 05 Jun 2020 14:31:33 -0500 Subject: [Numpy-discussion] Call for expertise: Blocked iteration Message-ID: Hi all, I am curious about exploring whether or not we could add simple blocked iteration to NumPy. It seems like a long standing small deficiency in NumPy that we do not support blocked iteration. I do not know how much speed gain we would actually have in real world code, but I assume some bad-memory-order copies could be drastically faster. Implementing blocked iteration for NumPy seems pretty complicated on first sight due to the complexity of the iterator and the fact that almost no-one knows the code well or touches it regularly. But, the actual complexity to add a new iteration mode to it is probably not forbiddingly high. First, we need to (quickly) find the cases where blocked iteration makes sense, and then, if it does, store whatever additional metadata is necessary. Second, we need to provide a newly implemented `iternext` function. The first chunk, seems like it can be done in its own function and should be fairly straight forward to do after most of the iterator setup is done. While the second part is already how the iterator is designed. It would be helpful to have someone with some expertise/brackground in this type of thing to be able discuss trade-offs and quickly see what the main goals should be and whether/where significant performance increases are likely. There are some things that may end up being complicated. For example, if we would want to support reductions/broadcasting. However, it may well be that there is no reason to attack those more complex cases, because the largest gains are expected elsewhere in any case. I would be extremely happy if anyone with the necessary background is interested in giving this challenge a try. I can help with the NumPy- API side, and code review and would be available for chatting/helping with the NumPy side. I do not have the bandwidth to actually dive into this for real though. Cheers, Sebastian [1] That is the complexity concerning the NumPy API. I do not know how complex a blocked iterator itself is. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rejones7 at msn.com Fri Jun 5 15:47:48 2020 From: rejones7 at msn.com (rondall jones) Date: Fri, 5 Jun 2020 19:47:48 +0000 Subject: [Numpy-discussion] introducing autoreg and autoregnn Message-ID: Hello! I have supported constrained solvers for linear matrix problems for about 10 years in C++, but have now switched to Python. I am going to submit a couple of new routines for linalg called autoreg(A,b) and autoregnn(A,b). They work just like lstsq(A,b) normally, but when they detect that the problem is dominated by noise they revert to an automatic regularization scheme that returns a better behaved result than one gets from lstsq. In addition, autoregnn enforces a nonnegativity constraint on the solution. I have put on my web site a slightly fuller featured version of these same two algorithms, using a Class implementation to facilitate retuning several diagnostic or other artifacts. The web site contains tutorials on these methods and a number of examples of their use. See http://www.rejones7.net/autorej/ . I hope this community can take a look at these routines and see whether they are appropriate for linalg or should be in another location. Ron Jones Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossbar15 at gmail.com Fri Jun 5 15:52:11 2020 From: rossbar15 at gmail.com (Ross Barnowski) Date: Fri, 5 Jun 2020 12:52:11 -0700 Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) In-Reply-To: <1591279296277-0.post@n7.nabble.com> References: <1591279296277-0.post@n7.nabble.com> Message-ID: On Thu, Jun 4, 2020 at 7:05 AM cvav wrote: > 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 > > This seems reasonable; in fact the addition of this normalization option was discussed in #2142, but there doesn't seem to have been a compelling use-case at that time. One potential issue that stood out to me was the name of the new keyword option. At face value, "inverse" seems like a poor choice given the established use of the term in Fourier analysis. For example, one might expect `norm="inverse"` to mean that scaling is applied to the ifft, when this is actually the current default. Ross Barnowski > > -- > Sent from: http://numpy-discussion.10968.n7.nabble.com/ > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cv1038 at wildcats.unh.edu Fri Jun 5 16:15:54 2020 From: cv1038 at wildcats.unh.edu (cvav) Date: Fri, 5 Jun 2020 13:15:54 -0700 (MST) Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) In-Reply-To: References: <1591279296277-0.post@n7.nabble.com> Message-ID: <1591388154629-0.post@n7.nabble.com> Ross Barnowski wrote > One potential issue that stood out to me was the name of the new keyword > option. At face value, "inverse" seems like a poor choice given the > established use of the term in Fourier analysis. For example, one might > expect `norm="inverse"` to mean that scaling is applied to the ifft, when > this is actually the current default. Yes that's true, the keyword argument name "inverse" is certainly something I don't feel sure about. It'd be nice if everyone interested could suggest names that make sense to them and what's their rationale behind them, so that we pick something that's as self explanatory as possible. My thinking was to indicate that it's the opposite scaling to the default option "None", so maybe something like "opposite" or "reversed" could be other choices. Otherwise, we can find something that directly describes the scaling and not its relationship to the default option. Chris -- Sent from: http://numpy-discussion.10968.n7.nabble.com/ From ralf.gommers at gmail.com Fri Jun 5 16:59:02 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 5 Jun 2020 22:59:02 +0200 Subject: [Numpy-discussion] introducing autoreg and autoregnn In-Reply-To: References: Message-ID: On Fri, Jun 5, 2020 at 9:48 PM rondall jones wrote: > Hello! I have supported constrained solvers for linear matrix problems for > about 10 years in C++, but have now switched to Python. I am going to > submit a couple of new routines for linalg called autoreg(A,b) and > autoregnn(A,b). They work just like lstsq(A,b) normally, but when they > detect that the problem is dominated by noise they revert to an automatic > regularization scheme that returns a better behaved result than one gets > from lstsq. In addition, autoregnn enforces a nonnegativity constraint on > the solution. I have put on my web site a slightly fuller featured version > of these same two algorithms, using a Class implementation to facilitate > retuning several diagnostic or other artifacts. The web site contains > tutorials on these methods and a number of examples of their use. See > http://www.rejones7.net/autorej/ . I hope this community can take a look > at these routines and see whether they are appropriate for linalg or should > be in another location. > Hi Ron, thanks for proposing this. It seems out of scope for NumPy; scipy.linalg or scipy.optimize seem like the most obvious candidates. If you propose inclusion into SciPy, it would be good to discuss whether the algorithm is based on a publication showing usage via citation stats or some other way. There's more details at http://scipy.github.io/devdocs/dev/core-dev/index.html#deciding-on-new-features Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfoxrabinovitz at gmail.com Fri Jun 5 22:40:40 2020 From: jfoxrabinovitz at gmail.com (Joseph Fox-Rabinovitz) Date: Fri, 5 Jun 2020 22:40:40 -0400 Subject: [Numpy-discussion] introducing autoreg and autoregnn In-Reply-To: References: Message-ID: Rondall, Are you familiar with the lmfit project? I am not an expert, but it seems like your algorithms may be useful there. I recommend checking with Matt Newville via the mailing list. Regards, Joe On Fri, Jun 5, 2020, 17:00 Ralf Gommers wrote: > > > On Fri, Jun 5, 2020 at 9:48 PM rondall jones wrote: > >> Hello! I have supported constrained solvers for linear matrix problems >> for about 10 years in C++, but have now switched to Python. I am going to >> submit a couple of new routines for linalg called autoreg(A,b) and >> autoregnn(A,b). They work just like lstsq(A,b) normally, but when they >> detect that the problem is dominated by noise they revert to an automatic >> regularization scheme that returns a better behaved result than one gets >> from lstsq. In addition, autoregnn enforces a nonnegativity constraint on >> the solution. I have put on my web site a slightly fuller featured version >> of these same two algorithms, using a Class implementation to facilitate >> retuning several diagnostic or other artifacts. The web site contains >> tutorials on these methods and a number of examples of their use. See >> http://www.rejones7.net/autorej/ . I hope this community can take a look >> at these routines and see whether they are appropriate for linalg or should >> be in another location. >> > > Hi Ron, thanks for proposing this. It seems out of scope for NumPy; > scipy.linalg or scipy.optimize seem like the most obvious candidates. > > If you propose inclusion into SciPy, it would be good to discuss whether > the algorithm is based on a publication showing usage via citation stats or > some other way. There's more details at > http://scipy.github.io/devdocs/dev/core-dev/index.html#deciding-on-new-features > > Cheers, > Ralf > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrin.jalali at gmail.com Sat Jun 6 08:57:30 2020 From: adrin.jalali at gmail.com (Adrin) Date: Sat, 6 Jun 2020 14:57:30 +0200 Subject: [Numpy-discussion] [Feature Request] Add alias of np.concatenate as np.concat In-Reply-To: References: Message-ID: This somehow also reminds me of the `__array_module__` (NEP37) protocol. I'm not sure if TF would ever implement it, but it would be really nice if the NEP37 proposal would move forward and libraries would implement it. On Mon, Jun 1, 2020 at 8:22 PM Iordanis Fostiropoulos < danny.fostiropoulos at gmail.com> wrote: > 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). > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Jun 6 10:21:03 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 6 Jun 2020 16:21:03 +0200 Subject: [Numpy-discussion] [Feature Request] Add alias of np.concatenate as np.concat In-Reply-To: References: Message-ID: On Sat, Jun 6, 2020 at 2:58 PM Adrin wrote: > This somehow also reminds me of the `__array_module__` (NEP37) protocol. > > I'm not sure if TF would ever implement it, but it would be really nice if > the NEP37 proposal > would move forward and libraries would implement it. > There is a plan to move forward with the various proposals on the array protocol front: https://github.com/numpy/archive/blob/master/other_meetings/2020-04-21-array-protocols_discussion_and_notes.md At this point I think it needs work to implement and exercise the alternatives, rather than a decision. > On Mon, Jun 1, 2020 at 8:22 PM Iordanis Fostiropoulos < > danny.fostiropoulos at gmail.com> wrote: > >> 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). >> > I don't think this is a good idea. We have a lot of poor function and object names, adding aliases for those isn't a healthy idea. `concatenate` is a good, descriptive name. Adding an alias for it just gives two equivalent ways of calling the same functionality, puts an extra burden on other libraries that want to be numpy-compatible, puts an extra burden on users that now see two similar function names (e.g. with tab completion) that they then need to look up to decide which one to use, and generally sets a bad precedent. Saving five characters is not a good enough reason to add an alias. I also don't see a reason to conform to TensorFlow (or PyTorch, or Matlab, or whichever other library). If we're adding a new function then yes by all means look at prior art, but here we have 15 years of existing uses of a sensibly named function. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From wieser.eric+numpy at gmail.com Sat Jun 6 10:43:20 2020 From: wieser.eric+numpy at gmail.com (Eric Wieser) Date: Sat, 6 Jun 2020 15:43:20 +0100 Subject: [Numpy-discussion] [Feature Request] Add alias of np.concatenate as np.concat In-Reply-To: References: Message-ID: I agree with all of Ralf's points, except for perhaps this one: > I also don't see a reason to conform to TensorFlow (or PyTorch, or Matlab, or whichever other library) Python itself has a name for this function, `operator.concat` - so _maybe_ this sets a strong enough precedent for us to add an alias. But we already diverge from the stardard library on things like `np.remainder` vs `math.remainder` - so my feeling is this still isn't worth it. Eric On Sat, Jun 6, 2020, 15:21 Ralf Gommers wrote: > > > On Sat, Jun 6, 2020 at 2:58 PM Adrin wrote: > >> This somehow also reminds me of the `__array_module__` (NEP37) protocol. >> >> I'm not sure if TF would ever implement it, but it would be really nice >> if the NEP37 proposal >> would move forward and libraries would implement it. >> > > There is a plan to move forward with the various proposals on the array > protocol front: > https://github.com/numpy/archive/blob/master/other_meetings/2020-04-21-array-protocols_discussion_and_notes.md > > At this point I think it needs work to implement and exercise the > alternatives, rather than a decision. > > >> On Mon, Jun 1, 2020 at 8:22 PM Iordanis Fostiropoulos < >> danny.fostiropoulos at gmail.com> wrote: >> >>> 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). >>> >> > I don't think this is a good idea. We have a lot of poor function and > object names, > adding aliases for those isn't a healthy idea. `concatenate` is a good, > descriptive name. > Adding an alias for it just gives two equivalent ways of calling the same > functionality, > puts an extra burden on other libraries that want to be numpy-compatible, > puts an extra burden on users that now see two similar function names > (e.g. with > tab completion) that they then need to look up to decide which one to use, > and generally sets a bad precedent. > > Saving five characters is not a good enough reason to add an alias. > > I also don't see a reason to conform to TensorFlow (or PyTorch, or Matlab, > or > whichever other library). If we're adding a new function then yes by all > means > look at prior art, but here we have 15 years of existing uses of a > sensibly named > function. > > Cheers, > Ralf > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rainwoodman at gmail.com Sun Jun 7 16:10:53 2020 From: rainwoodman at gmail.com (Feng Yu) Date: Sun, 7 Jun 2020 13:10:53 -0700 Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) In-Reply-To: <1591388154629-0.post@n7.nabble.com> References: <1591279296277-0.post@n7.nabble.com> <1591388154629-0.post@n7.nabble.com> Message-ID: Hi, 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as 'unitary'. Since we are in general working with complex numbers, I do suggest unitary over ortho. (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) and ( https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT) 2. I share Chris's concern about 'inverse', but I could not come up with a nice name. 3. Now that we are at this, should we also describe the corresponding continuum limit of FFT and iFFT in the documentation? A paragraph doing so could potentially also help people diagnose some of the normalization factor errors. I assumed it is common that one needs to translate a CFT into DFT when coding a paper up, and the correct compensation to the normalization factors will surface if one does the math. -- I had the impression 1 / N corresponds to 1 / 2pi if the variable is angular frequency, but it's been a while since I did that last time. - Yu On Fri, Jun 5, 2020 at 1:16 PM cvav wrote: > Ross Barnowski wrote > > One potential issue that stood out to me was the name of the new keyword > > option. At face value, "inverse" seems like a poor choice given the > > established use of the term in Fourier analysis. For example, one might > > expect `norm="inverse"` to mean that scaling is applied to the ifft, when > > this is actually the current default. > > Yes that's true, the keyword argument name "inverse" is certainly something > I don't feel sure about. It'd be nice if everyone interested could suggest > names that make sense to them and what's their rationale behind them, so > that we pick something that's as self explanatory as possible. > > My thinking was to indicate that it's the opposite scaling to the default > option "None", so maybe something like "opposite" or "reversed" could be > other choices. Otherwise, we can find something that directly describes the > scaling and not its relationship to the default option. > > Chris > > > > -- > Sent from: http://numpy-discussion.10968.n7.nabble.com/ > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Mon Jun 8 04:26:42 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 8 Jun 2020 10:26:42 +0200 Subject: [Numpy-discussion] Numpy Documentation: How-to content In-Reply-To: References: Message-ID: On Mon, Jun 1, 2020 at 8:18 PM Ryan C. Cooper wrote: > > This sounds fantastic. > > Great! > > > In what context would the students be creating the notebooks -- as > > part of one of your existing ME courses, as a for-credit project, as a > > supervised but non-credit project? > > These would be supervised projects either for work-study or credit. > > > What were your thoughts on submission workflow? You review initially, > > then the student directly submits a PR? > > My plan was to mentor the initial idea and creation and help the students > submit > PRs. For most, this will be their first interaction with Github. > > > Suppose several students want to create a notebook on the same topic. > > Would you steer them to another topic, allow them to work > > independently and both submit (and we merge best of both), urge them > > to collaborate? > > My hope would be students that are passionate about the same topic could > collaborate. I've had students collaborate on topic ideas for small > projects > that worked very well. > > > Were you planning to keep the mechanical engineering context for these > > problems, or present abstractly? > > I would plan to keep the How-to as an engineering application. It shouldn't > detract from the underlying numerical work. > This is something we've discussed before. It would be very useful to have such engineering applications. +1 for your proposal. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From cv1038 at wildcats.unh.edu Mon Jun 8 22:43:49 2020 From: cv1038 at wildcats.unh.edu (Chris Vavaliaris) Date: Mon, 8 Jun 2020 19:43:49 -0700 (MST) Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) In-Reply-To: References: <1591279296277-0.post@n7.nabble.com> <1591388154629-0.post@n7.nabble.com> Message-ID: <1591670629042-0.post@n7.nabble.com> Hello, - my first reaction would be that the less argument names we change at a time the better, so that we don't confuse people or cause codes written with previous NumPy versions to break. Personally I always think of "ortho" as "orthonormal", which immediately brings "unit norm" to mind, but I have no problem whatsoever with changing its name to "unitary" or maybe "unit", which I'd probably choose if we were writing the routines from scratch. - In terms of the "inverse" name option, I do believe that it'd be a confusing choice since "inverse" is used to describe the inverse FFT; if we choose to stick with a name that's based on the fact that this scaling is opposite to the "norm=None" option, then I'd suggest "norm=opposite" as a better choice. However, following Ross' comment, I think we could choose a name based on the fact that the forward transform is now scaled by `n`, instead of the backward one as in the default "norm=None". In this case, I'd suggest "norm=forward", which we can also nicely abbreviate to the 4-character form "norm=forw" if desirable. Chris Feng Yu wrote > Hi, > > 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as 'unitary'. > Since we are in general working with complex numbers, I do suggest unitary > over ortho. > (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) and ( > https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT) > > 2. I share Chris's concern about 'inverse', but I could not come up with a > nice name. > > 3. Now that we are at this, should we also describe the corresponding > continuum limit of FFT and iFFT in the documentation? > > A paragraph doing so could potentially also help people diagnose some of > the normalization factor errors. I assumed it is common that one needs to > translate a CFT into DFT when coding a paper up, and the correct > compensation to the normalization factors will surface if one does the > math. -- I had the impression 1 / N corresponds to 1 / 2pi if the variable > is angular frequency, but it's been a while since I did that last time. > > - Yu > > NumPy-Discussion mailing list > NumPy-Discussion@ > https://mail.python.org/mailman/listinfo/numpy-discussion -- Sent from: http://numpy-discussion.10968.n7.nabble.com/ From sebastian at sipsolutions.net Tue Jun 9 13:45:55 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 09 Jun 2020 12:45:55 -0500 Subject: [Numpy-discussion] NumPy Community Meeting Wednesday Message-ID: <75274813aa3eaa44fccefbd942b18df22befbd9a.camel@sipsolutions.net> Hi all, There will be a NumPy Community meeting Wednesday May 27th at 1pm Pacific Time (20:00 UTC [0]). 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From qiyu8f at gmail.com Thu Jun 11 07:47:58 2020 From: qiyu8f at gmail.com (ChunLin Fang) Date: Thu, 11 Jun 2020 19:47:58 +0800 Subject: [Numpy-discussion] Armv8 server donation Message-ID: Hi, all: I noticed that the shippable CI always skipped after PR submitted , The reason why it's skip seems to be "No active nodes found in shared node pool "shippable_shared_aarch64"" Potential bugs may buried through out numpy without shippable CI. I happened to own an idle armv8 server that can donate to numpy community, please let me know if that can improve numpy's CI/CD environment , also need somebody help me set up the CI/CD environment on that server. Best wishes Fang ChunLin. https://github.com/Qiyu8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Thu Jun 11 09:20:09 2020 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Thu, 11 Jun 2020 15:20:09 +0200 Subject: [Numpy-discussion] Armv8 server donation In-Reply-To: References: Message-ID: <8cb87a34-fb51-4175-9a83-214a0aeb93d5@www.fastmail.com> On Thu, Jun 11, 2020, at 13:47, ChunLin Fang wrote: > I noticed that the shippable CI always skipped after PR submitted , The reason why it's skip seems to be "No active nodes found in shared node pool "shippable_shared_aarch64"" > Potential bugs may buried through out numpy without shippable CI. > I happened to own an idle armv8 server that can donate to numpy community, please let me know if that can improve numpy's CI/CD environment , also need somebody help me set up the CI/CD environment on that server. Thank you for your kind offer! Someone else would be more qualified than I to comment on why the pool is empty, and what resources we have available. I know that AppVeyor allows you to host your own nodes, and it looks like Azure does too: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops https://www.appveyor.com/docs/server/#linux St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.k.sheppard at gmail.com Thu Jun 11 09:38:17 2020 From: kevin.k.sheppard at gmail.com (Kevin Sheppard) Date: Thu, 11 Jun 2020 14:38:17 +0100 Subject: [Numpy-discussion] Armv8 server donation In-Reply-To: <8cb87a34-fb51-4175-9a83-214a0aeb93d5@www.fastmail.com> References: <8cb87a34-fb51-4175-9a83-214a0aeb93d5@www.fastmail.com> Message-ID: Someone could setup https://drone.io/ which has both aarch64 and armv8l servers. I have used this service without issue in randomgen which requires building NumPy (but not testing it). On Thu, Jun 11, 2020 at 2:21 PM Stefan van der Walt wrote: > On Thu, Jun 11, 2020, at 13:47, ChunLin Fang wrote: > > I noticed that the shippable CI always skipped after PR submitted , > The reason why it's skip seems to be "No active nodes found in shared node > pool "shippable_shared_aarch64"" > Potential bugs may buried through out numpy without shippable CI. > I happened to own an idle armv8 server that can donate to numpy > community, please let me know if that can improve numpy's CI/CD environment > , also need somebody help me set up the CI/CD environment on that server. > > > Thank you for your kind offer! > > Someone else would be more qualified than I to comment on why the pool is > empty, and what resources we have available. > > I know that AppVeyor allows you to host your own nodes, and it looks like > Azure does too: > > > https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops > https://www.appveyor.com/docs/server/#linux > > St?fan > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Thu Jun 11 10:59:18 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Thu, 11 Jun 2020 09:59:18 -0500 Subject: [Numpy-discussion] Deprecating python type aliases (np.int, np.long, np.str, ...) Message-ID: Hi all, In the pull request: https://github.com/numpy/numpy/pull/14882 Eric proposes to deprecate the type aliases which NumPy imports into its main namespace (e.g. np.int, np.bool, see table below [1]). Right now there seems to be a consensus to move this forward and I plan on doing that, so this is a heads-up in case anyone has a differing opinion. The deprecation should not be very noisy as such, but I expect it will require many projects to update their code in the long run (although the changes are very simple). One advantage is that some aliases are confusing, e.g. `np.float` is Python float, and thus actually a `float64` and not a C `float`, which is a `float32`. For an example of how this affects a code-base, this is SciPy: https://github.com/scipy/scipy/pull/12344/commits/02def703b8b7b28ed315a658808364fd024bb45c (A chunk of the full PR unrelated style fixes). Cheers, Sebastian [1] Full table of deprecated aliases: ================== ===================== ============================ Deprecated Equivalent to Possibly intended numpy type ================== ===================== ============================ ``numpy.bool`` ``bool`` `numpy.bool_` ``numpy.int`` ``int`` `numpy.int_` (default int dtype), `numpy.cint` (C ``int``) ``numpy.float`` ``float`` `numpy.float_`, `numpy.double` (equivalent) ``numpy.complex`` ``complex`` `numpy.complex_`, `numpy.cdouble` (equivalent) ``numpy.object`` ``object`` `numpy.object_` ``numpy.str`` ``str`` `numpy.str_` ``numpy.long`` ``numpy.compat.long`` `numpy.int_` (C ``long``), `numpy.longlong` (largest integer type) ``numpy.unicode`` ``numpy.compat.str`` `numpy.unicode_` ================== ===================== ========================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From sebastian at sipsolutions.net Thu Jun 11 11:05:35 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Thu, 11 Jun 2020 10:05:35 -0500 Subject: [Numpy-discussion] Deprecating python type aliases (np.int, np.long, np.str, ...) In-Reply-To: References: Message-ID: On Thu, 2020-06-11 at 09:59 -0500, Sebastian Berg wrote: > Hi all, > > In the pull request: https://github.com/numpy/numpy/pull/14882 > Eric proposes to deprecate the type aliases which NumPy imports > into its main namespace (e.g. np.int, np.bool, see table below [1]). > > Right now there seems to be a consensus to move this forward and I > plan > on doing that, so this is a heads-up in case anyone has a differing > opinion. > > > The deprecation should not be very noisy as such, but I expect it > will Sorry, I made a mistake when considering the implementation. It may be fairly noisy, but it is also very easy to avoid for the user. > require many projects to update their code in the long run (although > the changes are very simple). > > One advantage is that some aliases are confusing, e.g. `np.float` is > Python float, and thus actually a `float64` and not a C `float`, > which > is a `float32`. > > For an example of how this affects a code-base, this is SciPy: > https://github.com/scipy/scipy/pull/12344/commits/02def703b8b7b28ed315a658808364fd024bb45c > (A chunk of the full PR unrelated style fixes). > > Cheers, > > Sebastian > > > [1] Full table of deprecated aliases: > > ================== ===================== ========================== > == > Deprecated Equivalent to Possibly intended numpy > type > ================== ===================== ========================== > == > ``numpy.bool`` ``bool`` `numpy.bool_` > ``numpy.int`` ``int`` `numpy.int_` (default int > dtype), `numpy.cint` (C ``int``) > ``numpy.float`` ``float`` `numpy.float_`, > `numpy.double` (equivalent) > ``numpy.complex`` ``complex`` `numpy.complex_`, > `numpy.cdouble` (equivalent) > ``numpy.object`` ``object`` `numpy.object_` > ``numpy.str`` ``str`` `numpy.str_` > ``numpy.long`` ``numpy.compat.long`` `numpy.int_` (C ``long``), > `numpy.longlong` (largest integer type) > ``numpy.unicode`` ``numpy.compat.str`` `numpy.unicode_` > ================== ===================== ========================== > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From tyler.je.reddy at gmail.com Sun Jun 14 00:17:28 2020 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Sat, 13 Jun 2020 22:17:28 -0600 Subject: [Numpy-discussion] ANN: SciPy 1.5.0rc2 -- please test Message-ID: Hi all, On behalf of the SciPy development team I'm pleased to announce the release candidate SciPy 1.5.0rc2. Please help us test this pre-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.0rc2 One of a few ways to install the release candidate with pip: pip install scipy==1.5.0rc2 ========================== SciPy 1.5.0 Release Notes ========================== .. note:: Scipy 1.5.0 is not released yet! .. contents:: SciPy 1.5.0 is the culmination of 6 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation. There have been a number of deprecations and API changes in this release, which are documented below. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Before upgrading, we recommend that users check that their own code does not use deprecated SciPy functionality (to do so, run your code with ``python -Wd`` and check for ``DeprecationWarning`` s). Our development attention will now shift to bug-fix releases on the 1.5.x branch, and on adding new features on the master branch. This release requires Python 3.6+ and NumPy 1.14.5 or greater. For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required. Highlights of this release - -------------------------- - - wrappers for more than a dozen new ``LAPACK`` routines are now available in `scipy.linalg.lapack` - - Improved support for leveraging 64-bit integer size from linear algebra backends - - addition of the probability distribution for two-sided one-sample Kolmogorov-Smirnov tests New features ============ `scipy.cluster` improvements - ------------------------------ Initialization of `scipy.cluster.vq.kmeans2` using ``minit="++"`` had a quadratic complexity in the number of samples. It has been improved, resulting in a much faster initialization with quasi-linear complexity. `scipy.cluster.hierarchy.dendrogram` now respects the ``matplotlib`` color palette `scipy.fft` improvements - ------------------------------ A new keyword-only argument ``plan`` is added to all FFT functions in this module. It is reserved for passing in a precomputed plan from libraries providing a FFT backend (such as ``PyFFTW`` and ``mkl-fft``), and it is currently not used in SciPy. `scipy.integrate` improvements - ------------------------------ `scipy.interpolate` improvements - -------------------------------- `scipy.io` improvements - ----------------------- `scipy.io.wavfile` error messages are more explicit about what's wrong, and extraneous bytes at the ends of files are ignored instead of raising an error when the data has successfully been read. `scipy.io.loadmat` gained a ``simplify_cells`` parameter, which if set to ``True`` simplifies the structure of the return value if the ``.mat`` file contains cell arrays. ``pathlib.Path`` objects are now supported in `scipy.io` Matrix Market I/O functions `scipy.linalg` improvements - --------------------------- `scipy.linalg.eigh` has been improved. Now various ``LAPACK`` drivers can be selected at will and also subsets of eigenvalues can be requested via ``subset_by_value`` keyword. Another keyword ``subset_by_index`` is introduced. Keywords ``turbo`` and ``eigvals`` are deprecated. Similarly, standard and generalized Hermitian eigenvalue ``LAPACK`` routines ``?evx`` are added and existing ones now have full ``_lwork`` counterparts. Wrappers for the following ``LAPACK`` routines have been added to `scipy.linalg.lapack`: - - ``?getc2``: computes the LU factorization of a general matrix with complete pivoting - - ``?gesc2``: solves a linear system given an LU factorization from ``?getc2`` - - ``?gejsv``: computes the singular value decomposition of a general matrix with higher accuracy calculation of tiny singular values and their corresponding singular vectors - - ``?geqrfp``: computes the QR factorization of a general matrix with non-negative elements on the diagonal of R - - ``?gtsvx``: solves a linear system with general tridiagonal matrix - - ``?gttrf``: computes the LU factorization of a tridiagonal matrix - - ``?gttrs``: solves a linear system given an LU factorization from ``?gttrf`` - - ``?ptsvx``: solves a linear system with symmetric positive definite tridiagonal matrix - - ``?pttrf``: computes the LU factorization of a symmetric positive definite tridiagonal matrix - - ``?pttrs``: solves a linear system given an LU factorization from ``?pttrf`` - - ``?pteqr``: computes the eigenvectors and eigenvalues of a positive definite tridiagonal matrix - - ``?tbtrs``: solves a linear system with a triangular banded matrix - - ``?csd``: computes the Cosine Sine decomposition of an orthogonal/unitary matrix Generalized QR factorization routines (``?geqrf``) now have full ``_lwork`` counterparts. `scipy.linalg.cossin` Cosine Sine decomposition of unitary matrices has been added. The function `scipy.linalg.khatri_rao`, which computes the Khatri-Rao product, was added. The new function `scipy.linalg.convolution_matrix` constructs the Toeplitz matrix representing one-dimensional convolution. `scipy.ndimage` improvements - ---------------------------- `scipy.optimize` improvements - ----------------------------- The finite difference numerical differentiation used in various ``minimize`` methods that use gradients has several new features: - - 2-point, 3-point, or complex step finite differences can be used. Previously only a 2-step finite difference was available. - - There is now the possibility to use a relative step size, previously only an absolute step size was available. - - If the ``minimize`` method uses bounds the numerical differentiation strictly obeys those limits. - - The numerical differentiation machinery now makes use of a simple cache, which in some cases can reduce the number of function evaluations. - - ``minimize``'s ``method= 'powell'`` now supports simple bound constraints There have been several improvements to `scipy.optimize.linprog`: - - The ``linprog`` benchmark suite has been expanded considerably. - - ``linprog``'s dense pivot-based redundancy removal routine and sparse presolve are faster - - When ``scikit-sparse`` is available, solving sparse problems with ``method='interior-point'`` is faster The caching of values when optimizing a function returning both value and gradient together has been improved, avoiding repeated function evaluations when using a ``HessianApproximation`` such as ``BFGS``. ``differential_evolution`` can now use the modern ``np.random.Generator`` as well as the legacy ``np.random.RandomState`` as a seed. `scipy.signal` improvements - --------------------------- A new optional argument ``include_nyquist`` is added to ``freqz`` functions in this module. It is used for including the last frequency (Nyquist frequency). `scipy.signal.find_peaks_cwt` now accepts a ``window_size`` parameter for the size of the window used to calculate the noise floor. `scipy.sparse` improvements - --------------------------- Outer indexing is now faster when using a 2d column vector to select column indices. `scipy.sparse.lil.tocsr` is faster Fixed/improved comparisons between pydata sparse arrays and sparse matrices BSR format sparse multiplication performance has been improved. `scipy.sparse.linalg.LinearOperator` has gained the new ``ndim`` class attribute `scipy.spatial` improvements - ---------------------------- `scipy.spatial.geometric_slerp` has been added to enable geometric spherical linear interpolation on an n-sphere `scipy.spatial.SphericalVoronoi` now supports calculation of region areas in 2D and 3D cases The tree building algorithm used by ``cKDTree`` has improved from quadratic worst case time complexity to loglinear. Benchmarks are also now available for building and querying of balanced/unbalanced kd-trees. `scipy.special` improvements - ---------------------------- The following functions now have Cython interfaces in `cython_special`: - - `scipy.special.erfinv` - - `scipy.special.erfcinv` - - `scipy.special.spherical_jn` - - `scipy.special.spherical_yn` - - `scipy.special.spherical_in` - - `scipy.special.spherical_kn` `scipy.special.log_softmax` has been added to calculate the logarithm of softmax function. It provides better accuracy than ``log(scipy.special.softmax(x))`` for inputs that make softmax saturate. `scipy.stats` improvements - -------------------------- The function for generating random samples in `scipy.stats.dlaplace` has been improved. The new function is approximately twice as fast with a memory footprint reduction between 25 % and 60 % (see gh-11069). `scipy.stats` functions that accept a seed for reproducible calculations using random number generation (e.g. random variates from distributions) can now use the modern ``np.random.Generator`` as well as the legacy ``np.random.RandomState`` as a seed. The ``axis`` parameter was added to `scipy.stats.rankdata`. This allows slices of an array along the given axis to be ranked independently. The ``axis`` parameter was added to `scipy.stats.f_oneway`, allowing it to compute multiple one-way ANOVA tests for data stored in n-dimensional arrays. The performance of ``f_oneway`` was also improved for some cases. The PDF and CDF methods for ``stats.geninvgauss`` are now significantly faster as the numerical integration to calculate the CDF uses a Cython based ``LowLevelCallable``. Moments of the normal distribution (`scipy.stats.norm`) are now calculated using analytical formulas instead of numerical integration for greater speed and accuracy Moments and entropy trapezoidal distribution (`scipy.stats.trapz`) are now calculated using analytical formulas instead of numerical integration for greater speed and accuracy Methods of the truncated normal distribution (`scipy.stats.truncnorm`), especially ``_rvs``, are significantly faster after a complete rewrite. The `fit` method of the Laplace distribution, `scipy.stats.laplace`, now uses the analytical formulas for the maximum likelihood estimates of the parameters. Generation of random variates is now thread safe for all SciPy distributions. 3rd-party distributions may need to modify the signature of the ``_rvs()`` method to conform to ``_rvs(self, ..., size=None, random_state=None)``. (A one-time VisibleDeprecationWarning is emitted when using non-conformant distributions.) The Kolmogorov-Smirnov two-sided test statistic distribution (`scipy.stats.kstwo`) was added. Calculates the distribution of the K-S two-sided statistic ``D_n`` for a sample of size n, using a mixture of exact and asymptotic algorithms. The new function ``median_abs_deviation`` replaces the deprecated ``median_absolute_deviation``. The ``wilcoxon`` function now computes the p-value for Wilcoxon's signed rank test using the exact distribution for inputs up to length 25. The function has a new ``mode`` parameter to specify how the p-value is to be computed. The default is ``"auto"``, which uses the exact distribution for inputs up to length 25 and the normal approximation for larger inputs. Added a new Cython-based implementation to evaluate guassian kernel estimates, which should improve the performance of ``gaussian_kde`` The ``winsorize`` function now has a ``nan_policy`` argument for refined handling of ``nan`` input values. The ``binned_statistic_dd`` function with ``statistic="std"`` performance was improved by ~4x. ``scipy.stats.kstest(rvs, cdf,...)`` now handles both one-sample and two-sample testing. The one-sample variation uses `scipy.stats.ksone` (or `scipy.stats.kstwo` with back off to `scipy.stats.kstwobign`) to calculate the p-value. The two-sample variation, invoked if ``cdf`` is array_like, uses an algorithm described by Hodges to compute the probability directly, only backing off to `scipy.stats.kstwo` in case of overflow. The result in both cases is more accurate p-values, especially for two-sample testing with smaller (or quite different) sizes. `scipy.stats.maxwell` performance improvements include a 20 % speed up for `fit()`` and 5 % for ``pdf()`` `scipy.stats.shapiro` and `scipy.stats.jarque_bera` now return a named tuple for greater consistency with other ``stats`` functions Deprecated features =================== `scipy` deprecations - -------------------- `scipy.special` changes - ----------------------- The ``bdtr``, ``bdtrc``, and ``bdtri`` functions are deprecating non-negative non-integral ``n`` arguments. `scipy.stats` changes - --------------------- The function ``median_absolute_deviation`` is deprecated. Use ``median_abs_deviation`` instead. The use of the string ``"raw"`` with the ``scale`` parameter of ``iqr`` is deprecated. Use ``scale=1`` instead. Backwards incompatible changes ============================== `scipy.interpolate` changes - --------------------------- `scipy.linalg` changes - ---------------------- The output signatures of ``?syevr``, ``?heevr`` have been changed from ``w, v, info`` to ``w, v, m, isuppz, info`` The order of output arguments ``w``, ``v`` of ``{gv, gvd, gvx}`` is swapped. `scipy.signal` changes - ---------------------- The output length of `scipy.signal.upfirdn` has been corrected, resulting outputs may now be shorter for some combinations of up/down ratios and input signal and filter lengths. `scipy.signal.resample` now supports a ``domain`` keyword argument for specification of time or frequency domain input. `scipy.stats` changes - --------------------- Other changes ============= Improved support for leveraging 64-bit integer size from linear algebra backends in several parts of the SciPy codebase. Shims designed to ensure the compatibility of SciPy with Python 2.7 have now been removed. Many warnings due to unused imports and unused assignments have been addressed. Many usage examples were added to function docstrings, and many input validations and intuitive exception messages have been added throughout the codebase. Early stage adoption of type annotations in a few parts of the codebase Authors ======= * @endolith * Hameer Abbasi * ADmitri + * Wesley Alves + * Berkay Antmen + * Sylwester Arabas + * Arne K?derle + * Christoph Baumgarten * Peter Bell * Felix Berkenkamp * Jord?o Bragantini + * Clemens Brunner + * Evgeni Burovski * Matthias Bussonnier + * CJ Carey * Derrick Chambers + * Leander Claes + * Christian Clauss * Luigi F. Cruz + * dankleeman * Andras Deak * Milad Sadeghi DM + * jeremie du boisberranger + * Stefan Endres * Malte Esders + * Leo Fang + * felixhekhorn + * Isuru Fernando * Andrew Fowlie * Lakshay Garg + * Gaurav Gijare + * Ralf Gommers * Emmanuelle Gouillart + * Kevin Green + * Martin Grignard + * Maja Gwozdz * Sturla Molden * gyu-don + * Matt Haberland * hakeemo + * Charles Harris * Alex Henrie * Santi Hernandez + * William Hickman + * Till Hoffmann + * Joseph T. Iosue + * Anany Shrey Jain * Jakob Jakobson * Charles Jekel + * Julien Jerphanion + * Jiacheng-Liu + * Christoph Kecht + * Paul Kienzle + * Reidar Kind + * Dmitry E. Kislov + * Konrad + * Konrad0 * Takuya KOUMURA + * Krzysztof Pi?ro * Peter Mahler Larsen * Eric Larson * Antony Lee * Gregory Lee + * Gregory R. Lee * Chelsea Liu * Cong Ma + * Kevin Mader + * Maja Gw??d? + * Alex Marvin + * Matthias K?mmerer * Nikolay Mayorov * Mazay0 + * G. D. McBain * Nicholas McKibben + * Sabrina J. Mielke + * Sebastian J. Mielke + * Milo? Komar?evi? + * Shubham Mishra + * Santiago M. Mola + * Grzegorz Mrukwa + * Peyton Murray * Andrew Nelson * Nico Schl?mer * nwjenkins + * odidev + * Sambit Panda * Vikas Pandey + * Rick Paris + * Harshal Prakash Patankar + * Balint Pato + * Matti Picus * Ilhan Polat * poom + * Siddhesh Poyarekar * Vladyslav Rachek + * Bharat Raghunathan * Manu Rajput + * Tyler Reddy * Andrew Reed + * Lucas Roberts * Ariel Rokem * Heshy Roskes * Matt Ruffalo * Atsushi Sakai + * Benjamin Santos + * Christoph Schock + * Lisa Schwetlick + * Chris Simpson + * Leo Singer * Kai Striega * S?ren Fuglede J?rgensen * Kale-ab Tessera + * Seth Troisi + * Robert Uhl + * Paul van Mulbregt * Vasiliy + * Isaac Virshup + * Pauli Virtanen * Shakthi Visagan + * Jan Vleeshouwers + * Sam Wallan + * Lijun Wang + * Warren Weckesser * Richard Weiss + * wenhui-prudencemed + * Eric Wieser * Josh Wilson * James Wright + * Ruslan Yevdokymov + * Ziyao Zhang + A total of 129 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.0 - ----------------------- * `#1455 `__: ellipord does returns bogus values if gstop or gpass are negative... * `#1968 `__: correlate2d's output does not agree with correlate's output in... * `#2744 `__: BUG: optimize: '\*\*kw' argument of 'newton_krylov' is not documented * `#4755 `__: TypeError: data type "`__: scipy.optimize maxiter option not working as expected * `#5144 `__: RuntimeWarning on csgraph.shortest_path when edge lengths are... * `#5309 `__: Documentation of 'hybr' and 'lm' inconsistent in optimize.root * `#6026 `__: Replace approx_grad with _numdiff.approx_derivative in scipy.optimize * `#6502 `__: Computing Eigenvalues in an Interval with LAPACK * `#7058 `__: Errors in special.bdtri and special.bdtr for non-integer k values * `#7700 `__: SuperLU does not respect perm_c="NATURAL" * `#7895 `__: Improvements to io.loadmat * `#8205 `__: ValueError in scipy.linalg.eigvalsh for large matrix * `#8278 `__: Memory limit for scipy.sparse.linalg.spsolve with scikit-umfpack * `#8327 `__: scipy.stats.mstats.winsorize NaN handling * `#8341 `__: scipy.stats.ks_2samp for masked and unmasked data give different... * `#8748 `__: scipy.stats.kstest for same distribution: p-values nonuniform * `#9042 `__: optimize: Incorrect statement about \`jac\` in the \`minimize\`... * `#9197 `__: problem with scipy.signal.butter with 1000+ points array * `#9212 `__: EIGH very very slow --> suggesting an easy fix * `#9553 `__: ndimage routines behave badly when output has memory overlap... * `#9632 `__: ndimage.maximum_filter undocumented behaviour using footprint... * `#9658 `__: `scipy.optimize.minimize(method='COBYLA')` not threadsafe * `#9710 `__: stats.weightedtau([1], [1.0]) SEGFAULTs * `#9797 `__: Master Tracker for some Kolmogorov-Smirnov test Issues * `#9844 `__: scipy.signal.upfirdn gives different length matrix versus MATLAB... * `#9872 `__: scipy.signal.convolve is slower when vectorized * `#9913 `__: BUG: No dt in StateSpace operations * `#10014 `__: Distribution names \`weibull_min\`and \`weibull_max\` should... * `#10159 `__: BUG: stats: chisquare returns incorrect results for arrays of... * `#10302 `__: scipy.fft: Add a \`plan\` argument * `#10332 `__: 'Incomplete wav chunk' inconsistent/reason unknown * `#10441 `__: Remove uses of \`numpy.dual\`? * `#10558 `__: Document implicit sum in csr_matrix() constructor * `#10788 `__: LU with full pivoting * `#10841 `__: Unexpected behavior in linalg.blas.dtrmm wrapper * `#10919 `__: optimize._lbfgsb setulb() function violates parameter bounds * `#10963 `__: kstest, ks_2samp: confusing \`mode\` argument descriptions * `#11022 `__: Unexpected Result in factorial function with NaN input * `#11028 `__: Documentation error in optimize.minimize * `#11058 `__: Adding logsoftmax function * `#11076 `__: ValueError: Unknown wave file format * `#11090 `__: Misconception of the median absolute deviation in stats? * `#11095 `__: BUG: find_peaks_cwt test failures in 32-bit Linux wheels * `#11107 `__: scipy.io.mmread generated an error "TypeError: startswith first... * `#11123 `__: Add wrapper for ?gttrf/?gttrs * `#11128 `__: OverflowError in resample_poly (upfirdn) * `#11132 `__: Possible bug: rv_discret.ppf for percentiles 0 and 100 and loc... * `#11163 `__: Comparisons between scipy spmatrix and can sparse.SparseArray... * `#11168 `__: Generalized Pareto variance inaccurate for concentrations near... * `#11169 `__: Add wrapper for ?geqrfp * `#11184 `__: 2-sided Kolmogorov Smirnov returns p-value of 1 * `#11185 `__: The .roots() or solve() function of scipy.interpolate.CubicHermiteSpline... * `#11190 `__: Add wrapper for ?tbtrs * `#11200 `__: Can no longer slice csr_matrix in 1.3.0 * `#11207 `__: _minimize_scalar_bounded: reference before assignment * `#11216 `__: linprog: interior-point: Cholmod reordering can be reused * `#11223 `__: Add wrappers for ?pttrf, ?pttrs * `#11224 `__: Add wrapperfor ?pteqr * `#11235 `__: MAINT: Missleading Error Message for IIR Filter * `#11244 `__: Missing reference in \`scipy.optimize.line_search\` * `#11262 `__: Hermitian Eigenvalue Problem eigh() API and wrapper change proposal * `#11266 `__: Sparse matrix constructor data type detection changes on Numpy... * `#11270 `__: CI failing: Travis CI Py36 refguide and Linux_Python_36_32bit_full... * `#11279 `__: linalg.eigh checks whole array for finite values * `#11295 `__: CI: azure does not auto-cancel old jobs on pushes * `#11299 `__: stats.truncnorm.rvs 100x slower in v1.4.x than v1.3.3 * `#11315 `__: BUG: special: rgamma on negative integers smaller -34 * `#11319 `__: Missing \`int64_t\` declaration in rectangular_lsap.cpp * `#11323 `__: Compilation failure due to missing symbol pthread_atfork * `#11332 `__: BUG: directed_hausdorff distance on sets u and v when u is a... * `#11350 `__: Khatri-Rao product * `#11354 `__: ENH: Add wrapper for ?gejsv * `#11361 `__: Dropped NaN in eval_genlaguerre function * `#11363 `__: Dropped NaN in hyperu function * `#11365 `__: scipy.stats.binned_statistic regressed in v1.4.0 * `#11369 `__: Dropped NaN in eval_hermite * `#11370 `__: Dropped NaN in eval_gegenbauer * `#11373 `__: Add wrapper for ?gtsvx * `#11374 `__: Add wrapper for ?ptsvx * `#11391 `__: csgraph.minimum_spanning_tree loses precision * `#11398 `__: Update stats to cope with \`np.random.Generator\` machinery * `#11412 `__: Array copying causes unwanted type casting from complex to float... * `#11415 `__: Where is the Wiener Filter derived from? * `#11416 `__: _lib._util.getargspec_no_self is missing KEYWORD_ONLY support * `#11428 `__: Documentation on SHGO inequality constraints appears contradictory * `#11429 `__: Add LAPACK's ZUNCSD cosine sine decomposition * `#11438 `__: run_dualannealing passes bounds incorrectly in benchmarks/optimize.py * `#11441 `__: Can't run optimize benchmarks * `#11442 `__: Chebyshev weights * `#11448 `__: Wrongly typed comparison in integrate.quad * `#11458 `__: BUG: maximum_bipartite_matching produces infeasible solution * `#11460 `__: CI failing: 2 Travis CI tests fail with numpy build or version... * `#11462 `__: Bug on "++" initialization on "kmeans2" * `#11464 `__: Shouldn't data type of KDE evaluation should be like in the input... * `#11468 `__: performance of binned_statistics_2d 100x slowdown from 1.3.2... * `#11484 `__: Callback function doesn't give the same value as the one being... * `#11492 `__: Confusing dendrogram labelling * `#11493 `__: scipy.optimize.least_squares fails if the return array of the... * `#11494 `__: Error performing kronecker product between large sparse vectors * `#11503 `__: medfilt produces 0 on input of length 1 * `#11529 `__: Pyflakes generates almost 700 warnings. * `#11566 `__: irfft/irfft2/irfftn docs are slightly confusing re: input type. * `#11572 `__: least_squares: too small tolerances not catched with method='lm' * `#11581 `__: DOC: scipy.interpolate.RectSphereBivariateSpline * `#11586 `__: Differential evolution breaks with LinearConstraints with sparse... * `#11595 `__: scipy.spatial.cKDTree construction slow for some datasets * `#11598 `__: output of special.voigt_profile when sigma=0 * `#11601 `__: linalg tests failing in runtests.py * `#11602 `__: scipy.optimize.linear_sum_assignment returns reverse diagonal... * `#11610 `__: Analytic formula for normal moments * `#11611 `__: Build failure with gfortran 10 * `#11613 `__: TST, MAINT: test_quadpack TestCtypesQuad wasn't fully migrated... * `#11630 `__: SmoothBivariateSpline bbox parameter * `#11635 `__: typo in docstring of scipy.stats.norminvgauss * `#11637 `__: BUG: core dumps when calling scipy.interpolate.interp1d with... * `#11638 `__: better documentation for 'return_all' option in minimize(Nelder... * `#11652 `__: TST, MAINT: CI failures for pre-release NumPy wheels * `#11659 `__: optimize.fmin_l_bfgs_b needs bound check and appropiate error... * `#11660 `__: BUG/ENH: distribution.ncf with nc=0 returns nan * `#11661 `__: scipy.ndimage.convolve1d and correlate1d don't behave properly... * `#11669 `__: p-value varies with the order of the data * `#11676 `__: documentation of scipy.spatial.HalfspaceIntersection: wrong method... * `#11685 `__: Rotation cannot be expressed as matrix * `#11686 `__: MAINT: mypy imports of Cython "modules" * `#11693 `__: TestDifferentialEvolutionSolver::test_L4 failing in CI * `#11696 `__: DOC: incorrect compiler information for macOS in docs * `#11709 `__: eigh() tests fail to pass, crash Python with seemingly ramdom... * `#11763 `__: Small error in gamma continuous rv fit comments * `#11769 `__: truncnorm.rvs Weird Behaviors * `#11770 `__: crash in TestEigh::test_value_subsets * `#11795 `__: trapz distribution mean computed using single precision * `#11800 `__: Segmentation fault in scipy.odr for multidimensional independent... * `#11811 `__: pyflakes silently failing on travis-ci * `#11826 `__: Error with _fblas * `#11827 `__: \`fft.tests.test_numpy.test_multiprocess\` hangs on Python3.8... * `#11835 `__: tests with \`multiprocessing\` hang on Python 3.8 on macOS * `#11839 `__: linalg.expm returns nans with RuntimeWarning: overflow encountered... * `#11856 `__: Documentation of fit methods for \`weibull_min\` and \`exponweib\`... * `#11868 `__: Function always evaluated twice when using HessianUpdateStrategy... * `#11875 `__: Typo in the docstring of simps() * `#11877 `__: kmeans2 '++' method is orders of magnitude slower than sklearn.cluster.KMeans() * `#11884 `__: The upper code lines are dead code * `#11886 `__: Array shape mismatch in scipy.optimize * `#11892 `__: BUG: stats: Incorrect handling of edges cases by ttest_rel and... * `#11908 `__: LinearOperator should have ndim attribute * `#11910 `__: Documentation missing for what M is in init argument * `#11922 `__: macOS actions CI has started failing in last couple of days. * `#11928 `__: DOC: signal: Wrong description for sepfir2d, cspline2d, qspline2d * `#11944 `__: curve_fit documentation unclear on default value of absolute_sigma * `#11945 `__: Add a (potentially temporary) py.typed file? * `#11949 `__: ValueError 'k exceeds matrix dimensions' for sparse.diagonal()... * `#11951 `__: BUG: asv benchmark failed because of cython version * `#11967 `__: BLD: Azure windows runs complain about drives * `#11973 `__: oaconvolve(a,b,'same') differs in shape from convolve(a,b,'same')... * `#12002 `__: pybind11 license * `#12003 `__: MAINT: circular SphericalVoronoi input * `#12015 `__: Reordering of CSC matrix breaks when you go above int32 limits * `#12031 `__: Documentation Rendering Issues Visible in CircleCI Artifacts * `#12037 `__: MAINT, CI: new Cython 3.0a4 issue * `#12087 `__: DOC: some odr models are missing docs * `#12119 `__: signal.fftconvolve no longer convolves types f8 and numpy.float64 * `#12149 `__: Documentation of Rosenbrock function * `#12173 `__: Large memory usage when indexing sparse matrices with \`np.ix_\` * `#12178 `__: BUG: stats: Some discrete distributions don't accept lists of... * `#12220 `__: BUG, REL: gh_lists.py compromised scraping * `#12239 `__: BUG: median absolute deviation handling of nan * `#12301 `__: integer overflow in scipy.sparse.sputils.check_shape when matrix size > 2^32 * `#12314 `__: scipy.spatial.transform.Rotation multiplication does not normalize quaternion Pull requests for 1.5.0 - ----------------------- * `#6510 `__: Add Eigenvalue Range Functionality for Symmetric Eigenvalue Problems * `#9525 `__: BUG: SuperLU 'NATURAL' order applies a column permutation * `#9634 `__: Add the number of Jacobian evaluations to the output of L-BFGS-B. * `#9719 `__: ENH: Added kstwo probability distribution for two-sided one-sample... * `#9783 `__: WIP: optimize: added (dense) interpolative decomposition redundancy... * `#10053 `__: Adding docstring to weibull_min and weibull_max based on issue... * `#10136 `__: DEP: Add warning to linprog_verbose_callback * `#10380 `__: ENH: add geometric_slerp * `#10602 `__: MAINT: optimize: refactor common linprog arguments into namedtuple * `#10648 `__: Bounds for the Powell minimization method * `#10673 `__: ENH: approx_fprime --> approx_derivative * `#10759 `__: ENH: calculation of region areas in spatial.SphericalVoronoi * `#10762 `__: BENCH: optimize: more comprehensive linprog benchmarking * `#10796 `__: ENH exact p-values of wilcoxon test in scipy.stats * `#10797 `__: ENH: linalg: LU with full pivoting (wrappers for ?getc2/?gesc2) * `#10824 `__: ENH: Fast gaussian kernel estimator * `#10942 `__: BUG: prevent bound violation in L-BFGS-B optimize method * `#11003 `__: ENH: add scipy.linalg.convolution_matrix * `#11023 `__: improving error message for cubic-interpolate with duplicates * `#11045 `__: MAINT: make bdt{r,rc,ri}() functions accept double n,k args +... * `#11063 `__: Fix documentation error in optimize.minimize * `#11069 `__: ENH: stats.dlaplace.rvs improvements * `#11071 `__: DOC: Added examples to maximum_position in ndimage * `#11075 `__: DOC: Update stylistic consistency in multiple files * `#11097 `__: BUG: stats: fixing chisquare to return correct results for arrays... * `#11110 `__: ENH: special: Cythonise erfinv, erfcinv * `#11112 `__: BUG: special: Return NaN outside the domain of \`eval_hermite\` * `#11114 `__: BUG: special: fix \`hyp1f1\` for nonnegative integral \`a\` and... * `#11115 `__: DOC: special: add docstrings for \`kei\`, \`ker\`, \`keip\`,... * `#11130 `__: ENH: support for circular input * `#11136 `__: BUG: expm handling of empty input * `#11138 `__: DOC: stylistic consistency, punctuation, etc. * `#11139 `__: MAINT: cluster: use cython_blas, remove handwritten BLAS wrappers * `#11146 `__: DOC: update docs on bp parameter for detrend * `#11151 `__: DOC: special: add docstrings for \`bei\`, \`ber\`, \`beip\`,... * `#11156 `__: ENH: add input validation for ellipord. * `#11157 `__: DOC: stylistic revision, punctuation, consistency * `#11160 `__: ignore warning on 0 \* inf in basin hopping * `#11162 `__: DOC: minor stylistic revision, undo changes * `#11164 `__: ENH/ BUG: Pydata sparse equality * `#11171 `__: Fix dtype validation of "seuclidean" metric V parameter * `#11177 `__: BUG: stats: Improve genpareto stats calculations. * `#11180 `__: MAINT: stats: Some clean up in test_distributions.py. * `#11187 `__: ENH: add functionality log_softmax to SciPy.special. * `#11188 `__: MAINT: add rvs method to argus in scipy.stats * `#11196 `__: DOC: special: add to docstrings of Kelvin zeros functions * `#11202 `__: BUG: fix edge counting in shortest_path * `#11218 `__: BUG: scipy/interpolate: fix PPoly/Cubic\*Spline roots() extrapolation... * `#11225 `__: Add a warning to constant input for spearmanr() function * `#11226 `__: Speed up of interior-point method for cholesky solver * `#11229 `__: BUG: Explicit dtype specification in _upfirdn.py * `#11230 `__: Additional citation for optimize tutorial * `#11231 `__: Adds SLSQP test for duplicate f-evals (#10738) * `#11236 `__: MAINT: Improved error message for Wn range in iirfilter. * `#11245 `__: ENH: optimize: dense redundancy removal routine optimizations * `#11247 `__: MAINT: Remove _lib/_numpy_compat.py * `#11248 `__: BUG: rv_discrete.ppf() to handle loc * `#11251 `__: DOC: add reference for linesearch zoom algorithm * `#11253 `__: BUG: fix kendalltau issue where p-value becomes >1 * `#11254 `__: MAINT: make special.factorial handle nan correctly * `#11256 `__: DOC: Updated documentation for scipy.linalg.qr * `#11265 `__: Fix: Can no longer slice csr_matrix in 1.3.0 * `#11267 `__: BUG: Rework the scaling in the ks_2samp two-sided exact test. * `#11268 `__: DOC: example of NonLinearConstraint * `#11269 `__: Fix: Sparse matrix constructor data type detection changes on... * `#11276 `__: BLD: update minimum Python, NumPy, Cython, Pybind11 versions * `#11277 `__: MAINT: Cleanup conditionals for unsupported numpy verisons * `#11278 `__: MAINT: Cleanup stats.iqr workarounds for unsupported NumPy versions * `#11282 `__: TST/CI: improve traceback formatting for test failures * `#11284 `__: fix docs & behavior for mode sequences in ndimage filters * `#11285 `__: DOC: special: complete the docstrings of Chi-square functions * `#11286 `__: BUG: make loadmat/savemat file opening close resources correctly * `#11287 `__: CI: skip Azure and TravisCI builds on merges and direct pushes... * `#11288 `__: DOC: Fix import in scipy.io.wavfile.read sample code * `#11289 `__: BUG: Use context manager for open * `#11290 `__: MAINT: Remove _lib._version in favour of _lib._pep440 * `#11292 `__: DOC: special: add docstrings for various convenience functions * `#11293 `__: DOC: special: fix typo in \`chdtri\` docstring * `#11296 `__: DOC: special: add to docstrings of Bessel zeros and derivatives * `#11297 `__: DOC: special: add parameters/returns sections for Bessel integrals * `#11300 `__: MAINT: Update vendored uarray version * `#11301 `__: CI: azure conditions should require succeeded() * `#11302 `__: ENH: build infrastructure for ILP64 BLAS + ARPACK conversion * `#11303 `__: DOC: special: fix typo in \`besselpoly\` docstring * `#11304 `__: ENH: MAINT: Rewrite of eigh() and relevant wrappers * `#11306 `__: TST: skip test_aligned_mem linalg test that is crashing on ppcle64 * `#11307 `__: MAINT: Fix typo 'solutuion' -> 'solution' * `#11308 `__: ENH: do not create 1d array out of a scalar * `#11310 `__: MAINT: clean up object array creation, scalar/1d confusion * `#11311 `__: DOC: Specify custom callable option for metric in cluster.hierarchy.fclusterdata * `#11316 `__: BUG: special: fix behavior for \`rgamma\` zeros * `#11317 `__: BUG: fix floating-point literal comparisons under C99 * `#11318 `__: TST: optimize: mark two linprog tests for skipping * `#11320 `__: BUG: Include \`int64_t\` declaration to \`rectangular_lsap.cpp\` * `#11330 `__: MAINT: Update vendored pypocketfft version * `#11333 `__: BUG: directed_hausdorff subset fix * `#11335 `__: [ENH] sparse: Loosen check for sparse outer indexing fast path * `#11337 `__: Undefined name 'e' in pavement.py * `#11338 `__: scipyoptdoc.py: Remove unused variable 'sixu' * `#11340 `__: xrange() was removed in Python 3 in favor of range() * `#11342 `__: range() was removed in Py3 in _binned_statistic.py * `#11343 `__: BUG: constants: fix 'exact' values table * `#11347 `__: ENH: add input validation function and apply it to needed functions * `#11348 `__: MAINT: remove six.string_types usages * `#11349 `__: MAINT: minor doc fix _minimize_trustregion_constr * `#11353 `__: MAINT: py3 remove various six usages * `#11358 `__: ENH: optimize: Use CSR format instead of LIL for speed * `#11362 `__: MAINT: sys.version_info >= 3.5 * `#11364 `__: ENH: cache square of sums for f_oneway * `#11368 `__: ENH: add optional argument, "include_nyquist", for freqz() * `#11372 `__: BENCH: optimize: added linprog presolve benchmarks * `#11376 `__: ENH: Add wrapper for ?gttrf/?gttrs * `#11377 `__: MAINT: Remove Python 2 code from tools/authors.py * `#11378 `__: ENH (WIP): Python wrapper for ?tbtrs * `#11379 `__: MAINT: Remove six.with_metaclass from benchmarks/cython_special.py * `#11380 `__: BUG: sparse/isolve: bicg and qmr don't treat x0 correctly * `#11382 `__: MAINT: remove error throw in binned_statistic_dd() on non-finite... * `#11383 `__: MAINT: _lib: remove py2 compat shims in getargspec * `#11384 `__: MAINT: Use numpy scalar types directly * `#11385 `__: ENH: special: add spherical Bessel functions to \`cython_special\` * `#11389 `__: MAINT: line.startswith shouldn't be bytes * `#11393 `__: ENH: Speed up truncnorm's ppf()and rvs() methods * `#11394 `__: MAINT: Remove self._size (and self._random_state) from stats... * `#11395 `__: correction in error message (%d->%g format) * `#11396 `__: DOC: revert gh10540, removing mtrand * `#11397 `__: MAINT: differential_evolution accepts np.random.Generator * `#11402 `__: ENH: stats can use np.random.Generator * `#11404 `__: ENH: add docstring of butter() for transfer function syntax problem * `#11405 `__: DOC: Fix "see also" for SmoothBivariateSpline * `#11408 `__: ENH: Add a \`plan\` argument to FFT functions in \`scipy.fft\` * `#11411 `__: MAINT: check minimize duplicate evaluations * `#11418 `__: ENH: Linalg: Python wrapper for ?geqrfp * `#11419 `__: TST: Python 3.7 mac OS gcc multibuild fix * `#11423 `__: ENH: Add tool to lint diffs * `#11425 `__: FIX: _array_newton should preserve complex inputs * `#11426 `__: MAINT: licence for global optimization benchmarks * `#11431 `__: Make median_absolute_deviation scale argument aligned w/iqr * `#11432 `__: Fix error message typo * `#11433 `__: DOC: Remove L from longs * `#11434 `__: MAINT: Python3 improvements to refguide_check.py * `#11435 `__: DOC: Update runtest --parallel help * `#11436 `__: MAINT: Remove checks for sys.version < 3.5 * `#11437 `__: DOC: Fix documentation issue * `#11439 `__: Support path objects (PEP 519) in mmio functions * `#11440 `__: correct bounds pass in run_dualannealing for benchmarks/optimize.py * `#11443 `__: BENCH: optimize_linprog remove ImportError exception * `#11453 `__: BUG: sparse: convert csc/csr indices to int64 as needed * `#11454 `__: DOC: Remove caveat on \`maximum_bipartite_matching\` * `#11455 `__: BUG: Fix _lib._util.getargspec_no_self lack of KEYWORD_ONLY support. * `#11456 `__: Implementation of khatri_rao product * `#11459 `__: BUG: fix augmentation being broken in maximum_bipartite_matching * `#11461 `__: MAINT: minor spelling corrections in comments in SciPy.sparse.linalg.arpack * `#11467 `__: [MRG] Make result data type of KDE evaluation like in the input... * `#11469 `__: Update integrate.quad documentation * `#11472 `__: Fixed result typo * `#11476 `__: DOC: stats: Copy-edit the anderson docstring. * `#11478 `__: ENH: avoid unnecessary array copies in matrix product * `#11481 `__: BUG: Make special.hyperu return nan if any argument is nan * `#11483 `__: BUG: Fixed \`_kpp\` initialization on \`scipy.cluster.vq\`, closing... * `#11485 `__: ENH: Update docstring of class KrylovJacobian to fix #2744 * `#11486 `__: BUG: make special.eval_hermite return nan if second argument... * `#11487 `__: ENH: improve docstring of correlate and correlate2d to fix #1968 * `#11488 `__: FIX: change "func -> fun" of scipy.optimize _root.py to solve... * `#11489 `__: BUG: fixes typo introduced in PR #11253 in stats.mstats.kendalltau() * `#11490 `__: DOC: fix typo in scipy/io/matlab/mio4.py * `#11495 `__: MAINT: refactor slsqp to fix issue in callback function * `#11498 `__: [DOC] mention graph cuts in maximum flow docstring * `#11499 `__: DOC: Improve documentation of scipy.signal.signaltools.wiener * `#11506 `__: DOC: Fix typo in documentation of scipy.stats.morestats * `#11508 `__: ENH: avoid copy on sparse __init__ when dtype is given * `#11509 `__: ENH: avoid unnecessary array copies in matrix product (again) * `#11510 `__: [DOC] An ex. for creating arbitrary size tri-diagonal * `#11511 `__: TST: pin numba for Travis/sparse * `#11513 `__: TST: disable NumPy cache dir ppc64le * `#11514 `__: BUG: make special.eval_genlaguerre return nan if passed nan * `#11517 `__: ENH: improve sparse.lil.tocsr performance * `#11519 `__: Fix fresnel documentation * `#11520 `__: BUG: make special.eval_gegenbauer return nan if passed nan * `#11524 `__: ENH: Cosine Sine Decomposition * `#11526 `__: BUG: fix SLSQP max iteration setting to fix #4921 * `#11527 `__: ENH: improve docstring of weibull_min_gen and weibull_max_gen... * `#11530 `__: MAINT: Removed 3 unused imports, 3 unused assignments from ndimage. * `#11531 `__: DOC: fix typos in bdtr and bdtrc from gh PR 11045 * `#11532 `__: MAINT: Fixed several unused imports and unused assignments from... * `#11533 `__: MAINT: Fixed about 100 unused imports, unused assignment warnings... * `#11534 `__: FIX: Allow non-native byte order inputs to scipy.fft * `#11535 `__: MAINT: Fixed several unused imports in _lib. * `#11536 `__: MAINT: Fixed several unused imports and unused assignments in... * `#11537 `__: MAINT: Removed an unused import in scipy/constants. * `#11538 `__: MAINT: Fixed several unused imports in scipy/fft. * `#11539 `__: MAINT: Fixed several unused imports and unused assignments in... * `#11540 `__: MAINT: Fixed two unused imports in scipy/misc. * `#11541 `__: MAINT: Fixed several unused imports and unused assignments in... * `#11542 `__: MAINT: Fixed an unused import in scipy/odr. * `#11543 `__: MAINT: Fixed several unused imports and unused assignments in... * `#11544 `__: MAINT: Fixed unused imports and unused assignments in scipy/integrate. * `#11545 `__: MAINT: Removed unused imports and fixed unused assignments in... * `#11546 `__: MAINT: Removed unused imports; fixed unused assignments in scipy/signal. * `#11547 `__: MAINT: Removed unused imports; fixed unused assignments in scipy/spatial * `#11548 `__: MAINT: Removed unused imports; fixed unused assignments in scipy.sparse. * `#11549 `__: MAINT: Replace xrange with range * `#11560 `__: MAINT: stats: remove an _argcheck call * `#11573 `__: MAINT: Removed unused imports; fixed unused assignments in scipy/stats. * `#11574 `__: MAINT: Small change to \`optimize.nnls\` error messages. * `#11575 `__: MAINT: Update sytrd/hetrd tests * `#11582 `__: MAINT: fix typo in quadpack.py closes #11448 * `#11585 `__: TST: add openblas_support.py * `#11587 `__: BUG: Differential evolution with LinearConstraint with sparse... * `#11588 `__: MAINT: Fully display problem size in lsmr/lsqr. * `#11589 `__: MAINT: Remove Python 2 workarounds * `#11590 `__: MAINT: Remove Python2 module init * `#11605 `__: Standardization of bounds in _linprog_util.py * `#11608 `__: BUG: fix use of is in DE callback * `#11614 `__: TST, MAINT: TestCtypesQuad skip with pytest * `#11619 `__: ENH: add nan_policy argument and functionality to stats.mstats.winsorize * `#11621 `__: MAINT: Cleanup uses of PY_VERSION_HEX, NPY_PY3K in ndimage * `#11622 `__: MAINT: Cleanup uses of PY_VERSION_HEX, NPY_PY3K in sparse * `#11623 `__: MAINT: Remove unnecessary 'from __future__ import ...' statements * `#11626 `__: MAINT: Cleanup uses of PY_VERSION_HEX * `#11627 `__: ENH: add analytic formula for normal moments * `#11628 `__: MAINT, TST: adjust azure for matplotlib release * `#11631 `__: Revert to old behaviour for constant cost matrices in \`linear_sum_assignment\` * `#11632 `__: MAINT: Define ARRAY_ANYORDER with DEF instead of cdef * `#11639 `__: BUG: interpolate/interp1d: fail gracefully on all-nan inputs * `#11640 `__: MAINT: Fix BLAS3 trmm wrapper for "side" arg * `#11642 `__: TST, MAINT: remove dead code in Travis CI * `#11643 `__: MAINT: fix conversion in binom_test * `#11645 `__: MAINT: Assorted clean up. * `#11646 `__: MAINT: Remove unnecessary 'from __future__ import ...' statements * `#11647 `__: DOC: document return_all arguments * `#11648 `__: Perform geometric slerp in quaternion space * `#11651 `__: DOC: Update paper URL in lambertw documentation * `#11653 `__: PERF: Switch to C++ STL std::nth_element * `#11655 `__: MAINT: Remove Python2 cStringStream * `#11657 `__: ENH: Add wrapper for ?pttrf/?pttrs * `#11664 `__: ENH: Add wrapper for ?gejsv * `#11665 `__: ENH: Add wrapper for ?pteqr * `#11667 `__: BUG: Non-central Fisher distribution (fix nan-values when nc=0) * `#11668 `__: ENH: Add wrapper for ?gtsvx * `#11671 `__: TST, CI: restore Azure temporarily * `#11672 `__: Add warning to medfilt when array size < kernel_size * `#11674 `__: TST: bump test precision for two np.dot related linalg tests. * `#11675 `__: MAINT: pycodestyle clean-up * `#11677 `__: ENH: Add wrapper for ?ptsvx * `#11679 `__: BENCH: cKDTree benchmarks added: balanced/unbalanced tree (related... * `#11680 `__: MAINT: rng_integers allows RandomState.randint or Generator.integers * `#11683 `__: BUG: fix mode='mirror' on length 1 axes * `#11684 `__: BUG: fix scipy.special.voigt_profile * `#11687 `__: MAINT: sparse.linalg: avoid importing from \`np.core\` * `#11688 `__: ENH: mypy: get specific about ignoring missing imports * `#11690 `__: MAINT: mypy: fix errors about incompatible types in lists * `#11692 `__: MAINT: mypy: fix remaining type errors * `#11694 `__: TST, MAINT: bump to OpenBLAS 0.3.9 stable, raise tol for Win... * `#11697 `__: DOC: fix pdf of norminvgauss in scipy.stats * `#11701 `__: MAINT: special: add rudimentary types for \`_ufuncs\` extension... * `#11702 `__: BUG: Fixed a post-merge bug for eigh() * `#11703 `__: Improves docstring with consistent L2-norm * `#11705 `__: DOC: Slerp the SphericalVoronoi docstring * `#11706 `__: ENH: mypy: add \`--mypy\` option to \`runtests.py\` * `#11710 `__: ENH: Modified stats.kstest() to use the exact stats.kstwo.sf()... * `#11715 `__: DOC: add .. versionadded:: to as_matrix/from_matrix in spatial/transf? * `#11716 `__: BENCH: fix benchmark imports for \`\`optimize_linprog.py\`\` * `#11721 `__: MAINT: io: Remove now-unnecessary \`# type: ignore\` * `#11722 `__: MAINT: mypy: remove mpmath from the ratchet * `#11726 `__: Handle constant input for scipy.stats.f_oneway * `#11729 `__: BENCH: optimize: added infeasible benchmarks for linprog * `#11731 `__: fix inaccurate information about Mac OS compiler (#11696) * `#11733 `__: Fix inaccurate docstring example of HalfspaceIntersection * `#11734 `__: Doc: fix inaccurate docstring of SmoothBivariateSpline. * `#11735 `__: Bug: stats: fix wrong shape from median_absolute_deviation for... * `#11736 `__: ENH: add input validations and its tests for FITPACK in fitpack2.py * `#11737 `__: BUG: Prevent crashes due to MKL bug in ?heevr * `#11739 `__: MAINT: special: add type stubs for \`_test_round.pyx\` * `#11740 `__: MAINT: special: remove unused specfun f2py wrappers * `#11741 `__: BUG: fix small tolerances handling for minpack and add a test. * `#11743 `__: Doc: fix docstring of rfft, rfft2, rfftn, irfft, irfft2, irfftn... * `#11744 `__: MAINT: Remove unused py3k.h code * `#11745 `__: DOC: stats: Clean up ncf documentation. * `#11748 `__: MAINT: special: type \`cython_special\` as \`Any\` * `#11750 `__: MAINT: type hints for \`_spherical_voronoi\` * `#11752 `__: DOC: fix docstring of scipy.optimize.least_squares * `#11753 `__: ENH: add input validation for dendrogram and a test. * `#11755 `__: MAINT: Replace uses of tostring with tobytes * `#11757 `__: ENH: improve binned_statistics_2d performance. * `#11759 `__: ENH: optimize: add HiGHS methods to linprog * `#11760 `__: MAINT: Remove FileStream replaced by GenericStream * `#11761 `__: MAINT: Replace npy_3kcompat.h shims * `#11765 `__: TST: Speedup test_pascal which is VERY slow on Azure * `#11766 `__: TST: speed up differential_evolution L8 test * `#11767 `__: Change comment in continuous rv gamma fit function * `#11776 `__: Add domain option for resample. * `#11784 `__: BUG: Fixed calculation of nonzero elements in scipy.sparse.random * `#11786 `__: ENH: stats: add axis keyword argument to scipy.stats.rankdata * `#11789 `__: Doc: fix docstring of scipy.spatial.chebyshev * `#11792 `__: DOC: dev: add guidelines for developing public Cython APIs * `#11794 `__: MAINT: add comments explaining a problem in cython_optimize organization * `#11796 `__: DOC: add a note about precision losing in csgraph.minimum_spanning_tree... * `#11797 `__: ENH: Allow negative \`axis\` in \`interpolate.BSpline\`. Also... * `#11798 `__: Add simplify_cells parameter to scipy.io.loadmat * `#11801 `__: MAINT, DOC: minor changes of ratio-of-uniforms in scipy.stats * `#11802 `__: BUG: fix scipy.odr to handle multidimensional independent and... * `#11803 `__: scipy.stats.trapz: Use analytic formulas for stats and entropy. * `#11808 `__: DOC: add Examples in the scipy.interpolate.interpn docstring. * `#11809 `__: Duplicate entries are added together in csr_matrix constructor * `#11813 `__: MAINT: bump pyflakes to version 2.1.1 * `#11814 `__: BUG: scipy.sparse.csr doctest failing with incorrect output value * `#11817 `__: DOC: add Examples in the scipy.optimize.leastsq docstring * `#11820 `__: ENH: Raise an error on incorrect bounds format in optimize.fmin_l_bfgs_b * `#11822 `__: CI: add github actions for macOS * `#11824 `__: DOC: add Examples in scipy.optimize.line_search docstring (line_search_wolfe2) * `#11830 `__: TST: Always use fork for multiprocessing in fft tests * `#11831 `__: DOC: add Examples and Returns in scipy.misc.central_diff_weights... * `#11832 `__: DOC: stats: Some small corrections to a couple docstrings. * `#11833 `__: BUG: Fix compiler_name when there are paths used in flags * `#11836 `__: MAINT: re-introduce multiprocessing tests on Python3.8 * `#11837 `__: Doc: add Examples in scipy.optimize.fsolve docstring * `#11838 `__: Doc: add Examples in scipy.sparse.linalg.minres docstring * `#11840 `__: BUG: sparse.linalg: fix overflow in expm intermediate computation * `#11842 `__: BLD: fix build with gfortran 10 * `#11843 `__: MAINT: Simplify floats in constants.py * `#11847 `__: DOC: add a tutorial of scipy.optimize.linprog * `#11849 `__: ENH: speed up geninvgauss by using cython * `#11852 `__: CI: remove osx from travisCI * `#11857 `__: BUG: Change parameter fc of gausspulse to float. * `#11861 `__: order = degree + 1 for splines * `#11863 `__: Make g77 ABI wrapper work with gfortran ABI lapack * `#11866 `__: MAINT: add type ignores to sympy and matplotlib imports * `#11867 `__: CI: Add arm64 in travis-ci * `#11869 `__: DOC: signal: Add an example to the lsim2 docstring. * `#11870 `__: DOC: signal: Use impulse instead of impulse2 in the impulse example... * `#11871 `__: ENH: type ufuncs in special as ufuncs instead of Any * `#11872 `__: BUG: avoid recomputing in scipy.optimize.optimize.MemoizeJac * `#11873 `__: DOC: signal: Fix ODE in impulse and impulse2 docstrings. * `#11874 `__: DOC: add Examples of docstring for scipy.interpolate.approximate_taylor_polynomial * `#11878 `__: DOC: fixed a typo under scipy/integrate/quadrature.py * `#11879 `__: BUG: Fix index arrays overflow in sparse.kron * `#11880 `__: DOC: stats: Add Examples for bartlett, fligner, levene. * `#11881 `__: MAINT: normalise numpy-->np in optimize.py * `#11882 `__: DOC: add Examples for scipy.io.readsav docstring. * `#11883 `__: DOC: add Returns and Examples for scipy.ndimage.correlate() docstring * `#11885 `__: BUG: stats: Handle multidimensional arrays in f_oneway, and more. * `#11889 `__: DOC: signal: Unify lsim and lsim2 examples. * `#11896 `__: BUG: stats: Fix handling of size 0 inputs for ttest_rel and ttest_ind. * `#11897 `__: DOC: Remove misleading default values from fit method * `#11898 `__: MAINT: LinearVectorFunction.J is ndarray closes #11886 * `#11902 `__: BUG: linalg: test_heequb failure * `#11904 `__: fix real-to-real transforms for complex inputs and overwrite_x=True * `#11906 `__: DOC: stats: fix error caused by trapz docstring * `#11907 `__: BUG: stats: fixed SEGFAULT from Issue #9710 * `#11912 `__: ENH: Respect matplotlib color palette with hierarchy/dendrogram. * `#11914 `__: DOC: refine doc for spatial.distance.squareform * `#11915 `__: ENH: Ndim linear operator * `#11919 `__: ENH: expose "window_size" parameter in find_peaks_cwt() * `#11920 `__: DOC: explain M, diffev * `#11923 `__: CI: macOS install swig closes #11922 * `#11924 `__: DOC: add Examples for scipy.optimize.bracket() docstring * `#11930 `__: DOC: add Examples and clean up for signal.qspline1d and signal.qspline_eval... * `#11931 `__: DOC: add Examples for sparse.linalg.bicg docstring. * `#11933 `__: DOC: Add original reference for Yao-Liu objective functions * `#11934 `__: DOC, MAINT: mailmap update * `#11935 `__: DOC: make scipy.stats.mode documentation reflect that the function... * `#11936 `__: ENH: special: add type stubs for \`orthogonal.py\` * `#11937 `__: DOC: Add docstring examples to fft2, ifft2, io.savemat * `#11938 `__: MAINT: add helper function for deprecating Cython API functions * `#11942 `__: MAINT: ignore conditional import in _lib/_util * `#11943 `__: MAINT: special: add types for geterr/seterr/errstate * `#11946 `__: MAINT: add py.typed marker * `#11950 `__: TST:MAINT: separated and stabilized heequb tests * `#11952 `__: DOC: update toolchain roadmap for py38, C99, C++11/14 * `#11957 `__: MAINT: Use np.errstate context manager instead of np.seterr. * `#11958 `__: MAINT: interpolate: Remove some trailing spaces. * `#11960 `__: MAINT: Cleanup Python2 compatibility code * `#11961 `__: MAINT: Remove numpy/npy_3kcompat.h from _superluobject.c * `#11962 `__: DOC: Fix type of \`codes\` in docstring of \`_vq._vq()\` * `#11964 `__: MAINT: Cleanup unused IS_PYPY * `#11969 `__: DOC: add Examples and fix docstring for special.airye * `#11970 `__: BUG: sparse: 'diagonal' of sparse matrices fixed to match numpy's... * `#11974 `__: BUG: Reshape oaconvolve output even when no axes are convolved * `#11976 `__: MAINT: add logo for github actions * `#11977 `__: CI: test bleeding edge Python * `#11979 `__: DOC: add Examples for stats.ranksums() docstring. * `#11982 `__: Fix KMeans++ initialisation slowness * `#11983 `__: DOC: add Examples for stats.mstats.argstoarray() docstring. * `#11986 `__: Avoid bugs in ndimage when the output and input arrays overlap... * `#11988 `__: ENH: Override fit method of Laplace distribution with Maximum... * `#11993 `__: TST, CI: Azure Windows path fixups * `#11995 `__: MAINT, CI: remove custom mingw Azure * `#11996 `__: DOC: add Examples and fix pep warning for fft.set_global_backend... * `#11997 `__: MAINT, CI: Azure OpenBLAS simplify * `#11998 `__: BENCH: Run against current HEAD instead of master * `#12001 `__: ENH: stats: Implement _logpdf for the maxwell distribution. * `#12004 `__: DOC: add examples for integrate.quad_vec() and integrate.quad_explain() * `#12005 `__: MAINT: Use helper functions in ?tbtrs tests * `#12007 `__: MAINT: updated LICENSES_bundled for pybind11 and six * `#12008 `__: DOC: roadmap update * `#12009 `__: ENH: optimize: support 64-bit BLAS in lbfgsb * `#12010 `__: ENH: sparse.linalg: support 64-bit BLAS in isolve * `#12012 `__: DOC: add Examples for interpolate.barycentric_interpolate(),... * `#12013 `__: MAINT: remove last uses of numpy.dual * `#12014 `__: CI: print 10 slowest tests * `#12020 `__: MAINT: Removed handling of circular input in SphericalVoronoi * `#12022 `__: DOC : added default value of absolute_sigma to False in scipy.optimize.curve_fit docs * `#12024 `__: DOC: add Examples for io.hb_read() and io.hb_write() * `#12025 `__: MAINT: Remove numpy/npy_3kcompat.h from nd_image * `#12028 `__: Spelling correction * `#12030 `__: ENH: optimize/_trlib: support ILP64 blas/lapack * `#12036 `__: MAINT: Add some generated C files .gitignore * `#12038 `__: MAINT, CI: Travis rackcdn->conda.org * `#12039 `__: MAINT: signal: Lower the resolution of the plots in the chirp... * `#12040 `__: DOC: add Examples for ndimage.spline_filter1d() and spline_filter()... * `#12044 `__: MAINT: combine apt-get update and apt-get install into one RUN * `#12045 `__: TST: Reduce size of test_diagonal_types to speed up tests * `#12046 `__: MAINT: Remove unused npy_3kcompat.h * `#12047 `__: MAINT: Cython 3.0 compat * `#12050 `__: DOC: add download number badges of PyPI and conda-forge in README.rst * `#12052 `__: DOC: add Examples odr.models.polynomial() and fix odr.odr docstring... * `#12056 `__: ENH: Modifies shapiro to return a named tuple * `#12057 `__: Adding my name into THANKS.txt * `#12060 `__: TST: Reduce number of test_diagonal_types configs * `#12062 `__: TST: Change dec.slow to pytest.mark.slow * `#12068 `__: ENH: Modifies jarque_bera to return a named tuple * `#12070 `__: MAINT, CI: appveyor rack->conda.org * `#12072 `__: TST: filter out factorial(float) deprecation warning * `#12078 `__: TST: Skip test on colab with large memory alloc * `#12079 `__: DOC: Remove Python2 reference from stats tutorial * `#12081 `__: DOC: add Examples docstring for optimize.show_options() * `#12084 `__: BUG: interpolate: fix BarycentricInterpolator with integer input... * `#12089 `__: ENH: spatial/qhull: support ILP64 Lapack * `#12090 `__: ENH: integrate: support ILP64 BLAS in odeint/vode/lsoda * `#12091 `__: ENH: integrate: support ILP64 in quadpack * `#12092 `__: BUG: Fix dropping dt in signal.StateSpace * `#12093 `__: MAINT: Rollback python2.6 workaround * `#12094 `__: MAINT: \`openblas_support\` hash checks * `#12095 `__: MAINT: ndimage: change \`shares_memory\` to \`may_share_memory\` * `#12098 `__: Doc: change 4 model instances of odr to be instances of \`Model\`... * `#12101 `__: Removed more unused imports and assignments. * `#12107 `__: ENH: Area calculation for 2D inputs in SphericalVoronoi * `#12108 `__: MAINT: ensure attributes have correct data type in \`SphericalVoronoi\` * `#12109 `__: degree is not order in splines * `#12110 `__: ENH: More helpful/forgiving io.wavfile errors * `#12117 `__: BUG: fix newline * `#12123 `__: [MAINT] Fix error on PyData/Sparse import. * `#12124 `__: TST: Always test matmul now that Python3.5+ is required * `#12126 `__: TST: Cleanup unused matplotlib code. * `#12127 `__: DOC: update docstrings of signal.cspline2d, qspline2d, sepfir2d * `#12130 `__: MAINT: Fixing broken links with linkchecker * `#12135 `__: ENH: linalg: Add the function convolution_matrix. * `#12136 `__: MAINT: Cleanup np.poly1d hack * `#12137 `__: TST, CI: reproduce wheels 32-bit setup * `#12140 `__: TST: stats: add kstwo, ksone to slow tests. * `#12141 `__: Support 64-bit integer size in Fitpack * `#12151 `__: DOC: Correct Rosenbrock function sum * `#12159 `__: BUG: Fix length calculation in upfirdn * `#12160 `__: BUG: Fix M_PI * `#12168 `__: DOC: add an obsolete version checking javascript to doc release... * `#12171 `__: CI, MAINT: Azure OpenBLAS drive flip * `#12172 `__: ENH: Bounds for the Powell minimization method * `#12175 `__: BLD: support more Fortran compilers for ilp64 and macro expansion... * `#12179 `__: BUG: stats: A few distributions didn't accept lists as arguments. * `#12180 `__: MAINT: removed redundant import in SphericalVoronoi tests * `#12181 `__: DOC: for versionwarning don't use $.getScript * `#12182 `__: MAINT: random sampling on the hypersphere in SphericalVoronoi... * `#12194 `__: MAINT: Module and example cleanups for doc build * `#12202 `__: ENH: tool to DL release wheels from Anaconda * `#12210 `__: Remove py.typed marker (at least for the release) * `#12217 `__: BUG: stats: Fix handling of edge cases in median_abs_deviation. * `#12223 `__: BUG: stats: wilcoxon returned p > 1 for certain inputs. * `#12227 `__: BLD: Set macos min version when building rectangular_lsap * `#12229 `__: MAINT: tools/gh_lists.py: fix http header case sensitivity issue * `#12236 `__: DOC: Fix a couple grammatical mistakes in 1.5.0-notes.rst. * `#12276 `__: TST: skip `test_heequb`, it fails intermittently. * `#12285 `__: CI: split travis arm64 run into two * `#12317 `__: BUG: prevent error accumulation in `Rotation` multiplication * `#12318 `__: BUG: sparse: avoid np.prod overflow in check_shape * `#12319 `__: BUG: Make cobyla threadsafe * `#12335 `__: MAINT: Work around Sphinx bug Checksums ========= MD5 ~~~ 83399629fbdf226cc39ecf9edcaaa1bb scipy-1.5.0rc2-cp36-cp36m-macosx_10_9_x86_64.whl 2e20179935ac222779ce7feb5053d4d7 scipy-1.5.0rc2-cp36-cp36m-manylinux1_i686.whl c93b24eb2a9a5b616537a1230a1a3329 scipy-1.5.0rc2-cp36-cp36m-manylinux1_x86_64.whl 4f8875c17e2b13dca1f288d5e8c536a0 scipy-1.5.0rc2-cp36-cp36m-win32.whl 18ee197d5a7102d09cc27bc3a7d6c7b2 scipy-1.5.0rc2-cp36-cp36m-win_amd64.whl 3fa741b364d56dfb37e7a5318ea81cdf scipy-1.5.0rc2-cp37-cp37m-macosx_10_9_x86_64.whl b9d2b8a9c9cdd88bfd34ea4c095ab145 scipy-1.5.0rc2-cp37-cp37m-manylinux1_i686.whl 937f5564405efd5d7e37f45e50c00074 scipy-1.5.0rc2-cp37-cp37m-manylinux1_x86_64.whl 8ed7b36d990c32014840a2c024a56d82 scipy-1.5.0rc2-cp37-cp37m-win32.whl 97e4c3c6329e41351bbdf5552fce423f scipy-1.5.0rc2-cp37-cp37m-win_amd64.whl 53351605d7561ad5685d41cac1c6333b scipy-1.5.0rc2-cp38-cp38-macosx_10_9_x86_64.whl cc5ea53ee3a3777184b39bee92d6d432 scipy-1.5.0rc2-cp38-cp38-manylinux1_i686.whl 3b8b55fceaa1edb0db71c3db666f8696 scipy-1.5.0rc2-cp38-cp38-manylinux1_x86_64.whl af1129dc5f85f50446f337a643049b6f scipy-1.5.0rc2-cp38-cp38-win32.whl 6eea947704de9515fd9ec5b5d939ea1b scipy-1.5.0rc2-cp38-cp38-win_amd64.whl 62eeaab3889c2074e14515feaeee01c6 scipy-1.5.0rc2.tar.gz 980ac99f7de69ed0890b050594b1b0a4 scipy-1.5.0rc2.tar.xz db38ec76f7aa10f5241e14261c80c928 scipy-1.5.0rc2.zip SHA256 ~~~~~~ 388cc2b84cd8c93f20170fbd881ce70a6b0d74a48dab6ad5dd88d4bde342fb35 scipy-1.5.0rc2-cp36-cp36m-macosx_10_9_x86_64.whl 0bf8b1ac919b244bf75180e3cb1533444115925aaa5d002d0c7219dece02ccc8 scipy-1.5.0rc2-cp36-cp36m-manylinux1_i686.whl 94cd4bb489acc03b057364c4c3ed787df0672f945dabad7247aaabbac364b271 scipy-1.5.0rc2-cp36-cp36m-manylinux1_x86_64.whl 488b4ba42086b8911806b68685c17f80698a952bb6612579524af828e3bb6fc6 scipy-1.5.0rc2-cp36-cp36m-win32.whl c3362995c6416c934a93933e90d11131a82a01929ae2dd4f140cbcfa773280c7 scipy-1.5.0rc2-cp36-cp36m-win_amd64.whl 87d0fdc34ecf2acfaf147dc53d35c6842f6693732b929a59e1f29d2e73c1b576 scipy-1.5.0rc2-cp37-cp37m-macosx_10_9_x86_64.whl e25bead48bb9832295902cd858979130c225ab9c2d50769ab4236bbf1784ee60 scipy-1.5.0rc2-cp37-cp37m-manylinux1_i686.whl b460ebaa532e6084c53d3979b131b96679d9f0f714684ad5cfcfd7ee3026219d scipy-1.5.0rc2-cp37-cp37m-manylinux1_x86_64.whl bc9bad55c2a15ea02cb68af77f909e69e89929085609ca858db6d00b210fb937 scipy-1.5.0rc2-cp37-cp37m-win32.whl f394d423c10d58f89ddc7677cd91f77ad6e18e7d792830b037ab2ed669f204a2 scipy-1.5.0rc2-cp37-cp37m-win_amd64.whl 0a4bee8fec8144c1cd70a493cbaa2f8beb67728beb62e0a3c33e18fd3d3ab26e scipy-1.5.0rc2-cp38-cp38-macosx_10_9_x86_64.whl 666ae802a660f892606096daa3752b4d3ca67ed10e96e045fa7c4e298fcd87fa scipy-1.5.0rc2-cp38-cp38-manylinux1_i686.whl 4ad221d8475d6022e62110c3f4968e1a89fc4ed27bad152ed57e2b0a6c7bd107 scipy-1.5.0rc2-cp38-cp38-manylinux1_x86_64.whl a2c228b04a34d58fa12f6c9ac4849a0d18e0088669ab6634fd32af608cfc74ad scipy-1.5.0rc2-cp38-cp38-win32.whl 42a11f2b85323d6b2f6b07d64366c1a8c53e52317cf69223894031ea424a6500 scipy-1.5.0rc2-cp38-cp38-win_amd64.whl 38509c2ecb32f751e3b20ffdccd506880405c980ee569c094ba449fd130d3c19 scipy-1.5.0rc2.tar.gz d6e647e520d10e62c8138c025b0a89fbdb588c1bf6bc76eb6e90601fc1f27b8a scipy-1.5.0rc2.tar.xz fe8540e7c28a89f98a5c11f937d97832728d931f7d3a56b5217ac7b7c66d0858 scipy-1.5.0rc2.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Tue Jun 16 17:53:24 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 16 Jun 2020 16:53:24 -0500 Subject: [Numpy-discussion] NumPy Development Meeting Tomorrow - Triage Focus Message-ID: <560dcf6a4773655101a61bff4d86f687ad45279d.camel@sipsolutions.net> Hi all, Our bi-weekly triage-focused NumPy development meeting is tomorrow (Wednesday, June 17th) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From albuscode at gmail.com Thu Jun 18 06:55:30 2020 From: albuscode at gmail.com (Inessa Pawson) Date: Thu, 18 Jun 2020 20:55:30 +1000 Subject: [Numpy-discussion] help translating Bangla into English In-Reply-To: References: Message-ID: We are two weeks away from the inaugural NumPy community survey going live. Currently, we are looking for a volunteer to help with the back translation of the Bangla version of the survey questionnaire (Bangla into English). If you are available, please leave a comment here: https://github.com/numpy/numpy-surveys/issues/1. -- Every good wish, Inessa Pawson NumPy survey team -------------- next part -------------- An HTML attachment was scrubbed... URL: From melissawm at gmail.com Thu Jun 18 09:14:38 2020 From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=) Date: Thu, 18 Jun 2020 10:14:38 -0300 Subject: [Numpy-discussion] Documentation Team meeting - Monday June 22nd In-Reply-To: References: Message-ID: Hi all! After last week's meeting, we discussed increasing the frequency of the Documentation Team meetings. So we're now having the meetings every two weeks. This means our next meeting will be on *Monday, June 22* 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 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+Documentation+Team+Meeting&iso=20200622T15&p1=1440&ah=1 *** You can add the NumPy community calendar to your google calendar by clicking this link: https://calendar.google.com/calendar/r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20 - Melissa -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Thu Jun 18 10:49:35 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Thu, 18 Jun 2020 09:49:35 -0500 Subject: [Numpy-discussion] `np.array()`, array-likes, nested sequences and subclasses Message-ID: Hi all, tl;dr: `np.array()` is somewhat ill-defined, also creating issues for Quantities. In a recent PR I am cementing, and slightly broadening, its definition. So we have to decide how we wish to handle code such as in the long run: np.array([array-like, array-like]) --- Traditionally, we have two meanings of "array-like" as understood by `np.array()` (In the text I use array-like for the second point here): 1. Nested sequences of scalars. 2. A single array-like object, meaning a buffer-interface, an array subclass, a pandas dataframe (`__array__()`), etc. However, the boundaries between these are fuzzy, and over the years became more fuzzy. The reason is that a NumPy array (and many array- likes) are also nested sequences of scalars. I defined the current behaviour slightly clearer in my PR, but by that also subtly broadened it up [0]: 1. Any array-like embedded in the nested-sequences is converted to a NumPy array. [1] (Any array-like is never interpreted as a sequence) 2. Any array-like's elements will be elements of the output. We never enter array-likes recursively (including object arrays). 3. The `subok=True` parameter is implicitly ignored, unless the input is a single ndarray sublcass. Now to the issues at hand: * We should make sure those defintions are good, they mainly cement current behaviour, but if we want to roll back on features, we should do it now. * There are some issues around Quantity and masked arrays, because their "scalars" are (sometimes) 0-D arrays. And they currently rely on NumPy considering them to be scalars. This has its own set of long term issues [2]. For now, I can simply roll the changes to 0-D array behaviour back. But in the mid-to-long run, we have to make a decision, or perpetually live with array subclasses being subtly broken: 1. Define Quantity and Masked arrays as wrong. They must use a special DType, which consistently tells NumPy that the elements cannot simply be copied by converting the Quantity to an array. The up-side is, that it generalizes to N-D. 2. Independently, but partially addressing the Quantity issue, we have to decide what `np.array()` should actually do. A sequence containing array-likes, in most cases is better written using `np.stack()`, but due to the fuzzy boundaries, code like `np.array([dataframe, dataframe])` is probably common. We could try to deprecate though. The downsides to deprecation seem to me that I feel we have to reject viewing array-likes as sequences. To me doing that has its own set of issues. If just that `np.array([arraylike])` seems perfectly reasonable, but may be very slow. - Sebastian [0] It is hard to list how exactly it is broadened up, because the current behaviour has very subtle behaviours, such as actually iterating a `memoryview()`, which does always the same thing, but only works for 1-D memoryviews, and fails for both 0-D and N-D. [1] There are some subtleties which are not important here, such that I do anticipate the possibility of having array-likes which are considered scalars with respect to a given dtype, such as `np.array([poly], dtype=Polynomial)` where a poly object itself is an array-like. [2] Basically: np.array([0d_array], dtype=user_dtype) works, by ending up calling: res[0] = float(0d_array) # quantity.__float__ is used! which works nice for the typical float/int dtype, is tricky to get right for general dtypes (e.g. longdouble/clongdouble). This is a small issue now, but it could become a problem when more user-dtypes are defined. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ralf.gommers at gmail.com Thu Jun 18 17:57:47 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 18 Jun 2020 23:57:47 +0200 Subject: [Numpy-discussion] NumPy team update Message-ID: Hi all, The NumPy team is growing, and it's awesome to see everything that is going on. Hard to keep up with, but that's a good thing! I think it's a good time for an update on people who gained commit rights, or joined one of the teams we now have. For those who haven't seen it yet, we have a team gallery at https://numpy.org/gallery/team.html. It isn't yet updated for the changes in this email, but gives a good picture of the current state. Matti Picus joined the Steering Council. He has been one of the driving forces behind NumPy for well over two years now, and we're very glad to have him join the council. Ross Barnowski, Melissa Weber Mendon?a, Josh Wilson and Bas van Beek gained commit rights. Ross has worked on the docs and reviewed lots of doc PRs for the last six months. Melissa has led the doc structuring and tutorial writing effort and has done a good amount of f2py maintenance as well. Josh and Bas have been pushing the type annotation work forward, first in the numpy-stubs repo and now in master. It's great to have experts in all these topics join the team. Furthermore, we now have 10+ people in the community calls, the triage calls and the docs team calls (all bi-weekly and on the NumPy community calendar [1] - everyone is welcome). And there's more going on - I feel like I should mention some of the other excellent work going on: A lot of work is going into SIMD optimizations. Sayed Adel has made very nice progress on implementing universal intrinsics (NEP 38), and Raghuveer Devulapalli, Chunlin Fang and others have contributed SSE/AVX and ARM Neon implementations for many functions. For the website, Shaloo Shalini has continued working on new case studies, we're about to merge a really nice one on tracking animal movement. Ben Nathanson has contributed his technical writing and editing skills to improve our website and documentation content. And Isabela Presedo-Floyd has taken up the challenge of redesigning the NumPy logo, and we're nearing the end of the process there. The survey team has also been working hard. Inessa Pawson, Xiaoyi Deng, Stephanie Mendoza, Ross Barnowski, Sebastian Berg and a number of volunteers for translations are getting a really well-designed survey together. And then of course there's both old hands and new people doing the regular maintenance and enhancement work on the main repo. Writing this email started with "we just gave out some commit rights, we should put that on the mailing list". Then I realized there's lots of other people and activities that deserve a shout out. And probably more that I forgot (if so, apologies!). I'll stop here - thanks everyone for all you do! Cheers, Ralf [1] https://calendar.google.com/calendar?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghuveer.devulapalli at intel.com Fri Jun 19 12:28:06 2020 From: raghuveer.devulapalli at intel.com (Devulapalli, Raghuveer) Date: Fri, 19 Jun 2020 16:28:06 +0000 Subject: [Numpy-discussion] NumPy team update In-Reply-To: References: Message-ID: Hi Ralf, Thank you for the acknowledgement. I am happy to contribute and hope to continue to do so in the future. Raghuveer From: NumPy-Discussion On Behalf Of Ralf Gommers Sent: Thursday, June 18, 2020 2:58 PM To: Discussion of Numerical Python Subject: [Numpy-discussion] NumPy team update Hi all, The NumPy team is growing, and it's awesome to see everything that is going on. Hard to keep up with, but that's a good thing! I think it's a good time for an update on people who gained commit rights, or joined one of the teams we now have. For those who haven't seen it yet, we have a team gallery at https://numpy.org/gallery/team.html. It isn't yet updated for the changes in this email, but gives a good picture of the current state. Matti Picus joined the Steering Council. He has been one of the driving forces behind NumPy for well over two years now, and we're very glad to have him join the council. Ross Barnowski, Melissa Weber Mendon?a, Josh Wilson and Bas van Beek gained commit rights. Ross has worked on the docs and reviewed lots of doc PRs for the last six months. Melissa has led the doc structuring and tutorial writing effort and has done a good amount of f2py maintenance as well. Josh and Bas have been pushing the type annotation work forward, first in the numpy-stubs repo and now in master. It's great to have experts in all these topics join the team. Furthermore, we now have 10+ people in the community calls, the triage calls and the docs team calls (all bi-weekly and on the NumPy community calendar [1] - everyone is welcome). And there's more going on - I feel like I should mention some of the other excellent work going on: A lot of work is going into SIMD optimizations. Sayed Adel has made very nice progress on implementing universal intrinsics (NEP 38), and Raghuveer Devulapalli, Chunlin Fang and others have contributed SSE/AVX and ARM Neon implementations for many functions. For the website, Shaloo Shalini has continued working on new case studies, we're about to merge a really nice one on tracking animal movement. Ben Nathanson has contributed his technical writing and editing skills to improve our website and documentation content. And Isabela Presedo-Floyd has taken up the challenge of redesigning the NumPy logo, and we're nearing the end of the process there. The survey team has also been working hard. Inessa Pawson, Xiaoyi Deng, Stephanie Mendoza, Ross Barnowski, Sebastian Berg and a number of volunteers for translations are getting a really well-designed survey together. And then of course there's both old hands and new people doing the regular maintenance and enhancement work on the main repo. Writing this email started with "we just gave out some commit rights, we should put that on the mailing list". Then I realized there's lots of other people and activities that deserve a shout out. And probably more that I forgot (if so, apologies!). I'll stop here - thanks everyone for all you do! Cheers, Ralf [1] https://calendar.google.com/calendar?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilhanpolat at gmail.com Fri Jun 19 13:31:42 2020 From: ilhanpolat at gmail.com (Ilhan Polat) Date: Fri, 19 Jun 2020 19:31:42 +0200 Subject: [Numpy-discussion] NumPy team update In-Reply-To: References: Message-ID: This is great. Can we have a SciPy version too Ralf? On Fri, Jun 19, 2020 at 6:31 PM Devulapalli, Raghuveer < raghuveer.devulapalli at intel.com> wrote: > Hi Ralf, > > > > Thank you for the acknowledgement. I am happy to contribute and hope to > continue to do so in the future. > > > > Raghuveer > > > > *From:* NumPy-Discussion intel.com at python.org> *On Behalf Of *Ralf Gommers > *Sent:* Thursday, June 18, 2020 2:58 PM > *To:* Discussion of Numerical Python > *Subject:* [Numpy-discussion] NumPy team update > > > > Hi all, > > > > The NumPy team is growing, and it's awesome to see everything that is > going on. Hard to keep up with, but that's a good thing! I think it's a > good time for an update on people who gained commit rights, or joined one > of the teams we now have. > > > > For those who haven't seen it yet, we have a team gallery at > https://numpy.org/gallery/team.html. It isn't yet updated for the changes > in this email, but gives a good picture of the current state. > > > > Matti Picus joined the Steering Council. He has been one of the driving > forces behind NumPy for well over two years now, and we're very glad to > have him join the council. > > > > Ross Barnowski, Melissa Weber Mendon?a, Josh Wilson and Bas van Beek > gained commit rights. Ross has worked on the docs and reviewed lots of doc > PRs for the last six months. Melissa has led the doc structuring and > tutorial writing effort and has done a good amount of f2py maintenance as > well. Josh and Bas have been pushing the type annotation work forward, > first in the numpy-stubs repo and now in master. It's great to have experts > in all these topics join the team. > > > > Furthermore, we now have 10+ people in the community calls, the triage > calls and the docs team calls (all bi-weekly and on the NumPy community > calendar [1] - everyone is welcome). And there's more going on - I feel > like I should mention some of the other excellent work going on: > > > > A lot of work is going into SIMD optimizations. Sayed Adel has made very > nice progress on implementing universal intrinsics (NEP 38), and Raghuveer > Devulapalli, Chunlin Fang and others have contributed SSE/AVX and ARM Neon > implementations for many functions. > > > > For the website, Shaloo Shalini has continued working on new case studies, > we're about to merge a really nice one on tracking animal movement. Ben > Nathanson has contributed his technical writing and editing skills to > improve our website and documentation content. And Isabela Presedo-Floyd > has taken up the challenge of redesigning the NumPy logo, and we're nearing > the end of the process there. > > > > The survey team has also been working hard. Inessa Pawson, Xiaoyi Deng, > Stephanie Mendoza, Ross Barnowski, Sebastian Berg and a number of > volunteers for translations are getting a really well-designed survey > together. > > > > And then of course there's both old hands and new people doing the regular > maintenance and enhancement work on the main repo. > > > > Writing this email started with "we just gave out some commit rights, we > should put that on the mailing list". Then I realized there's lots of other > people and activities that deserve a shout out. And probably more that I > forgot (if so, apologies!). I'll stop here - thanks everyone for all you do! > > > > Cheers, > > Ralf > > > > > > [1] > https://calendar.google.com/calendar?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20 > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Fri Jun 19 14:43:56 2020 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Fri, 19 Jun 2020 20:43:56 +0200 Subject: [Numpy-discussion] NumPy team update In-Reply-To: References: Message-ID: <44f0765b-7901-4774-a92b-ca7271079990@www.fastmail.com> Ralf, thank you very much for summarizing community movements?it is great to see all this growth. To all new committers and team members, thank you, and welcome! Your work is so appreciated. Keep up the good work! St?fan On Thu, Jun 18, 2020, at 23:57, Ralf Gommers wrote: > The NumPy team is growing, and it's awesome to see everything that is going on. Hard to keep up with, but that's a good thing! I think it's a good time for an update on people who gained commit rights, or joined one of the teams we now have. -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Fri Jun 19 19:23:13 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 19 Jun 2020 17:23:13 -0600 Subject: [Numpy-discussion] NumPy 1.19.0 release coming this weekend. Message-ID: Hi All, Just a heads up. There are no open PRs or issues with the 1.19.0 milestone and no reported problems with the 1.10.0rc2 release that I am aware of. Let me know if I have missed anything. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sat Jun 20 16:58:44 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 20 Jun 2020 14:58:44 -0600 Subject: [Numpy-discussion] NumPy 1.19.0 released Message-ID: Hi All, On behalf of the NumPy team I am pleased to announce that NumPy 1.19.0 has been released. This NumPy release supports Python 3.6-3.8 and is marked by the removal of much technical debt: support for Python 2 has been removed, many deprecations have been expired, and documentation has been improved. The polishing of the random module continues apace with bug fixes and better usability from Cython. Perhaps the most interesting thing for users will be the availability of wheels for aarch64 and PyPY. Downstream developers should use Cython >= 0.29.16 for Python 3.8 support and OpenBLAS >= 3.7 to avoid wrong results on the Skylake architecture. The NumPy Wheels for this release can be downloaded from PyPI , source archives, release notes, and wheel hashes are available from Github . Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. *Contributors* A total of 126 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Alex Henrie - Alexandre de Siqueira + - Andras Deak - Andrea Sangalli + - Andreas Kl?ckner + - Andrei Shirobokov + - Anirudh Subramanian + - Anne Bonner - Anton Ritter-Gogerly + - Benjamin Trendelkamp-Schroer + - Bharat Raghunathan - Brandt Bucher + - Brian Wignall - Bui Duc Minh + - Changqing Li + - Charles Harris - Chris Barker - Chris Holland + - Christian Kastner + - Chunlin + - Chunlin Fang + - Damien Caliste + - Dan Allan - Daniel Hrisca - Daniel Povey + - Dustan Levenstein + - Emmanuelle Gouillart + - Eric Larson - Eric M. Bray - Eric Mariasis + - Eric Wieser - Erik Welch + - Fabio Zeiser + - Gabriel Gerlero + - Ganesh Kathiresan + - Gengxin Xie + - Guilherme Leobas - Guillaume Peillex + - Hameer Abbasi - Hao Jin + - Harshal Prakash Patankar + - Heshy Roskes + - Himanshu Garg + - Huon Wilson + - John Han + - John Kirkham - Jon Dufresne - Jon Morris + - Josh Wilson - Justus Magin - Kai Striega - Kerem Halla? + - Kevin Sheppard - Kirill Zinovjev + - Marcin Podhajski + - Mark Harfouche - Marten van Kerkwijk - Martin Michlmayr + - Masashi Kishimoto + - Mathieu Lamarre - Matt Hancock + - MatteoRaso + - Matthew Harrigan - Matthias Bussonnier - Matti Picus - Max Balandat + - Maximilian Konrad + - Maxwell Aladago - Maxwell Bileschi + - Melissa Weber Mendon?a + - Michael Felt - Michael Hirsch + - Mike Taves - Nico Schl?mer - Pan Jan + - Paul Rougieux + - Pauli Virtanen - Peter Andreas Entschev - Petre-Flaviu Gostin + - Pierre de Buyl - Piotr Gai?ski + - Przemyslaw Bartosik + - Raghuveer Devulapalli - Rakesh Vasudevan + - Ralf Gommers - RenaRuirui + - Robert Kern - Roman Yurchak - Ross Barnowski + - Ryan + - Ryan Soklaski - Sanjeev Kumar + - SanthoshBala18 + - Sayed Adel + - Sebastian Berg - Seth Troisi - Sha Liu + - Siba Smarak Panigrahi + - Simon Gasse + - Stephan Hoyer - Steve Dower + - Thomas A Caswell - Till Hoffmann + - Tim Hoffmann - Tina Oberoi + - Tirth Patel - Tyler Reddy - Warren Weckesser - Wojciech Rzadkowski + - Xavier Thomas + - Yilin LI + - Zac Hatfield-Dodds + - Z? Vin?cius + - @Adam + - @Anthony + - @Jim + - @bartosz-grabowski + - @dojafrat + - @gamboon + - @jfbu + - @keremh + - @mayeut + - @ndunnewind + - @nglinh + - @shreepads + - @sslivkoff + Cheers, Charles Harris -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Sun Jun 21 15:21:09 2020 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Sun, 21 Jun 2020 13:21:09 -0600 Subject: [Numpy-discussion] ANN: SciPy 1.5.0 Message-ID: Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.5.0. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.5.0 One of a few ways to install this release with pip: pip install scipy==1.5.0 ========================== SciPy 1.5.0 Release Notes ========================== SciPy 1.5.0 is the culmination of 6 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation. There have been a number of deprecations and API changes in this release, which are documented below. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Before upgrading, we recommend that users check that their own code does not use deprecated SciPy functionality (to do so, run your code with ``python -Wd`` and check for ``DeprecationWarning`` s). Our development attention will now shift to bug-fix releases on the 1.5.x branch, and on adding new features on the master branch. This release requires Python 3.6+ and NumPy 1.14.5 or greater. For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required. Highlights of this release ---------------------------------- - wrappers for more than a dozen new ``LAPACK`` routines are now available in `scipy.linalg.lapack` - Improved support for leveraging 64-bit integer size from linear algebra backends - addition of the probability distribution for two-sided one-sample Kolmogorov-Smirnov tests New features ============ `scipy.cluster` improvements --------------------------------------- Initialization of `scipy.cluster.vq.kmeans2` using ``minit="++"`` had a quadratic complexity in the number of samples. It has been improved, resulting in a much faster initialization with quasi-linear complexity. `scipy.cluster.hierarchy.dendrogram` now respects the ``matplotlib`` color palette `scipy.fft` improvements ---------------------------------- A new keyword-only argument ``plan`` is added to all FFT functions in this module. It is reserved for passing in a precomputed plan from libraries providing a FFT backend (such as ``PyFFTW`` and ``mkl-fft``), and it is currently not used in SciPy. `scipy.io` improvements --------------------------------- `scipy.io.wavfile` error messages are more explicit about what's wrong, and extraneous bytes at the ends of files are ignored instead of raising an error when the data has successfully been read. `scipy.io.loadmat` gained a ``simplify_cells`` parameter, which if set to ``True`` simplifies the structure of the return value if the ``.mat`` file contains cell arrays. ``pathlib.Path`` objects are now supported in `scipy.io` Matrix Market I/O functions `scipy.linalg` improvements -------------------------------------- `scipy.linalg.eigh` has been improved. Now various ``LAPACK`` drivers can be selected at will and also subsets of eigenvalues can be requested via ``subset_by_value`` keyword. Another keyword ``subset_by_index`` is introduced. Keywords ``turbo`` and ``eigvals`` are deprecated. Similarly, standard and generalized Hermitian eigenvalue ``LAPACK`` routines ``?evx`` are added and existing ones now have full ``_lwork`` counterparts. Wrappers for the following ``LAPACK`` routines have been added to `scipy.linalg.lapack`: - ``?getc2``: computes the LU factorization of a general matrix with complete pivoting - ``?gesc2``: solves a linear system given an LU factorization from ``?getc2`` - ``?gejsv``: computes the singular value decomposition of a general matrix with higher accuracy calculation of tiny singular values and their corresponding singular vectors - ``?geqrfp``: computes the QR factorization of a general matrix with non-negative elements on the diagonal of R - ``?gtsvx``: solves a linear system with general tridiagonal matrix - ``?gttrf``: computes the LU factorization of a tridiagonal matrix - ``?gttrs``: solves a linear system given an LU factorization from ``?gttrf`` - ``?ptsvx``: solves a linear system with symmetric positive definite tridiagonal matrix - ``?pttrf``: computes the LU factorization of a symmetric positive definite tridiagonal matrix - ``?pttrs``: solves a linear system given an LU factorization from ``?pttrf`` - ``?pteqr``: computes the eigenvectors and eigenvalues of a positive definite tridiagonal matrix - ``?tbtrs``: solves a linear system with a triangular banded matrix - ``?csd``: computes the Cosine Sine decomposition of an orthogonal/unitary matrix Generalized QR factorization routines (``?geqrf``) now have full ``_lwork`` counterparts. `scipy.linalg.cossin` Cosine Sine decomposition of unitary matrices has been added. The function `scipy.linalg.khatri_rao`, which computes the Khatri-Rao product, was added. The new function `scipy.linalg.convolution_matrix` constructs the Toeplitz matrix representing one-dimensional convolution. `scipy.optimize` improvements ----------------------------------------- The finite difference numerical differentiation used in various ``minimize`` methods that use gradients has several new features: - 2-point, 3-point, or complex step finite differences can be used. Previously only a 2-step finite difference was available. - There is now the possibility to use a relative step size, previously only an absolute step size was available. - If the ``minimize`` method uses bounds the numerical differentiation strictly obeys those limits. - The numerical differentiation machinery now makes use of a simple cache, which in some cases can reduce the number of function evaluations. - ``minimize``'s ``method= 'powell'`` now supports simple bound constraints There have been several improvements to `scipy.optimize.linprog`: - The ``linprog`` benchmark suite has been expanded considerably. - ``linprog``'s dense pivot-based redundancy removal routine and sparse presolve are faster - When ``scikit-sparse`` is available, solving sparse problems with ``method='interior-point'`` is faster The caching of values when optimizing a function returning both value and gradient together has been improved, avoiding repeated function evaluations when using a ``HessianApproximation`` such as ``BFGS``. ``differential_evolution`` can now use the modern ``np.random.Generator`` as well as the legacy ``np.random.RandomState`` as a seed. `scipy.signal` improvements -------------------------------------- A new optional argument ``include_nyquist`` is added to ``freqz`` functions in this module. It is used for including the last frequency (Nyquist frequency). `scipy.signal.find_peaks_cwt` now accepts a ``window_size`` parameter for the size of the window used to calculate the noise floor. `scipy.sparse` improvements ---------------------------------------- Outer indexing is now faster when using a 2d column vector to select column indices. `scipy.sparse.lil.tocsr` is faster Fixed/improved comparisons between pydata sparse arrays and sparse matrices BSR format sparse multiplication performance has been improved. `scipy.sparse.linalg.LinearOperator` has gained the new ``ndim`` class attribute `scipy.spatial` improvements --------------------------------------- `scipy.spatial.geometric_slerp` has been added to enable geometric spherical linear interpolation on an n-sphere `scipy.spatial.SphericalVoronoi` now supports calculation of region areas in 2D and 3D cases The tree building algorithm used by ``cKDTree`` has improved from quadratic worst case time complexity to loglinear. Benchmarks are also now available for building and querying of balanced/unbalanced kd-trees. `scipy.special` improvements ---------------------------------------- The following functions now have Cython interfaces in `cython_special`: - `scipy.special.erfinv` - `scipy.special.erfcinv` - `scipy.special.spherical_jn` - `scipy.special.spherical_yn` - `scipy.special.spherical_in` - `scipy.special.spherical_kn` `scipy.special.log_softmax` has been added to calculate the logarithm of softmax function. It provides better accuracy than ``log(scipy.special.softmax(x))`` for inputs that make softmax saturate. `scipy.stats` improvements ------------------------------------ The function for generating random samples in `scipy.stats.dlaplace` has been improved. The new function is approximately twice as fast with a memory footprint reduction between 25 % and 60 % (see gh-11069). `scipy.stats` functions that accept a seed for reproducible calculations using random number generation (e.g. random variates from distributions) can now use the modern ``np.random.Generator`` as well as the legacy ``np.random.RandomState`` as a seed. The ``axis`` parameter was added to `scipy.stats.rankdata`. This allows slices of an array along the given axis to be ranked independently. The ``axis`` parameter was added to `scipy.stats.f_oneway`, allowing it to compute multiple one-way ANOVA tests for data stored in n-dimensional arrays. The performance of ``f_oneway`` was also improved for some cases. The PDF and CDF methods for ``stats.geninvgauss`` are now significantly faster as the numerical integration to calculate the CDF uses a Cython based ``LowLevelCallable``. Moments of the normal distribution (`scipy.stats.norm`) are now calculated using analytical formulas instead of numerical integration for greater speed and accuracy Moments and entropy trapezoidal distribution (`scipy.stats.trapz`) are now calculated using analytical formulas instead of numerical integration for greater speed and accuracy Methods of the truncated normal distribution (`scipy.stats.truncnorm`), especially ``_rvs``, are significantly faster after a complete rewrite. The `fit` method of the Laplace distribution, `scipy.stats.laplace`, now uses the analytical formulas for the maximum likelihood estimates of the parameters. Generation of random variates is now thread safe for all SciPy distributions. 3rd-party distributions may need to modify the signature of the ``_rvs()`` method to conform to ``_rvs(self, ..., size=None, random_state=None)``. (A one-time VisibleDeprecationWarning is emitted when using non-conformant distributions.) The Kolmogorov-Smirnov two-sided test statistic distribution (`scipy.stats.kstwo`) was added. Calculates the distribution of the K-S two-sided statistic ``D_n`` for a sample of size n, using a mixture of exact and asymptotic algorithms. The new function ``median_abs_deviation`` replaces the deprecated ``median_absolute_deviation``. The ``wilcoxon`` function now computes the p-value for Wilcoxon's signed rank test using the exact distribution for inputs up to length 25. The function has a new ``mode`` parameter to specify how the p-value is to be computed. The default is ``"auto"``, which uses the exact distribution for inputs up to length 25 and the normal approximation for larger inputs. Added a new Cython-based implementation to evaluate guassian kernel estimates, which should improve the performance of ``gaussian_kde`` The ``winsorize`` function now has a ``nan_policy`` argument for refined handling of ``nan`` input values. The ``binned_statistic_dd`` function with ``statistic="std"`` performance was improved by ~4x. ``scipy.stats.kstest(rvs, cdf,...)`` now handles both one-sample and two-sample testing. The one-sample variation uses `scipy.stats.ksone` (or `scipy.stats.kstwo` with back off to `scipy.stats.kstwobign`) to calculate the p-value. The two-sample variation, invoked if ``cdf`` is array_like, uses an algorithm described by Hodges to compute the probability directly, only backing off to `scipy.stats.kstwo` in case of overflow. The result in both cases is more accurate p-values, especially for two-sample testing with smaller (or quite different) sizes. `scipy.stats.maxwell` performance improvements include a 20 % speed up for `fit()`` and 5 % for ``pdf()`` `scipy.stats.shapiro` and `scipy.stats.jarque_bera` now return a named tuple for greater consistency with other ``stats`` functions Deprecated features ================ `scipy` deprecations ---------------------------- `scipy.special` changes -------------------------------- The ``bdtr``, ``bdtrc``, and ``bdtri`` functions are deprecating non-negative non-integral ``n`` arguments. `scipy.stats` changes ----------------------------- The function ``median_absolute_deviation`` is deprecated. Use ``median_abs_deviation`` instead. The use of the string ``"raw"`` with the ``scale`` parameter of ``iqr`` is deprecated. Use ``scale=1`` instead. Backwards incompatible changes ========================== `scipy.interpolate` changes ------------------------------------- `scipy.linalg` changes ------------------------------ The output signatures of ``?syevr``, ``?heevr`` have been changed from ``w, v, info`` to ``w, v, m, isuppz, info`` The order of output arguments ``w``, ``v`` of ``{gv, gvd, gvx}`` is swapped. `scipy.signal` changes ------------------------------- The output length of `scipy.signal.upfirdn` has been corrected, resulting outputs may now be shorter for some combinations of up/down ratios and input signal and filter lengths. `scipy.signal.resample` now supports a ``domain`` keyword argument for specification of time or frequency domain input. Other changes ============= Improved support for leveraging 64-bit integer size from linear algebra backends in several parts of the SciPy codebase. Shims designed to ensure the compatibility of SciPy with Python 2.7 have now been removed. Many warnings due to unused imports and unused assignments have been addressed. Many usage examples were added to function docstrings, and many input validations and intuitive exception messages have been added throughout the codebase. Early stage adoption of type annotations in a few parts of the codebase Authors ======= * @endolith * Hameer Abbasi * ADmitri + * Wesley Alves + * Berkay Antmen + * Sylwester Arabas + * Arne K?derle + * Christoph Baumgarten * Peter Bell * Felix Berkenkamp * Jord?o Bragantini + * Clemens Brunner + * Evgeni Burovski * Matthias Bussonnier + * CJ Carey * Derrick Chambers + * Leander Claes + * Christian Clauss * Luigi F. Cruz + * dankleeman * Andras Deak * Milad Sadeghi DM + * jeremie du boisberranger + * Stefan Endres * Malte Esders + * Leo Fang + * felixhekhorn + * Isuru Fernando * Andrew Fowlie * Lakshay Garg + * Gaurav Gijare + * Ralf Gommers * Emmanuelle Gouillart + * Kevin Green + * Martin Grignard + * Maja Gwozdz * Sturla Molden * gyu-don + * Matt Haberland * hakeemo + * Charles Harris * Alex Henrie * Santi Hernandez + * William Hickman + * Till Hoffmann + * Joseph T. Iosue + * Anany Shrey Jain * Jakob Jakobson * Charles Jekel + * Julien Jerphanion + * Jiacheng-Liu + * Christoph Kecht + * Paul Kienzle + * Reidar Kind + * Dmitry E. Kislov + * Konrad + * Konrad0 * Takuya KOUMURA + * Krzysztof Pi?ro * Peter Mahler Larsen * Eric Larson * Antony Lee * Gregory Lee + * Gregory R. Lee * Chelsea Liu * Cong Ma + * Kevin Mader + * Maja Gw??d? + * Alex Marvin + * Matthias K?mmerer * Nikolay Mayorov * Mazay0 + * G. D. McBain * Nicholas McKibben + * Sabrina J. Mielke + * Sebastian J. Mielke + * Milo? Komar?evi? + * Shubham Mishra + * Santiago M. Mola + * Grzegorz Mrukwa + * Peyton Murray * Andrew Nelson * Nico Schl?mer * nwjenkins + * odidev + * Sambit Panda * Vikas Pandey + * Rick Paris + * Harshal Prakash Patankar + * Balint Pato + * Matti Picus * Ilhan Polat * poom + * Siddhesh Poyarekar * Vladyslav Rachek + * Bharat Raghunathan * Manu Rajput + * Tyler Reddy * Andrew Reed + * Lucas Roberts * Ariel Rokem * Heshy Roskes * Matt Ruffalo * Atsushi Sakai + * Benjamin Santos + * Christoph Schock + * Lisa Schwetlick + * Chris Simpson + * Leo Singer * Kai Striega * S?ren Fuglede J?rgensen * Kale-ab Tessera + * Seth Troisi + * Robert Uhl + * Paul van Mulbregt * Vasiliy + * Isaac Virshup + * Pauli Virtanen * Shakthi Visagan + * Jan Vleeshouwers + * Sam Wallan + * Lijun Wang + * Warren Weckesser * Richard Weiss + * wenhui-prudencemed + * Eric Wieser * Josh Wilson * James Wright + * Ruslan Yevdokymov + * Ziyao Zhang + A total of 129 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.0 ------------------------------- * `#1455 `__: ellipord does returns bogus values if gstop or gpass are negative... * `#1968 `__: correlate2d's output does not agree with correlate's output in... * `#2744 `__: BUG: optimize: '\*\*kw' argument of 'newton_krylov' is not documented * `#4755 `__: TypeError: data type "`__: scipy.optimize maxiter option not working as expected * `#5144 `__: RuntimeWarning on csgraph.shortest_path when edge lengths are... * `#5309 `__: Documentation of 'hybr' and 'lm' inconsistent in optimize.root * `#6026 `__: Replace approx_grad with _numdiff.approx_derivative in scipy.optimize * `#6502 `__: Computing Eigenvalues in an Interval with LAPACK * `#7058 `__: Errors in special.bdtri and special.bdtr for non-integer k values * `#7700 `__: SuperLU does not respect perm_c="NATURAL" * `#7895 `__: Improvements to io.loadmat * `#8205 `__: ValueError in scipy.linalg.eigvalsh for large matrix * `#8278 `__: Memory limit for scipy.sparse.linalg.spsolve with scikit-umfpack * `#8327 `__: scipy.stats.mstats.winsorize NaN handling * `#8341 `__: scipy.stats.ks_2samp for masked and unmasked data give different... * `#8748 `__: scipy.stats.kstest for same distribution: p-values nonuniform * `#9042 `__: optimize: Incorrect statement about \`jac\` in the \`minimize\`... * `#9197 `__: problem with scipy.signal.butter with 1000+ points array * `#9212 `__: EIGH very very slow --> suggesting an easy fix * `#9553 `__: ndimage routines behave badly when output has memory overlap... * `#9632 `__: ndimage.maximum_filter undocumented behaviour using footprint... * `#9658 `__: `scipy.optimize.minimize(method='COBYLA')` not threadsafe * `#9710 `__: stats.weightedtau([1], [1.0]) SEGFAULTs * `#9797 `__: Master Tracker for some Kolmogorov-Smirnov test Issues * `#9844 `__: scipy.signal.upfirdn gives different length matrix versus MATLAB... * `#9872 `__: scipy.signal.convolve is slower when vectorized * `#9913 `__: BUG: No dt in StateSpace operations * `#10014 `__: Distribution names \`weibull_min\`and \`weibull_max\` should... * `#10159 `__: BUG: stats: chisquare returns incorrect results for arrays of... * `#10302 `__: scipy.fft: Add a \`plan\` argument * `#10332 `__: 'Incomplete wav chunk' inconsistent/reason unknown * `#10441 `__: Remove uses of \`numpy.dual\`? * `#10558 `__: Document implicit sum in csr_matrix() constructor * `#10788 `__: LU with full pivoting * `#10841 `__: Unexpected behavior in linalg.blas.dtrmm wrapper * `#10919 `__: optimize._lbfgsb setulb() function violates parameter bounds * `#10963 `__: kstest, ks_2samp: confusing \`mode\` argument descriptions * `#11022 `__: Unexpected Result in factorial function with NaN input * `#11028 `__: Documentation error in optimize.minimize * `#11058 `__: Adding logsoftmax function * `#11076 `__: ValueError: Unknown wave file format * `#11090 `__: Misconception of the median absolute deviation in stats? * `#11095 `__: BUG: find_peaks_cwt test failures in 32-bit Linux wheels * `#11107 `__: scipy.io.mmread generated an error "TypeError: startswith first... * `#11123 `__: Add wrapper for ?gttrf/?gttrs * `#11128 `__: OverflowError in resample_poly (upfirdn) * `#11132 `__: Possible bug: rv_discret.ppf for percentiles 0 and 100 and loc... * `#11163 `__: Comparisons between scipy spmatrix and can sparse.SparseArray... * `#11168 `__: Generalized Pareto variance inaccurate for concentrations near... * `#11169 `__: Add wrapper for ?geqrfp * `#11184 `__: 2-sided Kolmogorov Smirnov returns p-value of 1 * `#11185 `__: The .roots() or solve() function of scipy.interpolate.CubicHermiteSpline... * `#11190 `__: Add wrapper for ?tbtrs * `#11200 `__: Can no longer slice csr_matrix in 1.3.0 * `#11207 `__: _minimize_scalar_bounded: reference before assignment * `#11216 `__: linprog: interior-point: Cholmod reordering can be reused * `#11223 `__: Add wrappers for ?pttrf, ?pttrs * `#11224 `__: Add wrapperfor ?pteqr * `#11235 `__: MAINT: Missleading Error Message for IIR Filter * `#11244 `__: Missing reference in \`scipy.optimize.line_search\` * `#11262 `__: Hermitian Eigenvalue Problem eigh() API and wrapper change proposal * `#11266 `__: Sparse matrix constructor data type detection changes on Numpy... * `#11270 `__: CI failing: Travis CI Py36 refguide and Linux_Python_36_32bit_full... * `#11279 `__: linalg.eigh checks whole array for finite values * `#11295 `__: CI: azure does not auto-cancel old jobs on pushes * `#11299 `__: stats.truncnorm.rvs 100x slower in v1.4.x than v1.3.3 * `#11315 `__: BUG: special: rgamma on negative integers smaller -34 * `#11319 `__: Missing \`int64_t\` declaration in rectangular_lsap.cpp * `#11323 `__: Compilation failure due to missing symbol pthread_atfork * `#11332 `__: BUG: directed_hausdorff distance on sets u and v when u is a... * `#11350 `__: Khatri-Rao product * `#11354 `__: ENH: Add wrapper for ?gejsv * `#11361 `__: Dropped NaN in eval_genlaguerre function * `#11363 `__: Dropped NaN in hyperu function * `#11365 `__: scipy.stats.binned_statistic regressed in v1.4.0 * `#11369 `__: Dropped NaN in eval_hermite * `#11370 `__: Dropped NaN in eval_gegenbauer * `#11373 `__: Add wrapper for ?gtsvx * `#11374 `__: Add wrapper for ?ptsvx * `#11391 `__: csgraph.minimum_spanning_tree loses precision * `#11398 `__: Update stats to cope with \`np.random.Generator\` machinery * `#11412 `__: Array copying causes unwanted type casting from complex to float... * `#11415 `__: Where is the Wiener Filter derived from? * `#11416 `__: _lib._util.getargspec_no_self is missing KEYWORD_ONLY support * `#11428 `__: Documentation on SHGO inequality constraints appears contradictory * `#11429 `__: Add LAPACK's ZUNCSD cosine sine decomposition * `#11438 `__: run_dualannealing passes bounds incorrectly in benchmarks/optimize.py * `#11441 `__: Can't run optimize benchmarks * `#11442 `__: Chebyshev weights * `#11448 `__: Wrongly typed comparison in integrate.quad * `#11458 `__: BUG: maximum_bipartite_matching produces infeasible solution * `#11460 `__: CI failing: 2 Travis CI tests fail with numpy build or version... * `#11462 `__: Bug on "++" initialization on "kmeans2" * `#11464 `__: Shouldn't data type of KDE evaluation should be like in the input... * `#11468 `__: performance of binned_statistics_2d 100x slowdown from 1.3.2... * `#11484 `__: Callback function doesn't give the same value as the one being... * `#11492 `__: Confusing dendrogram labelling * `#11493 `__: scipy.optimize.least_squares fails if the return array of the... * `#11494 `__: Error performing kronecker product between large sparse vectors * `#11503 `__: medfilt produces 0 on input of length 1 * `#11529 `__: Pyflakes generates almost 700 warnings. * `#11566 `__: irfft/irfft2/irfftn docs are slightly confusing re: input type. * `#11572 `__: least_squares: too small tolerances not catched with method='lm' * `#11581 `__: DOC: scipy.interpolate.RectSphereBivariateSpline * `#11586 `__: Differential evolution breaks with LinearConstraints with sparse... * `#11595 `__: scipy.spatial.cKDTree construction slow for some datasets * `#11598 `__: output of special.voigt_profile when sigma=0 * `#11601 `__: linalg tests failing in runtests.py * `#11602 `__: scipy.optimize.linear_sum_assignment returns reverse diagonal... * `#11610 `__: Analytic formula for normal moments * `#11611 `__: Build failure with gfortran 10 * `#11613 `__: TST, MAINT: test_quadpack TestCtypesQuad wasn't fully migrated... * `#11630 `__: SmoothBivariateSpline bbox parameter * `#11635 `__: typo in docstring of scipy.stats.norminvgauss * `#11637 `__: BUG: core dumps when calling scipy.interpolate.interp1d with... * `#11638 `__: better documentation for 'return_all' option in minimize(Nelder... * `#11652 `__: TST, MAINT: CI failures for pre-release NumPy wheels * `#11659 `__: optimize.fmin_l_bfgs_b needs bound check and appropiate error... * `#11660 `__: BUG/ENH: distribution.ncf with nc=0 returns nan * `#11661 `__: scipy.ndimage.convolve1d and correlate1d don't behave properly... * `#11669 `__: p-value varies with the order of the data * `#11676 `__: documentation of scipy.spatial.HalfspaceIntersection: wrong method... * `#11685 `__: Rotation cannot be expressed as matrix * `#11686 `__: MAINT: mypy imports of Cython "modules" * `#11693 `__: TestDifferentialEvolutionSolver::test_L4 failing in CI * `#11696 `__: DOC: incorrect compiler information for macOS in docs * `#11709 `__: eigh() tests fail to pass, crash Python with seemingly ramdom... * `#11763 `__: Small error in gamma continuous rv fit comments * `#11769 `__: truncnorm.rvs Weird Behaviors * `#11770 `__: crash in TestEigh::test_value_subsets * `#11795 `__: trapz distribution mean computed using single precision * `#11800 `__: Segmentation fault in scipy.odr for multidimensional independent... * `#11811 `__: pyflakes silently failing on travis-ci * `#11826 `__: Error with _fblas * `#11827 `__: \`fft.tests.test_numpy.test_multiprocess\` hangs on Python3.8... * `#11835 `__: tests with \`multiprocessing\` hang on Python 3.8 on macOS * `#11839 `__: linalg.expm returns nans with RuntimeWarning: overflow encountered... * `#11856 `__: Documentation of fit methods for \`weibull_min\` and \`exponweib\`... * `#11868 `__: Function always evaluated twice when using HessianUpdateStrategy... * `#11875 `__: Typo in the docstring of simps() * `#11877 `__: kmeans2 '++' method is orders of magnitude slower than sklearn.cluster.KMeans() * `#11884 `__: The upper code lines are dead code * `#11886 `__: Array shape mismatch in scipy.optimize * `#11892 `__: BUG: stats: Incorrect handling of edges cases by ttest_rel and... * `#11908 `__: LinearOperator should have ndim attribute * `#11910 `__: Documentation missing for what M is in init argument * `#11922 `__: macOS actions CI has started failing in last couple of days. * `#11928 `__: DOC: signal: Wrong description for sepfir2d, cspline2d, qspline2d * `#11944 `__: curve_fit documentation unclear on default value of absolute_sigma * `#11945 `__: Add a (potentially temporary) py.typed file? * `#11949 `__: ValueError 'k exceeds matrix dimensions' for sparse.diagonal()... * `#11951 `__: BUG: asv benchmark failed because of cython version * `#11967 `__: BLD: Azure windows runs complain about drives * `#11973 `__: oaconvolve(a,b,'same') differs in shape from convolve(a,b,'same')... * `#12002 `__: pybind11 license * `#12003 `__: MAINT: circular SphericalVoronoi input * `#12015 `__: Reordering of CSC matrix breaks when you go above int32 limits * `#12031 `__: Documentation Rendering Issues Visible in CircleCI Artifacts * `#12037 `__: MAINT, CI: new Cython 3.0a4 issue * `#12087 `__: DOC: some odr models are missing docs * `#12119 `__: signal.fftconvolve no longer convolves types f8 and numpy.float64 * `#12149 `__: Documentation of Rosenbrock function * `#12173 `__: Large memory usage when indexing sparse matrices with \`np.ix_\` * `#12178 `__: BUG: stats: Some discrete distributions don't accept lists of... * `#12220 `__: BUG, REL: gh_lists.py compromised scraping * `#12239 `__: BUG: median absolute deviation handling of nan * `#12301 `__: integer overflow in scipy.sparse.sputils.check_shape when matrix size > 2^32 * `#12314 `__: scipy.spatial.transform.Rotation multiplication does not normalize quaternion Pull requests for 1.5.0 ------------------------------ * `#6510 `__: Add Eigenvalue Range Functionality for Symmetric Eigenvalue Problems * `#9525 `__: BUG: SuperLU 'NATURAL' order applies a column permutation * `#9634 `__: Add the number of Jacobian evaluations to the output of L-BFGS-B. * `#9719 `__: ENH: Added kstwo probability distribution for two-sided one-sample... * `#9783 `__: WIP: optimize: added (dense) interpolative decomposition redundancy... * `#10053 `__: Adding docstring to weibull_min and weibull_max based on issue... * `#10136 `__: DEP: Add warning to linprog_verbose_callback * `#10380 `__: ENH: add geometric_slerp * `#10602 `__: MAINT: optimize: refactor common linprog arguments into namedtuple * `#10648 `__: Bounds for the Powell minimization method * `#10673 `__: ENH: approx_fprime --> approx_derivative * `#10759 `__: ENH: calculation of region areas in spatial.SphericalVoronoi * `#10762 `__: BENCH: optimize: more comprehensive linprog benchmarking * `#10796 `__: ENH exact p-values of wilcoxon test in scipy.stats * `#10797 `__: ENH: linalg: LU with full pivoting (wrappers for ?getc2/?gesc2) * `#10824 `__: ENH: Fast gaussian kernel estimator * `#10942 `__: BUG: prevent bound violation in L-BFGS-B optimize method * `#11003 `__: ENH: add scipy.linalg.convolution_matrix * `#11023 `__: improving error message for cubic-interpolate with duplicates * `#11045 `__: MAINT: make bdt{r,rc,ri}() functions accept double n,k args +... * `#11063 `__: Fix documentation error in optimize.minimize * `#11069 `__: ENH: stats.dlaplace.rvs improvements * `#11071 `__: DOC: Added examples to maximum_position in ndimage * `#11075 `__: DOC: Update stylistic consistency in multiple files * `#11097 `__: BUG: stats: fixing chisquare to return correct results for arrays... * `#11110 `__: ENH: special: Cythonise erfinv, erfcinv * `#11112 `__: BUG: special: Return NaN outside the domain of \`eval_hermite\` * `#11114 `__: BUG: special: fix \`hyp1f1\` for nonnegative integral \`a\` and... * `#11115 `__: DOC: special: add docstrings for \`kei\`, \`ker\`, \`keip\`,... * `#11130 `__: ENH: support for circular input * `#11136 `__: BUG: expm handling of empty input * `#11138 `__: DOC: stylistic consistency, punctuation, etc. * `#11139 `__: MAINT: cluster: use cython_blas, remove handwritten BLAS wrappers * `#11146 `__: DOC: update docs on bp parameter for detrend * `#11151 `__: DOC: special: add docstrings for \`bei\`, \`ber\`, \`beip\`,... * `#11156 `__: ENH: add input validation for ellipord. * `#11157 `__: DOC: stylistic revision, punctuation, consistency * `#11160 `__: ignore warning on 0 \* inf in basin hopping * `#11162 `__: DOC: minor stylistic revision, undo changes * `#11164 `__: ENH/ BUG: Pydata sparse equality * `#11171 `__: Fix dtype validation of "seuclidean" metric V parameter * `#11177 `__: BUG: stats: Improve genpareto stats calculations. * `#11180 `__: MAINT: stats: Some clean up in test_distributions.py. * `#11187 `__: ENH: add functionality log_softmax to SciPy.special. * `#11188 `__: MAINT: add rvs method to argus in scipy.stats * `#11196 `__: DOC: special: add to docstrings of Kelvin zeros functions * `#11202 `__: BUG: fix edge counting in shortest_path * `#11218 `__: BUG: scipy/interpolate: fix PPoly/Cubic\*Spline roots() extrapolation... * `#11225 `__: Add a warning to constant input for spearmanr() function * `#11226 `__: Speed up of interior-point method for cholesky solver * `#11229 `__: BUG: Explicit dtype specification in _upfirdn.py * `#11230 `__: Additional citation for optimize tutorial * `#11231 `__: Adds SLSQP test for duplicate f-evals (#10738) * `#11236 `__: MAINT: Improved error message for Wn range in iirfilter. * `#11245 `__: ENH: optimize: dense redundancy removal routine optimizations * `#11247 `__: MAINT: Remove _lib/_numpy_compat.py * `#11248 `__: BUG: rv_discrete.ppf() to handle loc * `#11251 `__: DOC: add reference for linesearch zoom algorithm * `#11253 `__: BUG: fix kendalltau issue where p-value becomes >1 * `#11254 `__: MAINT: make special.factorial handle nan correctly * `#11256 `__: DOC: Updated documentation for scipy.linalg.qr * `#11265 `__: Fix: Can no longer slice csr_matrix in 1.3.0 * `#11267 `__: BUG: Rework the scaling in the ks_2samp two-sided exact test. * `#11268 `__: DOC: example of NonLinearConstraint * `#11269 `__: Fix: Sparse matrix constructor data type detection changes on... * `#11276 `__: BLD: update minimum Python, NumPy, Cython, Pybind11 versions * `#11277 `__: MAINT: Cleanup conditionals for unsupported numpy verisons * `#11278 `__: MAINT: Cleanup stats.iqr workarounds for unsupported NumPy versions * `#11282 `__: TST/CI: improve traceback formatting for test failures * `#11284 `__: fix docs & behavior for mode sequences in ndimage filters * `#11285 `__: DOC: special: complete the docstrings of Chi-square functions * `#11286 `__: BUG: make loadmat/savemat file opening close resources correctly * `#11287 `__: CI: skip Azure and TravisCI builds on merges and direct pushes... * `#11288 `__: DOC: Fix import in scipy.io.wavfile.read sample code * `#11289 `__: BUG: Use context manager for open * `#11290 `__: MAINT: Remove _lib._version in favour of _lib._pep440 * `#11292 `__: DOC: special: add docstrings for various convenience functions * `#11293 `__: DOC: special: fix typo in \`chdtri\` docstring * `#11296 `__: DOC: special: add to docstrings of Bessel zeros and derivatives * `#11297 `__: DOC: special: add parameters/returns sections for Bessel integrals * `#11300 `__: MAINT: Update vendored uarray version * `#11301 `__: CI: azure conditions should require succeeded() * `#11302 `__: ENH: build infrastructure for ILP64 BLAS + ARPACK conversion * `#11303 `__: DOC: special: fix typo in \`besselpoly\` docstring * `#11304 `__: ENH: MAINT: Rewrite of eigh() and relevant wrappers * `#11306 `__: TST: skip test_aligned_mem linalg test that is crashing on ppcle64 * `#11307 `__: MAINT: Fix typo 'solutuion' -> 'solution' * `#11308 `__: ENH: do not create 1d array out of a scalar * `#11310 `__: MAINT: clean up object array creation, scalar/1d confusion * `#11311 `__: DOC: Specify custom callable option for metric in cluster.hierarchy.fclusterdata * `#11316 `__: BUG: special: fix behavior for \`rgamma\` zeros * `#11317 `__: BUG: fix floating-point literal comparisons under C99 * `#11318 `__: TST: optimize: mark two linprog tests for skipping * `#11320 `__: BUG: Include \`int64_t\` declaration to \`rectangular_lsap.cpp\` * `#11330 `__: MAINT: Update vendored pypocketfft version * `#11333 `__: BUG: directed_hausdorff subset fix * `#11335 `__: [ENH] sparse: Loosen check for sparse outer indexing fast path * `#11337 `__: Undefined name 'e' in pavement.py * `#11338 `__: scipyoptdoc.py: Remove unused variable 'sixu' * `#11340 `__: xrange() was removed in Python 3 in favor of range() * `#11342 `__: range() was removed in Py3 in _binned_statistic.py * `#11343 `__: BUG: constants: fix 'exact' values table * `#11347 `__: ENH: add input validation function and apply it to needed functions * `#11348 `__: MAINT: remove six.string_types usages * `#11349 `__: MAINT: minor doc fix _minimize_trustregion_constr * `#11353 `__: MAINT: py3 remove various six usages * `#11358 `__: ENH: optimize: Use CSR format instead of LIL for speed * `#11362 `__: MAINT: sys.version_info >= 3.5 * `#11364 `__: ENH: cache square of sums for f_oneway * `#11368 `__: ENH: add optional argument, "include_nyquist", for freqz() * `#11372 `__: BENCH: optimize: added linprog presolve benchmarks * `#11376 `__: ENH: Add wrapper for ?gttrf/?gttrs * `#11377 `__: MAINT: Remove Python 2 code from tools/authors.py * `#11378 `__: ENH (WIP): Python wrapper for ?tbtrs * `#11379 `__: MAINT: Remove six.with_metaclass from benchmarks/cython_special.py * `#11380 `__: BUG: sparse/isolve: bicg and qmr don't treat x0 correctly * `#11382 `__: MAINT: remove error throw in binned_statistic_dd() on non-finite... * `#11383 `__: MAINT: _lib: remove py2 compat shims in getargspec * `#11384 `__: MAINT: Use numpy scalar types directly * `#11385 `__: ENH: special: add spherical Bessel functions to \`cython_special\` * `#11389 `__: MAINT: line.startswith shouldn't be bytes * `#11393 `__: ENH: Speed up truncnorm's ppf()and rvs() methods * `#11394 `__: MAINT: Remove self._size (and self._random_state) from stats... * `#11395 `__: correction in error message (%d->%g format) * `#11396 `__: DOC: revert gh10540, removing mtrand * `#11397 `__: MAINT: differential_evolution accepts np.random.Generator * `#11402 `__: ENH: stats can use np.random.Generator * `#11404 `__: ENH: add docstring of butter() for transfer function syntax problem * `#11405 `__: DOC: Fix "see also" for SmoothBivariateSpline * `#11408 `__: ENH: Add a \`plan\` argument to FFT functions in \`scipy.fft\` * `#11411 `__: MAINT: check minimize duplicate evaluations * `#11418 `__: ENH: Linalg: Python wrapper for ?geqrfp * `#11419 `__: TST: Python 3.7 mac OS gcc multibuild fix * `#11423 `__: ENH: Add tool to lint diffs * `#11425 `__: FIX: _array_newton should preserve complex inputs * `#11426 `__: MAINT: licence for global optimization benchmarks * `#11431 `__: Make median_absolute_deviation scale argument aligned w/iqr * `#11432 `__: Fix error message typo * `#11433 `__: DOC: Remove L from longs * `#11434 `__: MAINT: Python3 improvements to refguide_check.py * `#11435 `__: DOC: Update runtest --parallel help * `#11436 `__: MAINT: Remove checks for sys.version < 3.5 * `#11437 `__: DOC: Fix documentation issue * `#11439 `__: Support path objects (PEP 519) in mmio functions * `#11440 `__: correct bounds pass in run_dualannealing for benchmarks/optimize.py * `#11443 `__: BENCH: optimize_linprog remove ImportError exception * `#11453 `__: BUG: sparse: convert csc/csr indices to int64 as needed * `#11454 `__: DOC: Remove caveat on \`maximum_bipartite_matching\` * `#11455 `__: BUG: Fix _lib._util.getargspec_no_self lack of KEYWORD_ONLY support. * `#11456 `__: Implementation of khatri_rao product * `#11459 `__: BUG: fix augmentation being broken in maximum_bipartite_matching * `#11461 `__: MAINT: minor spelling corrections in comments in SciPy.sparse.linalg.arpack * `#11467 `__: [MRG] Make result data type of KDE evaluation like in the input... * `#11469 `__: Update integrate.quad documentation * `#11472 `__: Fixed result typo * `#11476 `__: DOC: stats: Copy-edit the anderson docstring. * `#11478 `__: ENH: avoid unnecessary array copies in matrix product * `#11481 `__: BUG: Make special.hyperu return nan if any argument is nan * `#11483 `__: BUG: Fixed \`_kpp\` initialization on \`scipy.cluster.vq\`, closing... * `#11485 `__: ENH: Update docstring of class KrylovJacobian to fix #2744 * `#11486 `__: BUG: make special.eval_hermite return nan if second argument... * `#11487 `__: ENH: improve docstring of correlate and correlate2d to fix #1968 * `#11488 `__: FIX: change "func -> fun" of scipy.optimize _root.py to solve... * `#11489 `__: BUG: fixes typo introduced in PR #11253 in stats.mstats.kendalltau() * `#11490 `__: DOC: fix typo in scipy/io/matlab/mio4.py * `#11495 `__: MAINT: refactor slsqp to fix issue in callback function * `#11498 `__: [DOC] mention graph cuts in maximum flow docstring * `#11499 `__: DOC: Improve documentation of scipy.signal.signaltools.wiener * `#11506 `__: DOC: Fix typo in documentation of scipy.stats.morestats * `#11508 `__: ENH: avoid copy on sparse __init__ when dtype is given * `#11509 `__: ENH: avoid unnecessary array copies in matrix product (again) * `#11510 `__: [DOC] An ex. for creating arbitrary size tri-diagonal * `#11511 `__: TST: pin numba for Travis/sparse * `#11513 `__: TST: disable NumPy cache dir ppc64le * `#11514 `__: BUG: make special.eval_genlaguerre return nan if passed nan * `#11517 `__: ENH: improve sparse.lil.tocsr performance * `#11519 `__: Fix fresnel documentation * `#11520 `__: BUG: make special.eval_gegenbauer return nan if passed nan * `#11524 `__: ENH: Cosine Sine Decomposition * `#11526 `__: BUG: fix SLSQP max iteration setting to fix #4921 * `#11527 `__: ENH: improve docstring of weibull_min_gen and weibull_max_gen... * `#11530 `__: MAINT: Removed 3 unused imports, 3 unused assignments from ndimage. * `#11531 `__: DOC: fix typos in bdtr and bdtrc from gh PR 11045 * `#11532 `__: MAINT: Fixed several unused imports and unused assignments from... * `#11533 `__: MAINT: Fixed about 100 unused imports, unused assignment warnings... * `#11534 `__: FIX: Allow non-native byte order inputs to scipy.fft * `#11535 `__: MAINT: Fixed several unused imports in _lib. * `#11536 `__: MAINT: Fixed several unused imports and unused assignments in... * `#11537 `__: MAINT: Removed an unused import in scipy/constants. * `#11538 `__: MAINT: Fixed several unused imports in scipy/fft. * `#11539 `__: MAINT: Fixed several unused imports and unused assignments in... * `#11540 `__: MAINT: Fixed two unused imports in scipy/misc. * `#11541 `__: MAINT: Fixed several unused imports and unused assignments in... * `#11542 `__: MAINT: Fixed an unused import in scipy/odr. * `#11543 `__: MAINT: Fixed several unused imports and unused assignments in... * `#11544 `__: MAINT: Fixed unused imports and unused assignments in scipy/integrate. * `#11545 `__: MAINT: Removed unused imports and fixed unused assignments in... * `#11546 `__: MAINT: Removed unused imports; fixed unused assignments in scipy/signal. * `#11547 `__: MAINT: Removed unused imports; fixed unused assignments in scipy/spatial * `#11548 `__: MAINT: Removed unused imports; fixed unused assignments in scipy.sparse. * `#11549 `__: MAINT: Replace xrange with range * `#11560 `__: MAINT: stats: remove an _argcheck call * `#11573 `__: MAINT: Removed unused imports; fixed unused assignments in scipy/stats. * `#11574 `__: MAINT: Small change to \`optimize.nnls\` error messages. * `#11575 `__: MAINT: Update sytrd/hetrd tests * `#11582 `__: MAINT: fix typo in quadpack.py closes #11448 * `#11585 `__: TST: add openblas_support.py * `#11587 `__: BUG: Differential evolution with LinearConstraint with sparse... * `#11588 `__: MAINT: Fully display problem size in lsmr/lsqr. * `#11589 `__: MAINT: Remove Python 2 workarounds * `#11590 `__: MAINT: Remove Python2 module init * `#11605 `__: Standardization of bounds in _linprog_util.py * `#11608 `__: BUG: fix use of is in DE callback * `#11614 `__: TST, MAINT: TestCtypesQuad skip with pytest * `#11619 `__: ENH: add nan_policy argument and functionality to stats.mstats.winsorize * `#11621 `__: MAINT: Cleanup uses of PY_VERSION_HEX, NPY_PY3K in ndimage * `#11622 `__: MAINT: Cleanup uses of PY_VERSION_HEX, NPY_PY3K in sparse * `#11623 `__: MAINT: Remove unnecessary 'from __future__ import ...' statements * `#11626 `__: MAINT: Cleanup uses of PY_VERSION_HEX * `#11627 `__: ENH: add analytic formula for normal moments * `#11628 `__: MAINT, TST: adjust azure for matplotlib release * `#11631 `__: Revert to old behaviour for constant cost matrices in \`linear_sum_assignment\` * `#11632 `__: MAINT: Define ARRAY_ANYORDER with DEF instead of cdef * `#11639 `__: BUG: interpolate/interp1d: fail gracefully on all-nan inputs * `#11640 `__: MAINT: Fix BLAS3 trmm wrapper for "side" arg * `#11642 `__: TST, MAINT: remove dead code in Travis CI * `#11643 `__: MAINT: fix conversion in binom_test * `#11645 `__: MAINT: Assorted clean up. * `#11646 `__: MAINT: Remove unnecessary 'from __future__ import ...' statements * `#11647 `__: DOC: document return_all arguments * `#11648 `__: Perform geometric slerp in quaternion space * `#11651 `__: DOC: Update paper URL in lambertw documentation * `#11653 `__: PERF: Switch to C++ STL std::nth_element * `#11655 `__: MAINT: Remove Python2 cStringStream * `#11657 `__: ENH: Add wrapper for ?pttrf/?pttrs * `#11664 `__: ENH: Add wrapper for ?gejsv * `#11665 `__: ENH: Add wrapper for ?pteqr * `#11667 `__: BUG: Non-central Fisher distribution (fix nan-values when nc=0) * `#11668 `__: ENH: Add wrapper for ?gtsvx * `#11671 `__: TST, CI: restore Azure temporarily * `#11672 `__: Add warning to medfilt when array size < kernel_size * `#11674 `__: TST: bump test precision for two np.dot related linalg tests. * `#11675 `__: MAINT: pycodestyle clean-up * `#11677 `__: ENH: Add wrapper for ?ptsvx * `#11679 `__: BENCH: cKDTree benchmarks added: balanced/unbalanced tree (related... * `#11680 `__: MAINT: rng_integers allows RandomState.randint or Generator.integers * `#11683 `__: BUG: fix mode='mirror' on length 1 axes * `#11684 `__: BUG: fix scipy.special.voigt_profile * `#11687 `__: MAINT: sparse.linalg: avoid importing from \`np.core\` * `#11688 `__: ENH: mypy: get specific about ignoring missing imports * `#11690 `__: MAINT: mypy: fix errors about incompatible types in lists * `#11692 `__: MAINT: mypy: fix remaining type errors * `#11694 `__: TST, MAINT: bump to OpenBLAS 0.3.9 stable, raise tol for Win... * `#11697 `__: DOC: fix pdf of norminvgauss in scipy.stats * `#11701 `__: MAINT: special: add rudimentary types for \`_ufuncs\` extension... * `#11702 `__: BUG: Fixed a post-merge bug for eigh() * `#11703 `__: Improves docstring with consistent L2-norm * `#11705 `__: DOC: Slerp the SphericalVoronoi docstring * `#11706 `__: ENH: mypy: add \`--mypy\` option to \`runtests.py\` * `#11710 `__: ENH: Modified stats.kstest() to use the exact stats.kstwo.sf()... * `#11715 `__: DOC: add .. versionadded:: to as_matrix/from_matrix in spatial/transf? * `#11716 `__: BENCH: fix benchmark imports for \`\`optimize_linprog.py\`\` * `#11721 `__: MAINT: io: Remove now-unnecessary \`# type: ignore\` * `#11722 `__: MAINT: mypy: remove mpmath from the ratchet * `#11726 `__: Handle constant input for scipy.stats.f_oneway * `#11729 `__: BENCH: optimize: added infeasible benchmarks for linprog * `#11731 `__: fix inaccurate information about Mac OS compiler (#11696) * `#11733 `__: Fix inaccurate docstring example of HalfspaceIntersection * `#11734 `__: Doc: fix inaccurate docstring of SmoothBivariateSpline. * `#11735 `__: Bug: stats: fix wrong shape from median_absolute_deviation for... * `#11736 `__: ENH: add input validations and its tests for FITPACK in fitpack2.py * `#11737 `__: BUG: Prevent crashes due to MKL bug in ?heevr * `#11739 `__: MAINT: special: add type stubs for \`_test_round.pyx\` * `#11740 `__: MAINT: special: remove unused specfun f2py wrappers * `#11741 `__: BUG: fix small tolerances handling for minpack and add a test. * `#11743 `__: Doc: fix docstring of rfft, rfft2, rfftn, irfft, irfft2, irfftn... * `#11744 `__: MAINT: Remove unused py3k.h code * `#11745 `__: DOC: stats: Clean up ncf documentation. * `#11748 `__: MAINT: special: type \`cython_special\` as \`Any\` * `#11750 `__: MAINT: type hints for \`_spherical_voronoi\` * `#11752 `__: DOC: fix docstring of scipy.optimize.least_squares * `#11753 `__: ENH: add input validation for dendrogram and a test. * `#11755 `__: MAINT: Replace uses of tostring with tobytes * `#11757 `__: ENH: improve binned_statistics_2d performance. * `#11759 `__: ENH: optimize: add HiGHS methods to linprog * `#11760 `__: MAINT: Remove FileStream replaced by GenericStream * `#11761 `__: MAINT: Replace npy_3kcompat.h shims * `#11765 `__: TST: Speedup test_pascal which is VERY slow on Azure * `#11766 `__: TST: speed up differential_evolution L8 test * `#11767 `__: Change comment in continuous rv gamma fit function * `#11776 `__: Add domain option for resample. * `#11784 `__: BUG: Fixed calculation of nonzero elements in scipy.sparse.random * `#11786 `__: ENH: stats: add axis keyword argument to scipy.stats.rankdata * `#11789 `__: Doc: fix docstring of scipy.spatial.chebyshev * `#11792 `__: DOC: dev: add guidelines for developing public Cython APIs * `#11794 `__: MAINT: add comments explaining a problem in cython_optimize organization * `#11796 `__: DOC: add a note about precision losing in csgraph.minimum_spanning_tree... * `#11797 `__: ENH: Allow negative \`axis\` in \`interpolate.BSpline\`. Also... * `#11798 `__: Add simplify_cells parameter to scipy.io.loadmat * `#11801 `__: MAINT, DOC: minor changes of ratio-of-uniforms in scipy.stats * `#11802 `__: BUG: fix scipy.odr to handle multidimensional independent and... * `#11803 `__: scipy.stats.trapz: Use analytic formulas for stats and entropy. * `#11808 `__: DOC: add Examples in the scipy.interpolate.interpn docstring. * `#11809 `__: Duplicate entries are added together in csr_matrix constructor * `#11813 `__: MAINT: bump pyflakes to version 2.1.1 * `#11814 `__: BUG: scipy.sparse.csr doctest failing with incorrect output value * `#11817 `__: DOC: add Examples in the scipy.optimize.leastsq docstring * `#11820 `__: ENH: Raise an error on incorrect bounds format in optimize.fmin_l_bfgs_b * `#11822 `__: CI: add github actions for macOS * `#11824 `__: DOC: add Examples in scipy.optimize.line_search docstring (line_search_wolfe2) * `#11830 `__: TST: Always use fork for multiprocessing in fft tests * `#11831 `__: DOC: add Examples and Returns in scipy.misc.central_diff_weights... * `#11832 `__: DOC: stats: Some small corrections to a couple docstrings. * `#11833 `__: BUG: Fix compiler_name when there are paths used in flags * `#11836 `__: MAINT: re-introduce multiprocessing tests on Python3.8 * `#11837 `__: Doc: add Examples in scipy.optimize.fsolve docstring * `#11838 `__: Doc: add Examples in scipy.sparse.linalg.minres docstring * `#11840 `__: BUG: sparse.linalg: fix overflow in expm intermediate computation * `#11842 `__: BLD: fix build with gfortran 10 * `#11843 `__: MAINT: Simplify floats in constants.py * `#11847 `__: DOC: add a tutorial of scipy.optimize.linprog * `#11849 `__: ENH: speed up geninvgauss by using cython * `#11852 `__: CI: remove osx from travisCI * `#11857 `__: BUG: Change parameter fc of gausspulse to float. * `#11861 `__: order = degree + 1 for splines * `#11863 `__: Make g77 ABI wrapper work with gfortran ABI lapack * `#11866 `__: MAINT: add type ignores to sympy and matplotlib imports * `#11867 `__: CI: Add arm64 in travis-ci * `#11869 `__: DOC: signal: Add an example to the lsim2 docstring. * `#11870 `__: DOC: signal: Use impulse instead of impulse2 in the impulse example... * `#11871 `__: ENH: type ufuncs in special as ufuncs instead of Any * `#11872 `__: BUG: avoid recomputing in scipy.optimize.optimize.MemoizeJac * `#11873 `__: DOC: signal: Fix ODE in impulse and impulse2 docstrings. * `#11874 `__: DOC: add Examples of docstring for scipy.interpolate.approximate_taylor_polynomial * `#11878 `__: DOC: fixed a typo under scipy/integrate/quadrature.py * `#11879 `__: BUG: Fix index arrays overflow in sparse.kron * `#11880 `__: DOC: stats: Add Examples for bartlett, fligner, levene. * `#11881 `__: MAINT: normalise numpy-->np in optimize.py * `#11882 `__: DOC: add Examples for scipy.io.readsav docstring. * `#11883 `__: DOC: add Returns and Examples for scipy.ndimage.correlate() docstring * `#11885 `__: BUG: stats: Handle multidimensional arrays in f_oneway, and more. * `#11889 `__: DOC: signal: Unify lsim and lsim2 examples. * `#11896 `__: BUG: stats: Fix handling of size 0 inputs for ttest_rel and ttest_ind. * `#11897 `__: DOC: Remove misleading default values from fit method * `#11898 `__: MAINT: LinearVectorFunction.J is ndarray closes #11886 * `#11902 `__: BUG: linalg: test_heequb failure * `#11904 `__: fix real-to-real transforms for complex inputs and overwrite_x=True * `#11906 `__: DOC: stats: fix error caused by trapz docstring * `#11907 `__: BUG: stats: fixed SEGFAULT from Issue #9710 * `#11912 `__: ENH: Respect matplotlib color palette with hierarchy/dendrogram. * `#11914 `__: DOC: refine doc for spatial.distance.squareform * `#11915 `__: ENH: Ndim linear operator * `#11919 `__: ENH: expose "window_size" parameter in find_peaks_cwt() * `#11920 `__: DOC: explain M, diffev * `#11923 `__: CI: macOS install swig closes #11922 * `#11924 `__: DOC: add Examples for scipy.optimize.bracket() docstring * `#11930 `__: DOC: add Examples and clean up for signal.qspline1d and signal.qspline_eval... * `#11931 `__: DOC: add Examples for sparse.linalg.bicg docstring. * `#11933 `__: DOC: Add original reference for Yao-Liu objective functions * `#11934 `__: DOC, MAINT: mailmap update * `#11935 `__: DOC: make scipy.stats.mode documentation reflect that the function... * `#11936 `__: ENH: special: add type stubs for \`orthogonal.py\` * `#11937 `__: DOC: Add docstring examples to fft2, ifft2, io.savemat * `#11938 `__: MAINT: add helper function for deprecating Cython API functions * `#11942 `__: MAINT: ignore conditional import in _lib/_util * `#11943 `__: MAINT: special: add types for geterr/seterr/errstate * `#11946 `__: MAINT: add py.typed marker * `#11950 `__: TST:MAINT: separated and stabilized heequb tests * `#11952 `__: DOC: update toolchain roadmap for py38, C99, C++11/14 * `#11957 `__: MAINT: Use np.errstate context manager instead of np.seterr. * `#11958 `__: MAINT: interpolate: Remove some trailing spaces. * `#11960 `__: MAINT: Cleanup Python2 compatibility code * `#11961 `__: MAINT: Remove numpy/npy_3kcompat.h from _superluobject.c * `#11962 `__: DOC: Fix type of \`codes\` in docstring of \`_vq._vq()\` * `#11964 `__: MAINT: Cleanup unused IS_PYPY * `#11969 `__: DOC: add Examples and fix docstring for special.airye * `#11970 `__: BUG: sparse: 'diagonal' of sparse matrices fixed to match numpy's... * `#11974 `__: BUG: Reshape oaconvolve output even when no axes are convolved * `#11976 `__: MAINT: add logo for github actions * `#11977 `__: CI: test bleeding edge Python * `#11979 `__: DOC: add Examples for stats.ranksums() docstring. * `#11982 `__: Fix KMeans++ initialisation slowness * `#11983 `__: DOC: add Examples for stats.mstats.argstoarray() docstring. * `#11986 `__: Avoid bugs in ndimage when the output and input arrays overlap... * `#11988 `__: ENH: Override fit method of Laplace distribution with Maximum... * `#11993 `__: TST, CI: Azure Windows path fixups * `#11995 `__: MAINT, CI: remove custom mingw Azure * `#11996 `__: DOC: add Examples and fix pep warning for fft.set_global_backend... * `#11997 `__: MAINT, CI: Azure OpenBLAS simplify * `#11998 `__: BENCH: Run against current HEAD instead of master * `#12001 `__: ENH: stats: Implement _logpdf for the maxwell distribution. * `#12004 `__: DOC: add examples for integrate.quad_vec() and integrate.quad_explain() * `#12005 `__: MAINT: Use helper functions in ?tbtrs tests * `#12007 `__: MAINT: updated LICENSES_bundled for pybind11 and six * `#12008 `__: DOC: roadmap update * `#12009 `__: ENH: optimize: support 64-bit BLAS in lbfgsb * `#12010 `__: ENH: sparse.linalg: support 64-bit BLAS in isolve * `#12012 `__: DOC: add Examples for interpolate.barycentric_interpolate(),... * `#12013 `__: MAINT: remove last uses of numpy.dual * `#12014 `__: CI: print 10 slowest tests * `#12020 `__: MAINT: Removed handling of circular input in SphericalVoronoi * `#12022 `__: DOC : added default value of absolute_sigma to False in scipy.optimize.curve_fit docs * `#12024 `__: DOC: add Examples for io.hb_read() and io.hb_write() * `#12025 `__: MAINT: Remove numpy/npy_3kcompat.h from nd_image * `#12028 `__: Spelling correction * `#12030 `__: ENH: optimize/_trlib: support ILP64 blas/lapack * `#12036 `__: MAINT: Add some generated C files .gitignore * `#12038 `__: MAINT, CI: Travis rackcdn->conda.org * `#12039 `__: MAINT: signal: Lower the resolution of the plots in the chirp... * `#12040 `__: DOC: add Examples for ndimage.spline_filter1d() and spline_filter()... * `#12044 `__: MAINT: combine apt-get update and apt-get install into one RUN * `#12045 `__: TST: Reduce size of test_diagonal_types to speed up tests * `#12046 `__: MAINT: Remove unused npy_3kcompat.h * `#12047 `__: MAINT: Cython 3.0 compat * `#12050 `__: DOC: add download number badges of PyPI and conda-forge in README.rst * `#12052 `__: DOC: add Examples odr.models.polynomial() and fix odr.odr docstring... * `#12056 `__: ENH: Modifies shapiro to return a named tuple * `#12057 `__: Adding my name into THANKS.txt * `#12060 `__: TST: Reduce number of test_diagonal_types configs * `#12062 `__: TST: Change dec.slow to pytest.mark.slow * `#12068 `__: ENH: Modifies jarque_bera to return a named tuple * `#12070 `__: MAINT, CI: appveyor rack->conda.org * `#12072 `__: TST: filter out factorial(float) deprecation warning * `#12078 `__: TST: Skip test on colab with large memory alloc * `#12079 `__: DOC: Remove Python2 reference from stats tutorial * `#12081 `__: DOC: add Examples docstring for optimize.show_options() * `#12084 `__: BUG: interpolate: fix BarycentricInterpolator with integer input... * `#12089 `__: ENH: spatial/qhull: support ILP64 Lapack * `#12090 `__: ENH: integrate: support ILP64 BLAS in odeint/vode/lsoda * `#12091 `__: ENH: integrate: support ILP64 in quadpack * `#12092 `__: BUG: Fix dropping dt in signal.StateSpace * `#12093 `__: MAINT: Rollback python2.6 workaround * `#12094 `__: MAINT: \`openblas_support\` hash checks * `#12095 `__: MAINT: ndimage: change \`shares_memory\` to \`may_share_memory\` * `#12098 `__: Doc: change 4 model instances of odr to be instances of \`Model\`... * `#12101 `__: Removed more unused imports and assignments. * `#12107 `__: ENH: Area calculation for 2D inputs in SphericalVoronoi * `#12108 `__: MAINT: ensure attributes have correct data type in \`SphericalVoronoi\` * `#12109 `__: degree is not order in splines * `#12110 `__: ENH: More helpful/forgiving io.wavfile errors * `#12117 `__: BUG: fix newline * `#12123 `__: [MAINT] Fix error on PyData/Sparse import. * `#12124 `__: TST: Always test matmul now that Python3.5+ is required * `#12126 `__: TST: Cleanup unused matplotlib code. * `#12127 `__: DOC: update docstrings of signal.cspline2d, qspline2d, sepfir2d * `#12130 `__: MAINT: Fixing broken links with linkchecker * `#12135 `__: ENH: linalg: Add the function convolution_matrix. * `#12136 `__: MAINT: Cleanup np.poly1d hack * `#12137 `__: TST, CI: reproduce wheels 32-bit setup * `#12140 `__: TST: stats: add kstwo, ksone to slow tests. * `#12141 `__: Support 64-bit integer size in Fitpack * `#12151 `__: DOC: Correct Rosenbrock function sum * `#12159 `__: BUG: Fix length calculation in upfirdn * `#12160 `__: BUG: Fix M_PI * `#12168 `__: DOC: add an obsolete version checking javascript to doc release... * `#12171 `__: CI, MAINT: Azure OpenBLAS drive flip * `#12172 `__: ENH: Bounds for the Powell minimization method * `#12175 `__: BLD: support more Fortran compilers for ilp64 and macro expansion... * `#12179 `__: BUG: stats: A few distributions didn't accept lists as arguments. * `#12180 `__: MAINT: removed redundant import in SphericalVoronoi tests * `#12181 `__: DOC: for versionwarning don't use $.getScript * `#12182 `__: MAINT: random sampling on the hypersphere in SphericalVoronoi... * `#12194 `__: MAINT: Module and example cleanups for doc build * `#12202 `__: ENH: tool to DL release wheels from Anaconda * `#12210 `__: Remove py.typed marker (at least for the release) * `#12217 `__: BUG: stats: Fix handling of edge cases in median_abs_deviation. * `#12223 `__: BUG: stats: wilcoxon returned p > 1 for certain inputs. * `#12227 `__: BLD: Set macos min version when building rectangular_lsap * `#12229 `__: MAINT: tools/gh_lists.py: fix http header case sensitivity issue * `#12236 `__: DOC: Fix a couple grammatical mistakes in 1.5.0-notes.rst. * `#12276 `__: TST: skip `test_heequb`, it fails intermittently. * `#12285 `__: CI: split travis arm64 run into two * `#12317 `__: BUG: prevent error accumulation in `Rotation` multiplication * `#12318 `__: BUG: sparse: avoid np.prod overflow in check_shape * `#12319 `__: BUG: Make cobyla threadsafe * `#12335 `__: MAINT: Work around Sphinx bug Checksums ========= MD5 ~~~ 6b67c3cdb5fd7ec7f65445ce5432c2d3 scipy-1.5.0-cp36-cp36m-macosx_10_9_x86_64.whl cb1c6b8022891ef2644caf26f6d6d0f2 scipy-1.5.0-cp36-cp36m-manylinux1_i686.whl 28a26064ae38b16c370be9691d0be2de scipy-1.5.0-cp36-cp36m-manylinux1_x86_64.whl 1a8324e7940ab7c405e534823a33872f scipy-1.5.0-cp36-cp36m-win32.whl 241c63762ae6e903b06c2498f5fef5d9 scipy-1.5.0-cp36-cp36m-win_amd64.whl c9642dfdc834dfc73b83fce7a05c6101 scipy-1.5.0-cp37-cp37m-macosx_10_9_x86_64.whl 30ec965fac402610192ff67428848f74 scipy-1.5.0-cp37-cp37m-manylinux1_i686.whl 46c7068c7cf789777ec4423b2ff83f5f scipy-1.5.0-cp37-cp37m-manylinux1_x86_64.whl 21a5d8636489c065ce84fcba238c0c32 scipy-1.5.0-cp37-cp37m-win32.whl cd0429315d501470b5bb732d23fddf9d scipy-1.5.0-cp37-cp37m-win_amd64.whl 99a35969fdd5329436f679e02c23f185 scipy-1.5.0-cp38-cp38-macosx_10_9_x86_64.whl 721abc2147746de50e639832c54d1c0a scipy-1.5.0-cp38-cp38-manylinux1_i686.whl c51a2faadfda7bc56e1492218f9d044c scipy-1.5.0-cp38-cp38-manylinux1_x86_64.whl 8f70224a6b8fb8e55cff52c83df30663 scipy-1.5.0-cp38-cp38-win32.whl 8e0c33036795485d14c6221d00cacb9e scipy-1.5.0-cp38-cp38-win_amd64.whl 4b0fc5a2eae9764c302187af4fad975f scipy-1.5.0.tar.gz 4157e49b7a0ba3c74b9df6df90d43245 scipy-1.5.0.tar.xz a14f9de5ed51eb23c8dfa739ec4f50ff scipy-1.5.0.zip SHA256 ~~~~~~ 8f354e92246de33c44ddfc5fef61bce8c19d5aeeb2130b6a672b15db619453e4 scipy-1.5.0-cp36-cp36m-macosx_10_9_x86_64.whl 244b4a23a8cb6707e19f5579502112954659bb983852b1c381243fe46d9b6818 scipy-1.5.0-cp36-cp36m-manylinux1_i686.whl d266d955c3fd12336c948abb368de230bf8dc20efad428abb908165d9c87f53f scipy-1.5.0-cp36-cp36m-manylinux1_x86_64.whl 11d8bfcea08e971968d07495bdf1de37b3b1bb5ca78e4ddbe8d60791f0456942 scipy-1.5.0-cp36-cp36m-win32.whl eb48915142f2dbd4b84df8ca66e433946df1a13eff36015c2b7843aa39dbc30d scipy-1.5.0-cp36-cp36m-win_amd64.whl ae24f16056c87e7f086a56a7aaf6e65e4626ac70b7e08d7f54e078693abcf778 scipy-1.5.0-cp37-cp37m-macosx_10_9_x86_64.whl 1b23129e9838694c36475b296ac251ae0b0247455352f2bed0b246c30b61c822 scipy-1.5.0-cp37-cp37m-manylinux1_i686.whl 69eb6245ff472db406c3e9b3e13bd0dc6e2ff48e7e758a7bfca296ecdb1ae8b9 scipy-1.5.0-cp37-cp37m-manylinux1_x86_64.whl 38cdb4eafe727b324f295ab69eaa0788a8eefe08d59360968928753ab7f68ba9 scipy-1.5.0-cp37-cp37m-win32.whl f662ad49ef930325161bd5edac39932c3f1b55547eaa0afce08367522f6314df scipy-1.5.0-cp37-cp37m-win_amd64.whl 40969696eb13c2f1b6fc8e99ce597a47627f0167a7feb6086c2ccdfb55835cfc scipy-1.5.0-cp38-cp38-macosx_10_9_x86_64.whl 0f62f3be924a4314cf2384c6f77d3a0e3bf4ada370530a7d0a6d5a61192bec9e scipy-1.5.0-cp38-cp38-manylinux1_i686.whl 4e1a790fdf82a67619a38f017105df4bb66dfcdaea45df793ece27fd534720c2 scipy-1.5.0-cp38-cp38-manylinux1_x86_64.whl 2e99f50d0061c385f8f46c5a99bb07ad013ec2dcf95ccba3be4e081594e7ab19 scipy-1.5.0-cp38-cp38-win32.whl 2aec0f81a29440e0c000222ac0447748a840d328b5698dd900ece4113bca5cde scipy-1.5.0-cp38-cp38-win_amd64.whl 4ff72877d19b295ee7f7727615ea8238f2d59159df0bdd98f91754be4a2767f0 scipy-1.5.0.tar.gz 23baeaa18803d12d1abdff3f5c148b1085c2dc4028c6b8efce652dde2119b41c scipy-1.5.0.tar.xz 92b17f65c2521a48e1853cbc6b1038140f38393ce6293bbdba6e99a7653d8063 scipy-1.5.0.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Mon Jun 22 09:11:44 2020 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Mon, 22 Jun 2020 09:11:44 -0400 Subject: [Numpy-discussion] [SciPy-Dev] ANN: SciPy 1.5.0 In-Reply-To: References: Message-ID: On 6/21/20, Tyler Reddy wrote: > Hi all, > > On behalf of the SciPy development team I'm pleased to announce > the release of SciPy 1.5.0. Thanks everyone, and especially Tyler for managing the release! Warren > > Sources and binary wheels can be found at: > https://pypi.org/project/scipy/ > and at: > https://github.com/scipy/scipy/releases/tag/v1.5.0 > > One of a few ways to install this release with pip: > > pip install scipy==1.5.0 > > ========================== > SciPy 1.5.0 Release Notes > ========================== > > SciPy 1.5.0 is the culmination of 6 months of hard work. It contains > many new features, numerous bug-fixes, improved test coverage and better > documentation. There have been a number of deprecations and API changes > in this release, which are documented below. All users are encouraged to > upgrade to this release, as there are a large number of bug-fixes and > optimizations. Before upgrading, we recommend that users check that > their own code does not use deprecated SciPy functionality (to do so, > run your code with ``python -Wd`` and check for ``DeprecationWarning`` s). > Our development attention will now shift to bug-fix releases on the > 1.5.x branch, and on adding new features on the master branch. > > This release requires Python 3.6+ and NumPy 1.14.5 or greater. > > For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required. > > Highlights of this release > ---------------------------------- > > - wrappers for more than a dozen new ``LAPACK`` routines are now available > in `scipy.linalg.lapack` > - Improved support for leveraging 64-bit integer size from linear algebra > backends > - addition of the probability distribution for two-sided one-sample > Kolmogorov-Smirnov tests > > > New features > ============ > > `scipy.cluster` improvements > --------------------------------------- > Initialization of `scipy.cluster.vq.kmeans2` using ``minit="++"`` had a > quadratic complexity in the number of samples. It has been improved, > resulting > in a much faster initialization with quasi-linear complexity. > > `scipy.cluster.hierarchy.dendrogram` now respects the ``matplotlib`` color > palette > > `scipy.fft` improvements > ---------------------------------- > A new keyword-only argument ``plan`` is added to all FFT functions in this > module. It is reserved for passing in a precomputed plan from libraries > providing a FFT backend (such as ``PyFFTW`` and ``mkl-fft``), and it is > currently not used in SciPy. > > `scipy.io` improvements > --------------------------------- > `scipy.io.wavfile` error messages are more explicit about what's wrong, and > extraneous bytes at the ends of files are ignored instead of raising an > error > when the data has successfully been read. > > `scipy.io.loadmat` gained a ``simplify_cells`` parameter, which if set to > ``True`` simplifies the structure of the return value if the ``.mat`` file > contains cell arrays. > > ``pathlib.Path`` objects are now supported in `scipy.io` Matrix Market I/O > functions > > `scipy.linalg` improvements > -------------------------------------- > `scipy.linalg.eigh` has been improved. Now various ``LAPACK`` drivers can > be > selected at will and also subsets of eigenvalues can be requested via > ``subset_by_value`` keyword. Another keyword ``subset_by_index`` is > introduced. > Keywords ``turbo`` and ``eigvals`` are deprecated. > > Similarly, standard and generalized Hermitian eigenvalue ``LAPACK`` > routines > ``?evx`` are added and existing ones now have full ``_lwork`` > counterparts. > > Wrappers for the following ``LAPACK`` routines have been added to > `scipy.linalg.lapack`: > > - ``?getc2``: computes the LU factorization of a general matrix with > complete > pivoting > - ``?gesc2``: solves a linear system given an LU factorization from > ``?getc2`` > - ``?gejsv``: computes the singular value decomposition of a general > matrix > with higher accuracy calculation of tiny singular values and their > corresponding singular vectors > - ``?geqrfp``: computes the QR factorization of a general matrix with > non-negative elements on the diagonal of R > - ``?gtsvx``: solves a linear system with general tridiagonal matrix > - ``?gttrf``: computes the LU factorization of a tridiagonal matrix > - ``?gttrs``: solves a linear system given an LU factorization from > ``?gttrf`` > - ``?ptsvx``: solves a linear system with symmetric positive definite > tridiagonal matrix > - ``?pttrf``: computes the LU factorization of a symmetric positive > definite > tridiagonal matrix > - ``?pttrs``: solves a linear system given an LU factorization from > ``?pttrf`` > - ``?pteqr``: computes the eigenvectors and eigenvalues of a positive > definite > tridiagonal matrix > - ``?tbtrs``: solves a linear system with a triangular banded matrix > - ``?csd``: computes the Cosine Sine decomposition of an > orthogonal/unitary > matrix > > Generalized QR factorization routines (``?geqrf``) now have full ``_lwork`` > counterparts. > > `scipy.linalg.cossin` Cosine Sine decomposition of unitary matrices has > been > added. > > The function `scipy.linalg.khatri_rao`, which computes the Khatri-Rao > product, > was added. > > The new function `scipy.linalg.convolution_matrix` constructs the Toeplitz > matrix representing one-dimensional convolution. > > `scipy.optimize` improvements > ----------------------------------------- > The finite difference numerical differentiation used in various > ``minimize`` > methods that use gradients has several new features: > > - 2-point, 3-point, or complex step finite differences can be used. > Previously > only a 2-step finite difference was available. > - There is now the possibility to use a relative step size, previously > only an > absolute step size was available. > - If the ``minimize`` method uses bounds the numerical differentiation > strictly > obeys those limits. > - The numerical differentiation machinery now makes use of a simple cache, > which in some cases can reduce the number of function evaluations. > - ``minimize``'s ``method= 'powell'`` now supports simple bound > constraints > > There have been several improvements to `scipy.optimize.linprog`: > > - The ``linprog`` benchmark suite has been expanded considerably. > - ``linprog``'s dense pivot-based redundancy removal routine and sparse > presolve are faster > - When ``scikit-sparse`` is available, solving sparse problems with > ``method='interior-point'`` is faster > > The caching of values when optimizing a function returning both value and > gradient together has been improved, avoiding repeated function evaluations > when using a ``HessianApproximation`` such as ``BFGS``. > > ``differential_evolution`` can now use the modern ``np.random.Generator`` > as > well as the legacy ``np.random.RandomState`` as a seed. > > `scipy.signal` improvements > -------------------------------------- > A new optional argument ``include_nyquist`` is added to ``freqz`` functions > in > this module. It is used for including the last frequency (Nyquist > frequency). > > `scipy.signal.find_peaks_cwt` now accepts a ``window_size`` parameter for > the > size of the window used to calculate the noise floor. > > `scipy.sparse` improvements > ---------------------------------------- > Outer indexing is now faster when using a 2d column vector to select column > indices. > > `scipy.sparse.lil.tocsr` is faster > > Fixed/improved comparisons between pydata sparse arrays and sparse matrices > > BSR format sparse multiplication performance has been improved. > > `scipy.sparse.linalg.LinearOperator` has gained the new ``ndim`` class > attribute > > `scipy.spatial` improvements > --------------------------------------- > `scipy.spatial.geometric_slerp` has been added to enable geometric > spherical linear interpolation on an n-sphere > > `scipy.spatial.SphericalVoronoi` now supports calculation of region areas > in 2D > and 3D cases > > The tree building algorithm used by ``cKDTree`` has improved from quadratic > worst case time complexity to loglinear. Benchmarks are also now available > for > building and querying of balanced/unbalanced kd-trees. > > `scipy.special` improvements > ---------------------------------------- > The following functions now have Cython interfaces in `cython_special`: > > - `scipy.special.erfinv` > - `scipy.special.erfcinv` > - `scipy.special.spherical_jn` > - `scipy.special.spherical_yn` > - `scipy.special.spherical_in` > - `scipy.special.spherical_kn` > > `scipy.special.log_softmax` has been added to calculate the logarithm of > softmax > function. It provides better accuracy than > ``log(scipy.special.softmax(x))`` for > inputs that make softmax saturate. > > `scipy.stats` improvements > ------------------------------------ > The function for generating random samples in `scipy.stats.dlaplace` has > been > improved. The new function is approximately twice as fast with a memory > footprint reduction between 25 % and 60 % (see gh-11069). > > `scipy.stats` functions that accept a seed for reproducible calculations > using > random number generation (e.g. random variates from distributions) can now > use > the modern ``np.random.Generator`` as well as the legacy > ``np.random.RandomState`` as a seed. > > The ``axis`` parameter was added to `scipy.stats.rankdata`. This allows > slices > of an array along the given axis to be ranked independently. > > The ``axis`` parameter was added to `scipy.stats.f_oneway`, allowing it to > compute multiple one-way ANOVA tests for data stored in n-dimensional > arrays. The performance of ``f_oneway`` was also improved for some cases. > > The PDF and CDF methods for ``stats.geninvgauss`` are now significantly > faster > as the numerical integration to calculate the CDF uses a Cython based > ``LowLevelCallable``. > > Moments of the normal distribution (`scipy.stats.norm`) are now calculated > using > analytical formulas instead of numerical integration for greater speed and > accuracy > > Moments and entropy trapezoidal distribution (`scipy.stats.trapz`) are now > calculated using analytical formulas instead of numerical integration for > greater speed and accuracy > > Methods of the truncated normal distribution (`scipy.stats.truncnorm`), > especially ``_rvs``, are significantly faster after a complete rewrite. > > The `fit` method of the Laplace distribution, `scipy.stats.laplace`, now > uses > the analytical formulas for the maximum likelihood estimates of the > parameters. > > Generation of random variates is now thread safe for all SciPy > distributions. > 3rd-party distributions may need to modify the signature of the ``_rvs()`` > method to conform to ``_rvs(self, ..., size=None, random_state=None)``. (A > one-time VisibleDeprecationWarning is emitted when using non-conformant > distributions.) > > The Kolmogorov-Smirnov two-sided test statistic distribution > (`scipy.stats.kstwo`) was added. Calculates the distribution of the K-S > two-sided statistic ``D_n`` for a sample of size n, using a mixture of > exact > and asymptotic algorithms. > > The new function ``median_abs_deviation`` replaces the deprecated > ``median_absolute_deviation``. > > The ``wilcoxon`` function now computes the p-value for Wilcoxon's signed > rank > test using the exact distribution for inputs up to length 25. The function > has > a new ``mode`` parameter to specify how the p-value is to be computed. The > default is ``"auto"``, which uses the exact distribution for inputs up to > length > 25 and the normal approximation for larger inputs. > > Added a new Cython-based implementation to evaluate guassian kernel > estimates, > which should improve the performance of ``gaussian_kde`` > > The ``winsorize`` function now has a ``nan_policy`` argument for refined > handling of ``nan`` input values. > > The ``binned_statistic_dd`` function with ``statistic="std"`` performance > was > improved by ~4x. > > ``scipy.stats.kstest(rvs, cdf,...)`` now handles both one-sample and > two-sample testing. The one-sample variation uses `scipy.stats.ksone` > (or `scipy.stats.kstwo` with back off to `scipy.stats.kstwobign`) to > calculate > the p-value. The two-sample variation, invoked if ``cdf`` is array_like, > uses > an algorithm described by Hodges to compute the probability directly, only > backing off to `scipy.stats.kstwo` in case of overflow. The result in both > cases is more accurate p-values, especially for two-sample testing with > smaller (or quite different) sizes. > > `scipy.stats.maxwell` performance improvements include a 20 % speed up for > `fit()`` and 5 % for ``pdf()`` > > `scipy.stats.shapiro` and `scipy.stats.jarque_bera` now return a named > tuple > for greater consistency with other ``stats`` functions > > Deprecated features > ================ > > `scipy` deprecations > ---------------------------- > > `scipy.special` changes > -------------------------------- > The ``bdtr``, ``bdtrc``, and ``bdtri`` functions are deprecating > non-negative > non-integral ``n`` arguments. > > `scipy.stats` changes > ----------------------------- > The function ``median_absolute_deviation`` is deprecated. Use > ``median_abs_deviation`` instead. > > The use of the string ``"raw"`` with the ``scale`` parameter of ``iqr`` is > deprecated. Use ``scale=1`` instead. > > Backwards incompatible changes > ========================== > > `scipy.interpolate` changes > ------------------------------------- > > `scipy.linalg` changes > ------------------------------ > The output signatures of ``?syevr``, ``?heevr`` have been changed from > ``w, v, info`` to ``w, v, m, isuppz, info`` > > The order of output arguments ``w``, ``v`` of ``{gv, gvd, gvx}`` is > swapped. > > `scipy.signal` changes > ------------------------------- > The output length of `scipy.signal.upfirdn` has been corrected, resulting > outputs may now be shorter for some combinations of up/down ratios and > input > signal and filter lengths. > > `scipy.signal.resample` now supports a ``domain`` keyword argument for > specification of time or frequency domain input. > > Other changes > ============= > Improved support for leveraging 64-bit integer size from linear algebra > backends > in several parts of the SciPy codebase. > > Shims designed to ensure the compatibility of SciPy with Python 2.7 have > now > been removed. > > Many warnings due to unused imports and unused assignments have been > addressed. > > Many usage examples were added to function docstrings, and many input > validations and intuitive exception messages have been added throughout the > codebase. > > Early stage adoption of type annotations in a few parts of the codebase > > > Authors > ======= > > * @endolith > * Hameer Abbasi > * ADmitri + > * Wesley Alves + > * Berkay Antmen + > * Sylwester Arabas + > * Arne K?derle + > * Christoph Baumgarten > * Peter Bell > * Felix Berkenkamp > * Jord?o Bragantini + > * Clemens Brunner + > * Evgeni Burovski > * Matthias Bussonnier + > * CJ Carey > * Derrick Chambers + > * Leander Claes + > * Christian Clauss > * Luigi F. Cruz + > * dankleeman > * Andras Deak > * Milad Sadeghi DM + > * jeremie du boisberranger + > * Stefan Endres > * Malte Esders + > * Leo Fang + > * felixhekhorn + > * Isuru Fernando > * Andrew Fowlie > * Lakshay Garg + > * Gaurav Gijare + > * Ralf Gommers > * Emmanuelle Gouillart + > * Kevin Green + > * Martin Grignard + > * Maja Gwozdz > * Sturla Molden > * gyu-don + > * Matt Haberland > * hakeemo + > * Charles Harris > * Alex Henrie > * Santi Hernandez + > * William Hickman + > * Till Hoffmann + > * Joseph T. Iosue + > * Anany Shrey Jain > * Jakob Jakobson > * Charles Jekel + > * Julien Jerphanion + > * Jiacheng-Liu + > * Christoph Kecht + > * Paul Kienzle + > * Reidar Kind + > * Dmitry E. Kislov + > * Konrad + > * Konrad0 > * Takuya KOUMURA + > * Krzysztof Pi?ro > * Peter Mahler Larsen > * Eric Larson > * Antony Lee > * Gregory Lee + > * Gregory R. Lee > * Chelsea Liu > * Cong Ma + > * Kevin Mader + > * Maja Gw??d? + > * Alex Marvin + > * Matthias K?mmerer > * Nikolay Mayorov > * Mazay0 + > * G. D. McBain > * Nicholas McKibben + > * Sabrina J. Mielke + > * Sebastian J. Mielke + > * Milo? Komar?evi? + > * Shubham Mishra + > * Santiago M. Mola + > * Grzegorz Mrukwa + > * Peyton Murray > * Andrew Nelson > * Nico Schl?mer > * nwjenkins + > * odidev + > * Sambit Panda > * Vikas Pandey + > * Rick Paris + > * Harshal Prakash Patankar + > * Balint Pato + > * Matti Picus > * Ilhan Polat > * poom + > * Siddhesh Poyarekar > * Vladyslav Rachek + > * Bharat Raghunathan > * Manu Rajput + > * Tyler Reddy > * Andrew Reed + > * Lucas Roberts > * Ariel Rokem > * Heshy Roskes > * Matt Ruffalo > * Atsushi Sakai + > * Benjamin Santos + > * Christoph Schock + > * Lisa Schwetlick + > * Chris Simpson + > * Leo Singer > * Kai Striega > * S?ren Fuglede J?rgensen > * Kale-ab Tessera + > * Seth Troisi + > * Robert Uhl + > * Paul van Mulbregt > * Vasiliy + > * Isaac Virshup + > * Pauli Virtanen > * Shakthi Visagan + > * Jan Vleeshouwers + > * Sam Wallan + > * Lijun Wang + > * Warren Weckesser > * Richard Weiss + > * wenhui-prudencemed + > * Eric Wieser > * Josh Wilson > * James Wright + > * Ruslan Yevdokymov + > * Ziyao Zhang + > > A total of 129 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.0 > ------------------------------- > > * `#1455 `__: ellipord does > returns bogus values if gstop or gpass are negative... > * `#1968 `__: correlate2d's > output does not agree with correlate's output in... > * `#2744 `__: BUG: optimize: > '\*\*kw' argument of 'newton_krylov' is not documented > * `#4755 `__: TypeError: data > type " * `#4921 `__: scipy.optimize > maxiter option not working as expected > * `#5144 `__: RuntimeWarning on > csgraph.shortest_path when edge lengths are... > * `#5309 `__: Documentation of > 'hybr' and 'lm' inconsistent in optimize.root > * `#6026 `__: Replace > approx_grad with _numdiff.approx_derivative in scipy.optimize > * `#6502 `__: Computing > Eigenvalues in an Interval with LAPACK > * `#7058 `__: Errors in > special.bdtri and special.bdtr for non-integer k values > * `#7700 `__: SuperLU does not > respect perm_c="NATURAL" > * `#7895 `__: Improvements to > io.loadmat > * `#8205 `__: ValueError in > scipy.linalg.eigvalsh for large matrix > * `#8278 `__: Memory limit for > scipy.sparse.linalg.spsolve with scikit-umfpack > * `#8327 `__: > scipy.stats.mstats.winsorize NaN handling > * `#8341 `__: > scipy.stats.ks_2samp for masked and unmasked data give different... > * `#8748 `__: > scipy.stats.kstest for same distribution: p-values nonuniform > * `#9042 `__: optimize: > Incorrect statement about \`jac\` in the \`minimize\`... > * `#9197 `__: problem with > scipy.signal.butter with 1000+ points array > * `#9212 `__: EIGH very very > slow --> suggesting an easy fix > * `#9553 `__: ndimage routines > behave badly when output has memory overlap... > * `#9632 `__: > ndimage.maximum_filter undocumented behaviour using footprint... > * `#9658 `__: > `scipy.optimize.minimize(method='COBYLA')` not threadsafe > * `#9710 `__: > stats.weightedtau([1], [1.0]) SEGFAULTs > * `#9797 `__: Master Tracker > for some Kolmogorov-Smirnov test Issues > * `#9844 `__: > scipy.signal.upfirdn gives different length matrix versus MATLAB... > * `#9872 `__: > scipy.signal.convolve is slower when vectorized > * `#9913 `__: BUG: No dt in > StateSpace operations > * `#10014 `__: Distribution > names \`weibull_min\`and \`weibull_max\` should... > * `#10159 `__: BUG: stats: > chisquare returns incorrect results for arrays of... > * `#10302 `__: scipy.fft: Add > a \`plan\` argument > * `#10332 `__: 'Incomplete wav > chunk' inconsistent/reason unknown > * `#10441 `__: Remove uses of > \`numpy.dual\`? > * `#10558 `__: Document > implicit sum in csr_matrix() constructor > * `#10788 `__: LU with full > pivoting > * `#10841 `__: Unexpected > behavior in linalg.blas.dtrmm wrapper > * `#10919 `__: > optimize._lbfgsb setulb() function violates parameter bounds > * `#10963 `__: kstest, > ks_2samp: confusing \`mode\` argument descriptions > * `#11022 `__: Unexpected > Result in factorial function with NaN input > * `#11028 `__: Documentation > error in optimize.minimize > * `#11058 `__: Adding > logsoftmax function > * `#11076 `__: ValueError: > Unknown wave file format > * `#11090 `__: Misconception > of the median absolute deviation in stats? > * `#11095 `__: BUG: > find_peaks_cwt test failures in 32-bit Linux wheels > * `#11107 `__: scipy.io.mmread > generated an error "TypeError: startswith first... > * `#11123 `__: Add wrapper for > ?gttrf/?gttrs > * `#11128 `__: OverflowError > in resample_poly (upfirdn) > * `#11132 `__: Possible bug: > rv_discret.ppf for percentiles 0 and 100 and loc... > * `#11163 `__: Comparisons > between scipy spmatrix and can sparse.SparseArray... > * `#11168 `__: Generalized > Pareto variance inaccurate for concentrations near... > * `#11169 `__: Add wrapper for > ?geqrfp > * `#11184 `__: 2-sided > Kolmogorov Smirnov returns p-value of 1 > * `#11185 `__: The .roots() or > solve() function of scipy.interpolate.CubicHermiteSpline... > * `#11190 `__: Add wrapper for > ?tbtrs > * `#11200 `__: Can no longer > slice csr_matrix in 1.3.0 > * `#11207 `__: > _minimize_scalar_bounded: reference before assignment > * `#11216 `__: linprog: > interior-point: Cholmod reordering can be reused > * `#11223 `__: Add wrappers > for ?pttrf, ?pttrs > * `#11224 `__: Add wrapperfor > ?pteqr > * `#11235 `__: MAINT: > Missleading Error Message for IIR Filter > * `#11244 `__: Missing > reference in \`scipy.optimize.line_search\` > * `#11262 `__: Hermitian > Eigenvalue Problem eigh() API and wrapper change proposal > * `#11266 `__: Sparse matrix > constructor data type detection changes on Numpy... > * `#11270 `__: CI failing: > Travis CI Py36 refguide and Linux_Python_36_32bit_full... > * `#11279 `__: linalg.eigh > checks whole array for finite values > * `#11295 `__: CI: azure does > not auto-cancel old jobs on pushes > * `#11299 `__: > stats.truncnorm.rvs 100x slower in v1.4.x than v1.3.3 > * `#11315 `__: BUG: special: > rgamma on negative integers smaller -34 > * `#11319 `__: Missing > \`int64_t\` declaration in rectangular_lsap.cpp > * `#11323 `__: Compilation > failure due to missing symbol pthread_atfork > * `#11332 `__: BUG: > directed_hausdorff distance on sets u and v when u is a... > * `#11350 `__: Khatri-Rao > product > * `#11354 `__: ENH: Add > wrapper for ?gejsv > * `#11361 `__: Dropped NaN in > eval_genlaguerre function > * `#11363 `__: Dropped NaN in > hyperu function > * `#11365 `__: > scipy.stats.binned_statistic regressed in v1.4.0 > * `#11369 `__: Dropped NaN in > eval_hermite > * `#11370 `__: Dropped NaN in > eval_gegenbauer > * `#11373 `__: Add wrapper for > ?gtsvx > * `#11374 `__: Add wrapper for > ?ptsvx > * `#11391 `__: > csgraph.minimum_spanning_tree loses precision > * `#11398 `__: Update stats to > cope with \`np.random.Generator\` machinery > * `#11412 `__: Array copying > causes unwanted type casting from complex to float... > * `#11415 `__: Where is the > Wiener Filter derived from? > * `#11416 `__: > _lib._util.getargspec_no_self is missing KEYWORD_ONLY support > * `#11428 `__: Documentation > on SHGO inequality constraints appears contradictory > * `#11429 `__: Add LAPACK's > ZUNCSD cosine sine decomposition > * `#11438 `__: > run_dualannealing passes bounds incorrectly in benchmarks/optimize.py > * `#11441 `__: Can't run > optimize benchmarks > * `#11442 `__: Chebyshev > weights > * `#11448 `__: Wrongly typed > comparison in integrate.quad > * `#11458 `__: BUG: > maximum_bipartite_matching produces infeasible solution > * `#11460 `__: CI failing: 2 > Travis CI tests fail with numpy build or version... > * `#11462 `__: Bug on "++" > initialization on "kmeans2" > * `#11464 `__: Shouldn't data > type of KDE evaluation should be like in the input... > * `#11468 `__: performance of > binned_statistics_2d 100x slowdown from 1.3.2... > * `#11484 `__: Callback > function doesn't give the same value as the one being... > * `#11492 `__: Confusing > dendrogram labelling > * `#11493 `__: > scipy.optimize.least_squares fails if the return array of the... > * `#11494 `__: Error > performing kronecker product between large sparse vectors > * `#11503 `__: medfilt > produces 0 on input of length 1 > * `#11529 `__: Pyflakes > generates almost 700 warnings. > * `#11566 `__: > irfft/irfft2/irfftn docs are slightly confusing re: input type. > * `#11572 `__: least_squares: > too small tolerances not catched with method='lm' > * `#11581 `__: DOC: > scipy.interpolate.RectSphereBivariateSpline > * `#11586 `__: Differential > evolution breaks with LinearConstraints with sparse... > * `#11595 `__: > scipy.spatial.cKDTree construction slow for some datasets > * `#11598 `__: output of > special.voigt_profile when sigma=0 > * `#11601 `__: linalg tests > failing in runtests.py > * `#11602 `__: > scipy.optimize.linear_sum_assignment returns reverse diagonal... > * `#11610 `__: Analytic > formula for normal moments > * `#11611 `__: Build failure > with gfortran 10 > * `#11613 `__: TST, MAINT: > test_quadpack TestCtypesQuad wasn't fully migrated... > * `#11630 `__: > SmoothBivariateSpline bbox parameter > * `#11635 `__: typo in > docstring of scipy.stats.norminvgauss > * `#11637 `__: BUG: core dumps > when calling scipy.interpolate.interp1d with... > * `#11638 `__: better > documentation for 'return_all' option in minimize(Nelder... > * `#11652 `__: TST, MAINT: CI > failures for pre-release NumPy wheels > * `#11659 `__: > optimize.fmin_l_bfgs_b needs bound check and appropiate error... > * `#11660 `__: BUG/ENH: > distribution.ncf with nc=0 returns nan > * `#11661 `__: > scipy.ndimage.convolve1d and correlate1d don't behave properly... > * `#11669 `__: p-value varies > with the order of the data > * `#11676 `__: documentation > of scipy.spatial.HalfspaceIntersection: wrong method... > * `#11685 `__: Rotation cannot > be expressed as matrix > * `#11686 `__: MAINT: mypy > imports of Cython "modules" > * `#11693 `__: > TestDifferentialEvolutionSolver::test_L4 failing in CI > * `#11696 `__: DOC: incorrect > compiler information for macOS in docs > * `#11709 `__: eigh() tests > fail to pass, crash Python with seemingly ramdom... > * `#11763 `__: Small error in > gamma continuous rv fit comments > * `#11769 `__: truncnorm.rvs > Weird Behaviors > * `#11770 `__: crash in > TestEigh::test_value_subsets > * `#11795 `__: trapz > distribution mean computed using single precision > * `#11800 `__: Segmentation > fault in scipy.odr for multidimensional independent... > * `#11811 `__: pyflakes > silently failing on travis-ci > * `#11826 `__: Error with > _fblas > * `#11827 `__: > \`fft.tests.test_numpy.test_multiprocess\` hangs on Python3.8... > * `#11835 `__: tests with > \`multiprocessing\` hang on Python 3.8 on macOS > * `#11839 `__: linalg.expm > returns nans with RuntimeWarning: overflow encountered... > * `#11856 `__: Documentation > of fit methods for \`weibull_min\` and \`exponweib\`... > * `#11868 `__: Function always > evaluated twice when using HessianUpdateStrategy... > * `#11875 `__: Typo in the > docstring of simps() > * `#11877 `__: kmeans2 '++' > method is orders of magnitude slower than sklearn.cluster.KMeans() > * `#11884 `__: The upper code > lines are dead code > * `#11886 `__: Array shape > mismatch in scipy.optimize > * `#11892 `__: BUG: stats: > Incorrect handling of edges cases by ttest_rel and... > * `#11908 `__: LinearOperator > should have ndim attribute > * `#11910 `__: Documentation > missing for what M is in init argument > * `#11922 `__: macOS actions > CI has started failing in last couple of days. > * `#11928 `__: DOC: signal: > Wrong description for sepfir2d, cspline2d, qspline2d > * `#11944 `__: curve_fit > documentation unclear on default value of absolute_sigma > * `#11945 `__: Add a > (potentially temporary) py.typed file? > * `#11949 `__: ValueError 'k > exceeds matrix dimensions' for sparse.diagonal()... > * `#11951 `__: BUG: asv > benchmark failed because of cython version > * `#11967 `__: BLD: Azure > windows runs complain about drives > * `#11973 `__: > oaconvolve(a,b,'same') differs in shape from convolve(a,b,'same')... > * `#12002 `__: pybind11 > license > * `#12003 `__: MAINT: circular > SphericalVoronoi input > * `#12015 `__: Reordering of > CSC matrix breaks when you go above int32 limits > * `#12031 `__: Documentation > Rendering Issues Visible in CircleCI Artifacts > * `#12037 `__: MAINT, CI: new > Cython 3.0a4 issue > * `#12087 `__: DOC: some odr > models are missing docs > * `#12119 `__: > signal.fftconvolve no longer convolves types f8 and numpy.float64 > * `#12149 `__: Documentation > of Rosenbrock function > * `#12173 `__: Large memory > usage when indexing sparse matrices with \`np.ix_\` > * `#12178 `__: BUG: stats: > Some discrete distributions don't accept lists of... > * `#12220 `__: BUG, REL: > gh_lists.py compromised scraping > * `#12239 `__: BUG: median > absolute deviation handling of nan > * `#12301 `__: integer > overflow in scipy.sparse.sputils.check_shape when matrix size > 2^32 > * `#12314 `__: > scipy.spatial.transform.Rotation multiplication does not normalize > quaternion > > Pull requests for 1.5.0 > ------------------------------ > > * `#6510 `__: Add Eigenvalue > Range Functionality for Symmetric Eigenvalue Problems > * `#9525 `__: BUG: SuperLU > 'NATURAL' order applies a column permutation > * `#9634 `__: Add the number of > Jacobian evaluations to the output of L-BFGS-B. > * `#9719 `__: ENH: Added kstwo > probability distribution for two-sided one-sample... > * `#9783 `__: WIP: optimize: > added (dense) interpolative decomposition redundancy... > * `#10053 `__: Adding docstring > to weibull_min and weibull_max based on issue... > * `#10136 `__: DEP: Add warning > to linprog_verbose_callback > * `#10380 `__: ENH: add > geometric_slerp > * `#10602 `__: MAINT: optimize: > refactor common linprog arguments into namedtuple > * `#10648 `__: Bounds for the > Powell minimization method > * `#10673 `__: ENH: > approx_fprime --> approx_derivative > * `#10759 `__: ENH: calculation > of region areas in spatial.SphericalVoronoi > * `#10762 `__: BENCH: optimize: > more comprehensive linprog benchmarking > * `#10796 `__: ENH exact > p-values of wilcoxon test in scipy.stats > * `#10797 `__: ENH: linalg: LU > with full pivoting (wrappers for ?getc2/?gesc2) > * `#10824 `__: ENH: Fast > gaussian kernel estimator > * `#10942 `__: BUG: prevent > bound violation in L-BFGS-B optimize method > * `#11003 `__: ENH: add > scipy.linalg.convolution_matrix > * `#11023 `__: improving error > message for cubic-interpolate with duplicates > * `#11045 `__: MAINT: make > bdt{r,rc,ri}() functions accept double n,k args +... > * `#11063 `__: Fix documentation > error in optimize.minimize > * `#11069 `__: ENH: > stats.dlaplace.rvs improvements > * `#11071 `__: DOC: Added > examples to maximum_position in ndimage > * `#11075 `__: DOC: Update > stylistic consistency in multiple files > * `#11097 `__: BUG: stats: > fixing chisquare to return correct results for arrays... > * `#11110 `__: ENH: special: > Cythonise erfinv, erfcinv > * `#11112 `__: BUG: special: > Return NaN outside the domain of \`eval_hermite\` > * `#11114 `__: BUG: special: fix > \`hyp1f1\` for nonnegative integral \`a\` and... > * `#11115 `__: DOC: special: add > docstrings for \`kei\`, \`ker\`, \`keip\`,... > * `#11130 `__: ENH: support for > circular input > * `#11136 `__: BUG: expm > handling of empty input > * `#11138 `__: DOC: stylistic > consistency, punctuation, etc. > * `#11139 `__: MAINT: cluster: > use cython_blas, remove handwritten BLAS wrappers > * `#11146 `__: DOC: update docs > on bp parameter for detrend > * `#11151 `__: DOC: special: add > docstrings for \`bei\`, \`ber\`, \`beip\`,... > * `#11156 `__: ENH: add input > validation for ellipord. > * `#11157 `__: DOC: stylistic > revision, punctuation, consistency > * `#11160 `__: ignore warning on > 0 \* inf in basin hopping > * `#11162 `__: DOC: minor > stylistic revision, undo changes > * `#11164 `__: ENH/ BUG: Pydata > sparse equality > * `#11171 `__: Fix dtype > validation of "seuclidean" metric V parameter > * `#11177 `__: BUG: stats: > Improve genpareto stats calculations. > * `#11180 `__: MAINT: stats: > Some clean up in test_distributions.py. > * `#11187 `__: ENH: add > functionality log_softmax to SciPy.special. > * `#11188 `__: MAINT: add rvs > method to argus in scipy.stats > * `#11196 `__: DOC: special: add > to docstrings of Kelvin zeros functions > * `#11202 `__: BUG: fix edge > counting in shortest_path > * `#11218 `__: BUG: > scipy/interpolate: fix PPoly/Cubic\*Spline roots() extrapolation... > * `#11225 `__: Add a warning to > constant input for spearmanr() function > * `#11226 `__: Speed up of > interior-point method for cholesky solver > * `#11229 `__: BUG: Explicit > dtype specification in _upfirdn.py > * `#11230 `__: Additional > citation for optimize tutorial > * `#11231 `__: Adds SLSQP test > for duplicate f-evals (#10738) > * `#11236 `__: MAINT: Improved > error message for Wn range in iirfilter. > * `#11245 `__: ENH: optimize: > dense redundancy removal routine optimizations > * `#11247 `__: MAINT: Remove > _lib/_numpy_compat.py > * `#11248 `__: BUG: > rv_discrete.ppf() to handle loc > * `#11251 `__: DOC: add > reference for linesearch zoom algorithm > * `#11253 `__: BUG: fix > kendalltau issue where p-value becomes >1 > * `#11254 `__: MAINT: make > special.factorial handle nan correctly > * `#11256 `__: DOC: Updated > documentation for scipy.linalg.qr > * `#11265 `__: Fix: Can no > longer slice csr_matrix in 1.3.0 > * `#11267 `__: BUG: Rework the > scaling in the ks_2samp two-sided exact test. > * `#11268 `__: DOC: example of > NonLinearConstraint > * `#11269 `__: Fix: Sparse > matrix constructor data type detection changes on... > * `#11276 `__: BLD: update > minimum Python, NumPy, Cython, Pybind11 versions > * `#11277 `__: MAINT: Cleanup > conditionals for unsupported numpy verisons > * `#11278 `__: MAINT: Cleanup > stats.iqr workarounds for unsupported NumPy versions > * `#11282 `__: TST/CI: improve > traceback formatting for test failures > * `#11284 `__: fix docs & > behavior for mode sequences in ndimage filters > * `#11285 `__: DOC: special: > complete the docstrings of Chi-square functions > * `#11286 `__: BUG: make > loadmat/savemat file opening close resources correctly > * `#11287 `__: CI: skip Azure > and TravisCI builds on merges and direct pushes... > * `#11288 `__: DOC: Fix import > in scipy.io.wavfile.read sample code > * `#11289 `__: BUG: Use context > manager for open > * `#11290 `__: MAINT: Remove > _lib._version in favour of _lib._pep440 > * `#11292 `__: DOC: special: add > docstrings for various convenience functions > * `#11293 `__: DOC: special: fix > typo in \`chdtri\` docstring > * `#11296 `__: DOC: special: add > to docstrings of Bessel zeros and derivatives > * `#11297 `__: DOC: special: add > parameters/returns sections for Bessel integrals > * `#11300 `__: MAINT: Update > vendored uarray version > * `#11301 `__: CI: azure > conditions should require succeeded() > * `#11302 `__: ENH: build > infrastructure for ILP64 BLAS + ARPACK conversion > * `#11303 `__: DOC: special: fix > typo in \`besselpoly\` docstring > * `#11304 `__: ENH: MAINT: > Rewrite of eigh() and relevant wrappers > * `#11306 `__: TST: skip > test_aligned_mem linalg test that is crashing on ppcle64 > * `#11307 `__: MAINT: Fix typo > 'solutuion' -> 'solution' > * `#11308 `__: ENH: do not > create 1d array out of a scalar > * `#11310 `__: MAINT: clean up > object array creation, scalar/1d confusion > * `#11311 `__: DOC: Specify > custom callable option for metric in cluster.hierarchy.fclusterdata > * `#11316 `__: BUG: special: fix > behavior for \`rgamma\` zeros > * `#11317 `__: BUG: fix > floating-point literal comparisons under C99 > * `#11318 `__: TST: optimize: > mark two linprog tests for skipping > * `#11320 `__: BUG: Include > \`int64_t\` declaration to \`rectangular_lsap.cpp\` > * `#11330 `__: MAINT: Update > vendored pypocketfft version > * `#11333 `__: BUG: > directed_hausdorff subset fix > * `#11335 `__: [ENH] sparse: > Loosen check for sparse outer indexing fast path > * `#11337 `__: Undefined name > 'e' in pavement.py > * `#11338 `__: scipyoptdoc.py: > Remove unused variable 'sixu' > * `#11340 `__: xrange() was > removed in Python 3 in favor of range() > * `#11342 `__: range() was > removed in Py3 in _binned_statistic.py > * `#11343 `__: BUG: constants: > fix 'exact' values table > * `#11347 `__: ENH: add input > validation function and apply it to needed functions > * `#11348 `__: MAINT: remove > six.string_types usages > * `#11349 `__: MAINT: minor doc > fix _minimize_trustregion_constr > * `#11353 `__: MAINT: py3 remove > various six usages > * `#11358 `__: ENH: optimize: > Use CSR format instead of LIL for speed > * `#11362 `__: MAINT: > sys.version_info >= 3.5 > * `#11364 `__: ENH: cache square > of sums for f_oneway > * `#11368 `__: ENH: add optional > argument, "include_nyquist", for freqz() > * `#11372 `__: BENCH: optimize: > added linprog presolve benchmarks > * `#11376 `__: ENH: Add wrapper > for ?gttrf/?gttrs > * `#11377 `__: MAINT: Remove > Python 2 code from tools/authors.py > * `#11378 `__: ENH (WIP): Python > wrapper for ?tbtrs > * `#11379 `__: MAINT: Remove > six.with_metaclass from benchmarks/cython_special.py > * `#11380 `__: BUG: > sparse/isolve: bicg and qmr don't treat x0 correctly > * `#11382 `__: MAINT: remove > error throw in binned_statistic_dd() on non-finite... > * `#11383 `__: MAINT: _lib: > remove py2 compat shims in getargspec > * `#11384 `__: MAINT: Use numpy > scalar types directly > * `#11385 `__: ENH: special: add > spherical Bessel functions to \`cython_special\` > * `#11389 `__: MAINT: > line.startswith shouldn't be bytes > * `#11393 `__: ENH: Speed up > truncnorm's ppf()and rvs() methods > * `#11394 `__: MAINT: Remove > self._size (and self._random_state) from stats... > * `#11395 `__: correction in > error message (%d->%g format) > * `#11396 `__: DOC: revert > gh10540, removing mtrand > * `#11397 `__: MAINT: > differential_evolution accepts np.random.Generator > * `#11402 `__: ENH: stats can > use np.random.Generator > * `#11404 `__: ENH: add > docstring of butter() for transfer function syntax problem > * `#11405 `__: DOC: Fix "see > also" for SmoothBivariateSpline > * `#11408 `__: ENH: Add a > \`plan\` argument to FFT functions in \`scipy.fft\` > * `#11411 `__: MAINT: check > minimize duplicate evaluations > * `#11418 `__: ENH: Linalg: > Python wrapper for ?geqrfp > * `#11419 `__: TST: Python 3.7 > mac OS gcc multibuild fix > * `#11423 `__: ENH: Add tool to > lint diffs > * `#11425 `__: FIX: > _array_newton should preserve complex inputs > * `#11426 `__: MAINT: licence > for global optimization benchmarks > * `#11431 `__: Make > median_absolute_deviation scale argument aligned w/iqr > * `#11432 `__: Fix error message > typo > * `#11433 `__: DOC: Remove L > from longs > * `#11434 `__: MAINT: Python3 > improvements to refguide_check.py > * `#11435 `__: DOC: Update > runtest --parallel help > * `#11436 `__: MAINT: Remove > checks for sys.version < 3.5 > * `#11437 `__: DOC: Fix > documentation issue > * `#11439 `__: Support path > objects (PEP 519) in mmio functions > * `#11440 `__: correct bounds > pass in run_dualannealing for benchmarks/optimize.py > * `#11443 `__: BENCH: > optimize_linprog remove ImportError exception > * `#11453 `__: BUG: sparse: > convert csc/csr indices to int64 as needed > * `#11454 `__: DOC: Remove > caveat on \`maximum_bipartite_matching\` > * `#11455 `__: BUG: Fix > _lib._util.getargspec_no_self lack of KEYWORD_ONLY support. > * `#11456 `__: Implementation of > khatri_rao product > * `#11459 `__: BUG: fix > augmentation being broken in maximum_bipartite_matching > * `#11461 `__: MAINT: minor > spelling corrections in comments in SciPy.sparse.linalg.arpack > * `#11467 `__: [MRG] Make result > data type of KDE evaluation like in the input... > * `#11469 `__: Update > integrate.quad documentation > * `#11472 `__: Fixed result typo > * `#11476 `__: DOC: stats: > Copy-edit the anderson docstring. > * `#11478 `__: ENH: avoid > unnecessary array copies in matrix product > * `#11481 `__: BUG: Make > special.hyperu return nan if any argument is nan > * `#11483 `__: BUG: Fixed > \`_kpp\` initialization on \`scipy.cluster.vq\`, closing... > * `#11485 `__: ENH: Update > docstring of class KrylovJacobian to fix #2744 > * `#11486 `__: BUG: make > special.eval_hermite return nan if second argument... > * `#11487 `__: ENH: improve > docstring of correlate and correlate2d to fix #1968 > * `#11488 `__: FIX: change "func > -> fun" of scipy.optimize _root.py to solve... > * `#11489 `__: BUG: fixes typo > introduced in PR #11253 in stats.mstats.kendalltau() > * `#11490 `__: DOC: fix typo in > scipy/io/matlab/mio4.py > * `#11495 `__: MAINT: refactor > slsqp to fix issue in callback function > * `#11498 `__: [DOC] mention > graph cuts in maximum flow docstring > * `#11499 `__: DOC: Improve > documentation of scipy.signal.signaltools.wiener > * `#11506 `__: DOC: Fix typo in > documentation of scipy.stats.morestats > * `#11508 `__: ENH: avoid copy > on sparse __init__ when dtype is given > * `#11509 `__: ENH: avoid > unnecessary array copies in matrix product (again) > * `#11510 `__: [DOC] An ex. for > creating arbitrary size tri-diagonal > * `#11511 `__: TST: pin numba > for Travis/sparse > * `#11513 `__: TST: disable > NumPy cache dir ppc64le > * `#11514 `__: BUG: make > special.eval_genlaguerre return nan if passed nan > * `#11517 `__: ENH: improve > sparse.lil.tocsr performance > * `#11519 `__: Fix fresnel > documentation > * `#11520 `__: BUG: make > special.eval_gegenbauer return nan if passed nan > * `#11524 `__: ENH: Cosine Sine > Decomposition > * `#11526 `__: BUG: fix SLSQP > max iteration setting to fix #4921 > * `#11527 `__: ENH: improve > docstring of weibull_min_gen and weibull_max_gen... > * `#11530 `__: MAINT: Removed 3 > unused imports, 3 unused assignments from ndimage. > * `#11531 `__: DOC: fix typos in > bdtr and bdtrc from gh PR 11045 > * `#11532 `__: MAINT: Fixed > several unused imports and unused assignments from... > * `#11533 `__: MAINT: Fixed > about 100 unused imports, unused assignment warnings... > * `#11534 `__: FIX: Allow > non-native byte order inputs to scipy.fft > * `#11535 `__: MAINT: Fixed > several unused imports in _lib. > * `#11536 `__: MAINT: Fixed > several unused imports and unused assignments in... > * `#11537 `__: MAINT: Removed an > unused import in scipy/constants. > * `#11538 `__: MAINT: Fixed > several unused imports in scipy/fft. > * `#11539 `__: MAINT: Fixed > several unused imports and unused assignments in... > * `#11540 `__: MAINT: Fixed two > unused imports in scipy/misc. > * `#11541 `__: MAINT: Fixed > several unused imports and unused assignments in... > * `#11542 `__: MAINT: Fixed an > unused import in scipy/odr. > * `#11543 `__: MAINT: Fixed > several unused imports and unused assignments in... > * `#11544 `__: MAINT: Fixed > unused imports and unused assignments in scipy/integrate. > * `#11545 `__: MAINT: Removed > unused imports and fixed unused assignments in... > * `#11546 `__: MAINT: Removed > unused imports; fixed unused assignments in scipy/signal. > * `#11547 `__: MAINT: Removed > unused imports; fixed unused assignments in scipy/spatial > * `#11548 `__: MAINT: Removed > unused imports; fixed unused assignments in scipy.sparse. > * `#11549 `__: MAINT: Replace > xrange with range > * `#11560 `__: MAINT: stats: > remove an _argcheck call > * `#11573 `__: MAINT: Removed > unused imports; fixed unused assignments in scipy/stats. > * `#11574 `__: MAINT: Small > change to \`optimize.nnls\` error messages. > * `#11575 `__: MAINT: Update > sytrd/hetrd tests > * `#11582 `__: MAINT: fix typo > in quadpack.py closes #11448 > * `#11585 `__: TST: add > openblas_support.py > * `#11587 `__: BUG: Differential > evolution with LinearConstraint with sparse... > * `#11588 `__: MAINT: Fully > display problem size in lsmr/lsqr. > * `#11589 `__: MAINT: Remove > Python 2 workarounds > * `#11590 `__: MAINT: Remove > Python2 module init > * `#11605 `__: Standardization > of bounds in _linprog_util.py > * `#11608 `__: BUG: fix use of > is in DE callback > * `#11614 `__: TST, MAINT: > TestCtypesQuad skip with pytest > * `#11619 `__: ENH: add > nan_policy argument and functionality to stats.mstats.winsorize > * `#11621 `__: MAINT: Cleanup > uses of PY_VERSION_HEX, NPY_PY3K in ndimage > * `#11622 `__: MAINT: Cleanup > uses of PY_VERSION_HEX, NPY_PY3K in sparse > * `#11623 `__: MAINT: Remove > unnecessary 'from __future__ import ...' statements > * `#11626 `__: MAINT: Cleanup > uses of PY_VERSION_HEX > * `#11627 `__: ENH: add analytic > formula for normal moments > * `#11628 `__: MAINT, TST: > adjust azure for matplotlib release > * `#11631 `__: Revert to old > behaviour for constant cost matrices in \`linear_sum_assignment\` > * `#11632 `__: MAINT: Define > ARRAY_ANYORDER with DEF instead of cdef > * `#11639 `__: BUG: > interpolate/interp1d: fail gracefully on all-nan inputs > * `#11640 `__: MAINT: Fix BLAS3 > trmm wrapper for "side" arg > * `#11642 `__: TST, MAINT: > remove dead code in Travis CI > * `#11643 `__: MAINT: fix > conversion in binom_test > * `#11645 `__: MAINT: Assorted > clean up. > * `#11646 `__: MAINT: Remove > unnecessary 'from __future__ import ...' statements > * `#11647 `__: DOC: document > return_all arguments > * `#11648 `__: Perform geometric > slerp in quaternion space > * `#11651 `__: DOC: Update paper > URL in lambertw documentation > * `#11653 `__: PERF: Switch to > C++ STL std::nth_element > * `#11655 `__: MAINT: Remove > Python2 cStringStream > * `#11657 `__: ENH: Add wrapper > for ?pttrf/?pttrs > * `#11664 `__: ENH: Add wrapper > for ?gejsv > * `#11665 `__: ENH: Add wrapper > for ?pteqr > * `#11667 `__: BUG: Non-central > Fisher distribution (fix nan-values when nc=0) > * `#11668 `__: ENH: Add wrapper > for ?gtsvx > * `#11671 `__: TST, CI: restore > Azure temporarily > * `#11672 `__: Add warning to > medfilt when array size < kernel_size > * `#11674 `__: TST: bump test > precision for two np.dot related linalg tests. > * `#11675 `__: MAINT: > pycodestyle clean-up > * `#11677 `__: ENH: Add wrapper > for ?ptsvx > * `#11679 `__: BENCH: cKDTree > benchmarks added: balanced/unbalanced tree (related... > * `#11680 `__: MAINT: > rng_integers allows RandomState.randint or Generator.integers > * `#11683 `__: BUG: fix > mode='mirror' on length 1 axes > * `#11684 `__: BUG: fix > scipy.special.voigt_profile > * `#11687 `__: MAINT: > sparse.linalg: avoid importing from \`np.core\` > * `#11688 `__: ENH: mypy: get > specific about ignoring missing imports > * `#11690 `__: MAINT: mypy: fix > errors about incompatible types in lists > * `#11692 `__: MAINT: mypy: fix > remaining type errors > * `#11694 `__: TST, MAINT: bump > to OpenBLAS 0.3.9 stable, raise tol for Win... > * `#11697 `__: DOC: fix pdf of > norminvgauss in scipy.stats > * `#11701 `__: MAINT: special: > add rudimentary types for \`_ufuncs\` extension... > * `#11702 `__: BUG: Fixed a > post-merge bug for eigh() > * `#11703 `__: Improves > docstring with consistent L2-norm > * `#11705 `__: DOC: Slerp the > SphericalVoronoi docstring > * `#11706 `__: ENH: mypy: add > \`--mypy\` option to \`runtests.py\` > * `#11710 `__: ENH: Modified > stats.kstest() to use the exact stats.kstwo.sf()... > * `#11715 `__: DOC: add .. > versionadded:: to as_matrix/from_matrix in spatial/transf? > * `#11716 `__: BENCH: fix > benchmark imports for \`\`optimize_linprog.py\`\` > * `#11721 `__: MAINT: io: Remove > now-unnecessary \`# type: ignore\` > * `#11722 `__: MAINT: mypy: > remove mpmath from the ratchet > * `#11726 `__: Handle constant > input for scipy.stats.f_oneway > * `#11729 `__: BENCH: optimize: > added infeasible benchmarks for linprog > * `#11731 `__: fix inaccurate > information about Mac OS compiler (#11696) > * `#11733 `__: Fix inaccurate > docstring example of HalfspaceIntersection > * `#11734 `__: Doc: fix > inaccurate docstring of SmoothBivariateSpline. > * `#11735 `__: Bug: stats: fix > wrong shape from median_absolute_deviation for... > * `#11736 `__: ENH: add input > validations and its tests for FITPACK in fitpack2.py > * `#11737 `__: BUG: Prevent > crashes due to MKL bug in ?heevr > * `#11739 `__: MAINT: special: > add type stubs for \`_test_round.pyx\` > * `#11740 `__: MAINT: special: > remove unused specfun f2py wrappers > * `#11741 `__: BUG: fix small > tolerances handling for minpack and add a test. > * `#11743 `__: Doc: fix > docstring of rfft, rfft2, rfftn, irfft, irfft2, irfftn... > * `#11744 `__: MAINT: Remove > unused py3k.h code > * `#11745 `__: DOC: stats: Clean > up ncf documentation. > * `#11748 `__: MAINT: special: > type \`cython_special\` as \`Any\` > * `#11750 `__: MAINT: type hints > for \`_spherical_voronoi\` > * `#11752 `__: DOC: fix > docstring of scipy.optimize.least_squares > * `#11753 `__: ENH: add input > validation for dendrogram and a test. > * `#11755 `__: MAINT: Replace > uses of tostring with tobytes > * `#11757 `__: ENH: improve > binned_statistics_2d performance. > * `#11759 `__: ENH: optimize: > add HiGHS methods to linprog > * `#11760 `__: MAINT: Remove > FileStream replaced by GenericStream > * `#11761 `__: MAINT: Replace > npy_3kcompat.h shims > * `#11765 `__: TST: Speedup > test_pascal which is VERY slow on Azure > * `#11766 `__: TST: speed up > differential_evolution L8 test > * `#11767 `__: Change comment in > continuous rv gamma fit function > * `#11776 `__: Add domain option > for resample. > * `#11784 `__: BUG: Fixed > calculation of nonzero elements in scipy.sparse.random > * `#11786 `__: ENH: stats: add > axis keyword argument to scipy.stats.rankdata > * `#11789 `__: Doc: fix > docstring of scipy.spatial.chebyshev > * `#11792 `__: DOC: dev: add > guidelines for developing public Cython APIs > * `#11794 `__: MAINT: add > comments explaining a problem in cython_optimize organization > * `#11796 `__: DOC: add a note > about precision losing in csgraph.minimum_spanning_tree... > * `#11797 `__: ENH: Allow > negative \`axis\` in \`interpolate.BSpline\`. Also... > * `#11798 `__: Add > simplify_cells parameter to scipy.io.loadmat > * `#11801 `__: MAINT, DOC: minor > changes of ratio-of-uniforms in scipy.stats > * `#11802 `__: BUG: fix > scipy.odr to handle multidimensional independent and... > * `#11803 `__: > scipy.stats.trapz: Use analytic formulas for stats and entropy. > * `#11808 `__: DOC: add Examples > in the scipy.interpolate.interpn docstring. > * `#11809 `__: Duplicate entries > are added together in csr_matrix constructor > * `#11813 `__: MAINT: bump > pyflakes to version 2.1.1 > * `#11814 `__: BUG: > scipy.sparse.csr doctest failing with incorrect output value > * `#11817 `__: DOC: add Examples > in the scipy.optimize.leastsq docstring > * `#11820 `__: ENH: Raise an > error on incorrect bounds format in optimize.fmin_l_bfgs_b > * `#11822 `__: CI: add github > actions for macOS > * `#11824 `__: DOC: add Examples > in scipy.optimize.line_search docstring (line_search_wolfe2) > * `#11830 `__: TST: Always use > fork for multiprocessing in fft tests > * `#11831 `__: DOC: add Examples > and Returns in scipy.misc.central_diff_weights... > * `#11832 `__: DOC: stats: Some > small corrections to a couple docstrings. > * `#11833 `__: BUG: Fix > compiler_name when there are paths used in flags > * `#11836 `__: MAINT: > re-introduce multiprocessing tests on Python3.8 > * `#11837 `__: Doc: add Examples > in scipy.optimize.fsolve docstring > * `#11838 `__: Doc: add Examples > in scipy.sparse.linalg.minres docstring > * `#11840 `__: BUG: > sparse.linalg: fix overflow in expm intermediate computation > * `#11842 `__: BLD: fix build > with gfortran 10 > * `#11843 `__: MAINT: Simplify > floats in constants.py > * `#11847 `__: DOC: add a > tutorial of scipy.optimize.linprog > * `#11849 `__: ENH: speed up > geninvgauss by using cython > * `#11852 `__: CI: remove osx > from travisCI > * `#11857 `__: BUG: Change > parameter fc of gausspulse to float. > * `#11861 `__: order = degree + > 1 for splines > * `#11863 `__: Make g77 ABI > wrapper work with gfortran ABI lapack > * `#11866 `__: MAINT: add type > ignores to sympy and matplotlib imports > * `#11867 `__: CI: Add arm64 in > travis-ci > * `#11869 `__: DOC: signal: Add > an example to the lsim2 docstring. > * `#11870 `__: DOC: signal: Use > impulse instead of impulse2 in the impulse example... > * `#11871 `__: ENH: type ufuncs > in special as ufuncs instead of Any > * `#11872 `__: BUG: avoid > recomputing in scipy.optimize.optimize.MemoizeJac > * `#11873 `__: DOC: signal: Fix > ODE in impulse and impulse2 docstrings. > * `#11874 `__: DOC: add Examples > of docstring for scipy.interpolate.approximate_taylor_polynomial > * `#11878 `__: DOC: fixed a typo > under scipy/integrate/quadrature.py > * `#11879 `__: BUG: Fix index > arrays overflow in sparse.kron > * `#11880 `__: DOC: stats: Add > Examples for bartlett, fligner, levene. > * `#11881 `__: MAINT: normalise > numpy-->np in optimize.py > * `#11882 `__: DOC: add Examples > for scipy.io.readsav docstring. > * `#11883 `__: DOC: add Returns > and Examples for scipy.ndimage.correlate() docstring > * `#11885 `__: BUG: stats: > Handle multidimensional arrays in f_oneway, and more. > * `#11889 `__: DOC: signal: > Unify lsim and lsim2 examples. > * `#11896 `__: BUG: stats: Fix > handling of size 0 inputs for ttest_rel and ttest_ind. > * `#11897 `__: DOC: Remove > misleading default values from fit method > * `#11898 `__: MAINT: > LinearVectorFunction.J is ndarray closes #11886 > * `#11902 `__: BUG: linalg: > test_heequb failure > * `#11904 `__: fix real-to-real > transforms for complex inputs and overwrite_x=True > * `#11906 `__: DOC: stats: fix > error caused by trapz docstring > * `#11907 `__: BUG: stats: fixed > SEGFAULT from Issue #9710 > * `#11912 `__: ENH: Respect > matplotlib color palette with hierarchy/dendrogram. > * `#11914 `__: DOC: refine doc > for spatial.distance.squareform > * `#11915 `__: ENH: Ndim linear > operator > * `#11919 `__: ENH: expose > "window_size" parameter in find_peaks_cwt() > * `#11920 `__: DOC: explain M, > diffev > * `#11923 `__: CI: macOS install > swig closes #11922 > * `#11924 `__: DOC: add Examples > for scipy.optimize.bracket() docstring > * `#11930 `__: DOC: add Examples > and clean up for signal.qspline1d and signal.qspline_eval... > * `#11931 `__: DOC: add Examples > for sparse.linalg.bicg docstring. > * `#11933 `__: DOC: Add original > reference for Yao-Liu objective functions > * `#11934 `__: DOC, MAINT: > mailmap update > * `#11935 `__: DOC: make > scipy.stats.mode documentation reflect that the function... > * `#11936 `__: ENH: special: add > type stubs for \`orthogonal.py\` > * `#11937 `__: DOC: Add > docstring examples to fft2, ifft2, io.savemat > * `#11938 `__: MAINT: add helper > function for deprecating Cython API functions > * `#11942 `__: MAINT: ignore > conditional import in _lib/_util > * `#11943 `__: MAINT: special: > add types for geterr/seterr/errstate > * `#11946 `__: MAINT: add > py.typed marker > * `#11950 `__: TST:MAINT: > separated and stabilized heequb tests > * `#11952 `__: DOC: update > toolchain roadmap for py38, C99, C++11/14 > * `#11957 `__: MAINT: Use > np.errstate context manager instead of np.seterr. > * `#11958 `__: MAINT: > interpolate: Remove some trailing spaces. > * `#11960 `__: MAINT: Cleanup > Python2 compatibility code > * `#11961 `__: MAINT: Remove > numpy/npy_3kcompat.h from _superluobject.c > * `#11962 `__: DOC: Fix type of > \`codes\` in docstring of \`_vq._vq()\` > * `#11964 `__: MAINT: Cleanup > unused IS_PYPY > * `#11969 `__: DOC: add Examples > and fix docstring for special.airye > * `#11970 `__: BUG: sparse: > 'diagonal' of sparse matrices fixed to match numpy's... > * `#11974 `__: BUG: Reshape > oaconvolve output even when no axes are convolved > * `#11976 `__: MAINT: add logo > for github actions > * `#11977 `__: CI: test bleeding > edge Python > * `#11979 `__: DOC: add Examples > for stats.ranksums() docstring. > * `#11982 `__: Fix KMeans++ > initialisation slowness > * `#11983 `__: DOC: add Examples > for stats.mstats.argstoarray() docstring. > * `#11986 `__: Avoid bugs in > ndimage when the output and input arrays overlap... > * `#11988 `__: ENH: Override fit > method of Laplace distribution with Maximum... > * `#11993 `__: TST, CI: Azure > Windows path fixups > * `#11995 `__: MAINT, CI: remove > custom mingw Azure > * `#11996 `__: DOC: add Examples > and fix pep warning for fft.set_global_backend... > * `#11997 `__: MAINT, CI: Azure > OpenBLAS simplify > * `#11998 `__: BENCH: Run > against current HEAD instead of master > * `#12001 `__: ENH: stats: > Implement _logpdf for the maxwell distribution. > * `#12004 `__: DOC: add examples > for integrate.quad_vec() and integrate.quad_explain() > * `#12005 `__: MAINT: Use helper > functions in ?tbtrs tests > * `#12007 `__: MAINT: updated > LICENSES_bundled for pybind11 and six > * `#12008 `__: DOC: roadmap > update > * `#12009 `__: ENH: optimize: > support 64-bit BLAS in lbfgsb > * `#12010 `__: ENH: > sparse.linalg: support 64-bit BLAS in isolve > * `#12012 `__: DOC: add Examples > for interpolate.barycentric_interpolate(),... > * `#12013 `__: MAINT: remove > last uses of numpy.dual > * `#12014 `__: CI: print 10 > slowest tests > * `#12020 `__: MAINT: Removed > handling of circular input in SphericalVoronoi > * `#12022 `__: DOC : added > default value of absolute_sigma to False in scipy.optimize.curve_fit docs > * `#12024 `__: DOC: add Examples > for io.hb_read() and io.hb_write() > * `#12025 `__: MAINT: Remove > numpy/npy_3kcompat.h from nd_image > * `#12028 `__: Spelling > correction > * `#12030 `__: ENH: > optimize/_trlib: support ILP64 blas/lapack > * `#12036 `__: MAINT: Add some > generated C files .gitignore > * `#12038 `__: MAINT, CI: Travis > rackcdn->conda.org > * `#12039 `__: MAINT: signal: > Lower the resolution of the plots in the chirp... > * `#12040 `__: DOC: add Examples > for ndimage.spline_filter1d() and spline_filter()... > * `#12044 `__: MAINT: combine > apt-get update and apt-get install into one RUN > * `#12045 `__: TST: Reduce size > of test_diagonal_types to speed up tests > * `#12046 `__: MAINT: Remove > unused npy_3kcompat.h > * `#12047 `__: MAINT: Cython 3.0 > compat > * `#12050 `__: DOC: add download > number badges of PyPI and conda-forge in README.rst > * `#12052 `__: DOC: add Examples > odr.models.polynomial() and fix odr.odr docstring... > * `#12056 `__: ENH: Modifies > shapiro to return a named tuple > * `#12057 `__: Adding my name > into THANKS.txt > * `#12060 `__: TST: Reduce > number of test_diagonal_types configs > * `#12062 `__: TST: Change > dec.slow to pytest.mark.slow > * `#12068 `__: ENH: Modifies > jarque_bera to return a named tuple > * `#12070 `__: MAINT, CI: > appveyor rack->conda.org > * `#12072 `__: TST: filter out > factorial(float) deprecation warning > * `#12078 `__: TST: Skip test on > colab with large memory alloc > * `#12079 `__: DOC: Remove > Python2 reference from stats tutorial > * `#12081 `__: DOC: add Examples > docstring for optimize.show_options() > * `#12084 `__: BUG: interpolate: > fix BarycentricInterpolator with integer input... > * `#12089 `__: ENH: > spatial/qhull: support ILP64 Lapack > * `#12090 `__: ENH: integrate: > support ILP64 BLAS in odeint/vode/lsoda > * `#12091 `__: ENH: integrate: > support ILP64 in quadpack > * `#12092 `__: BUG: Fix dropping > dt in signal.StateSpace > * `#12093 `__: MAINT: Rollback > python2.6 workaround > * `#12094 `__: MAINT: > \`openblas_support\` hash checks > * `#12095 `__: MAINT: ndimage: > change \`shares_memory\` to \`may_share_memory\` > * `#12098 `__: Doc: change 4 > model instances of odr to be instances of \`Model\`... > * `#12101 `__: Removed more > unused imports and assignments. > * `#12107 `__: ENH: Area > calculation for 2D inputs in SphericalVoronoi > * `#12108 `__: MAINT: ensure > attributes have correct data type in \`SphericalVoronoi\` > * `#12109 `__: degree is not > order in splines > * `#12110 `__: ENH: More > helpful/forgiving io.wavfile errors > * `#12117 `__: BUG: fix newline > * `#12123 `__: [MAINT] Fix error > on PyData/Sparse import. > * `#12124 `__: TST: Always test > matmul now that Python3.5+ is required > * `#12126 `__: TST: Cleanup > unused matplotlib code. > * `#12127 `__: DOC: update > docstrings of signal.cspline2d, qspline2d, sepfir2d > * `#12130 `__: MAINT: Fixing > broken links with linkchecker > * `#12135 `__: ENH: linalg: Add > the function convolution_matrix. > * `#12136 `__: MAINT: Cleanup > np.poly1d hack > * `#12137 `__: TST, CI: > reproduce wheels 32-bit setup > * `#12140 `__: TST: stats: add > kstwo, ksone to slow tests. > * `#12141 `__: Support 64-bit > integer size in Fitpack > * `#12151 `__: DOC: Correct > Rosenbrock function sum > * `#12159 `__: BUG: Fix length > calculation in upfirdn > * `#12160 `__: BUG: Fix M_PI > * `#12168 `__: DOC: add an > obsolete version checking javascript to doc release... > * `#12171 `__: CI, MAINT: Azure > OpenBLAS drive flip > * `#12172 `__: ENH: Bounds for > the Powell minimization method > * `#12175 `__: BLD: support more > Fortran compilers for ilp64 and macro expansion... > * `#12179 `__: BUG: stats: A few > distributions didn't accept lists as arguments. > * `#12180 `__: MAINT: removed > redundant import in SphericalVoronoi tests > * `#12181 `__: DOC: for > versionwarning don't use $.getScript > * `#12182 `__: MAINT: random > sampling on the hypersphere in SphericalVoronoi... > * `#12194 `__: MAINT: Module and > example cleanups for doc build > * `#12202 `__: ENH: tool to DL > release wheels from Anaconda > * `#12210 `__: Remove py.typed > marker (at least for the release) > * `#12217 `__: BUG: stats: Fix > handling of edge cases in median_abs_deviation. > * `#12223 `__: BUG: stats: > wilcoxon returned p > 1 for certain inputs. > * `#12227 `__: BLD: Set macos > min version when building rectangular_lsap > * `#12229 `__: MAINT: > tools/gh_lists.py: fix http header case sensitivity issue > * `#12236 `__: DOC: Fix a couple > grammatical mistakes in 1.5.0-notes.rst. > * `#12276 `__: TST: skip > `test_heequb`, it fails intermittently. > * `#12285 `__: CI: split travis > arm64 run into two > * `#12317 `__: BUG: prevent > error accumulation in `Rotation` multiplication > * `#12318 `__: BUG: sparse: > avoid np.prod overflow in check_shape > * `#12319 `__: BUG: Make cobyla > threadsafe > * `#12335 `__: MAINT: Work > around Sphinx bug > > > Checksums > ========= > > MD5 > ~~~ > > 6b67c3cdb5fd7ec7f65445ce5432c2d3 > scipy-1.5.0-cp36-cp36m-macosx_10_9_x86_64.whl > cb1c6b8022891ef2644caf26f6d6d0f2 > scipy-1.5.0-cp36-cp36m-manylinux1_i686.whl > 28a26064ae38b16c370be9691d0be2de > scipy-1.5.0-cp36-cp36m-manylinux1_x86_64.whl > 1a8324e7940ab7c405e534823a33872f scipy-1.5.0-cp36-cp36m-win32.whl > 241c63762ae6e903b06c2498f5fef5d9 scipy-1.5.0-cp36-cp36m-win_amd64.whl > c9642dfdc834dfc73b83fce7a05c6101 > scipy-1.5.0-cp37-cp37m-macosx_10_9_x86_64.whl > 30ec965fac402610192ff67428848f74 > scipy-1.5.0-cp37-cp37m-manylinux1_i686.whl > 46c7068c7cf789777ec4423b2ff83f5f > scipy-1.5.0-cp37-cp37m-manylinux1_x86_64.whl > 21a5d8636489c065ce84fcba238c0c32 scipy-1.5.0-cp37-cp37m-win32.whl > cd0429315d501470b5bb732d23fddf9d scipy-1.5.0-cp37-cp37m-win_amd64.whl > 99a35969fdd5329436f679e02c23f185 > scipy-1.5.0-cp38-cp38-macosx_10_9_x86_64.whl > 721abc2147746de50e639832c54d1c0a scipy-1.5.0-cp38-cp38-manylinux1_i686.whl > c51a2faadfda7bc56e1492218f9d044c > scipy-1.5.0-cp38-cp38-manylinux1_x86_64.whl > 8f70224a6b8fb8e55cff52c83df30663 scipy-1.5.0-cp38-cp38-win32.whl > 8e0c33036795485d14c6221d00cacb9e scipy-1.5.0-cp38-cp38-win_amd64.whl > 4b0fc5a2eae9764c302187af4fad975f scipy-1.5.0.tar.gz > 4157e49b7a0ba3c74b9df6df90d43245 scipy-1.5.0.tar.xz > a14f9de5ed51eb23c8dfa739ec4f50ff scipy-1.5.0.zip > > SHA256 > ~~~~~~ > > 8f354e92246de33c44ddfc5fef61bce8c19d5aeeb2130b6a672b15db619453e4 > scipy-1.5.0-cp36-cp36m-macosx_10_9_x86_64.whl > 244b4a23a8cb6707e19f5579502112954659bb983852b1c381243fe46d9b6818 > scipy-1.5.0-cp36-cp36m-manylinux1_i686.whl > d266d955c3fd12336c948abb368de230bf8dc20efad428abb908165d9c87f53f > scipy-1.5.0-cp36-cp36m-manylinux1_x86_64.whl > 11d8bfcea08e971968d07495bdf1de37b3b1bb5ca78e4ddbe8d60791f0456942 > scipy-1.5.0-cp36-cp36m-win32.whl > eb48915142f2dbd4b84df8ca66e433946df1a13eff36015c2b7843aa39dbc30d > scipy-1.5.0-cp36-cp36m-win_amd64.whl > ae24f16056c87e7f086a56a7aaf6e65e4626ac70b7e08d7f54e078693abcf778 > scipy-1.5.0-cp37-cp37m-macosx_10_9_x86_64.whl > 1b23129e9838694c36475b296ac251ae0b0247455352f2bed0b246c30b61c822 > scipy-1.5.0-cp37-cp37m-manylinux1_i686.whl > 69eb6245ff472db406c3e9b3e13bd0dc6e2ff48e7e758a7bfca296ecdb1ae8b9 > scipy-1.5.0-cp37-cp37m-manylinux1_x86_64.whl > 38cdb4eafe727b324f295ab69eaa0788a8eefe08d59360968928753ab7f68ba9 > scipy-1.5.0-cp37-cp37m-win32.whl > f662ad49ef930325161bd5edac39932c3f1b55547eaa0afce08367522f6314df > scipy-1.5.0-cp37-cp37m-win_amd64.whl > 40969696eb13c2f1b6fc8e99ce597a47627f0167a7feb6086c2ccdfb55835cfc > scipy-1.5.0-cp38-cp38-macosx_10_9_x86_64.whl > 0f62f3be924a4314cf2384c6f77d3a0e3bf4ada370530a7d0a6d5a61192bec9e > scipy-1.5.0-cp38-cp38-manylinux1_i686.whl > 4e1a790fdf82a67619a38f017105df4bb66dfcdaea45df793ece27fd534720c2 > scipy-1.5.0-cp38-cp38-manylinux1_x86_64.whl > 2e99f50d0061c385f8f46c5a99bb07ad013ec2dcf95ccba3be4e081594e7ab19 > scipy-1.5.0-cp38-cp38-win32.whl > 2aec0f81a29440e0c000222ac0447748a840d328b5698dd900ece4113bca5cde > scipy-1.5.0-cp38-cp38-win_amd64.whl > 4ff72877d19b295ee7f7727615ea8238f2d59159df0bdd98f91754be4a2767f0 > scipy-1.5.0.tar.gz > 23baeaa18803d12d1abdff3f5c148b1085c2dc4028c6b8efce652dde2119b41c > scipy-1.5.0.tar.xz > 92b17f65c2521a48e1853cbc6b1038140f38393ce6293bbdba6e99a7653d8063 > scipy-1.5.0.zip > From numpy_gsod at bigriver.xyz Mon Jun 22 14:42:44 2020 From: numpy_gsod at bigriver.xyz (Ben Nathanson) Date: Mon, 22 Jun 2020 14:42:44 -0400 Subject: [Numpy-discussion] Guidelines for NumPy tutorials Message-ID: I've submitted PR #11 in the new numpy-tutorials repo (https://github.com/numpy/numpy-tutorials/pull/11) to provide a checklist and standard style for writing tutorials. Added tutorial content is an objective of NEP 44. We're expecting part of the content to come from new contributors (for instance, through Ryan Cooper's generous offer to get his students involved, https://mail.python.org/pipermail/numpy-discussion/2020-May/080715.htmll). The PR will provide a guide for all contributors to work from. While "tutorial" is often used broadly for introductory material, here it is closely defined: a multistep participatory walkthrough for a user new to NumPy. This is the meaning of "tutorial" in NEP 44; it was originally distinguished from other kinds of documentation by Daniele Procida (https://documentation.divio.com/tutorials/). One goal of the PR, in fact, is to make sure the tutorial stays a tutorial and doesn't mission-creep into other kinds of introductory documentation. Procida's insight is that mission creep like this leads to failed docs. At today's docs meeting it was suggested that the PR be announced on the mailing list for possible further comment. From melissawm at gmail.com Mon Jun 22 15:12:07 2020 From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=) Date: Mon, 22 Jun 2020 16:12:07 -0300 Subject: [Numpy-discussion] Guidelines for NumPy tutorials In-Reply-To: References: Message-ID: Hi all, Thanks for the PR, Ben. Note that this is in the numpy-tutorials repo, which is a new repo created to specifically host Jupyter notebook tutorials for NumPy users. It is still not in its final form. One of the questions around this PR is where this style guide should live: in the main documentation or in the numpy-tutorials repo? If you have thoughts on this, please share. Best, - Melissa On Mon, Jun 22, 2020 at 3:44 PM Ben Nathanson wrote: > I've submitted PR #11 in the new numpy-tutorials repo > (https://github.com/numpy/numpy-tutorials/pull/11) to provide a > checklist and standard style for writing tutorials. > > Added tutorial content is an objective of NEP 44. We're expecting part > of the content to come from new contributors (for instance, through > Ryan Cooper's generous offer to get his students involved, > https://mail.python.org/pipermail/numpy-discussion/2020-May/080715.htmll). > The PR will provide a guide for all contributors to work from. > > While "tutorial" is often used broadly for introductory material, here > it is closely defined: a multistep participatory walkthrough for a > user new to NumPy. > > This is the meaning of "tutorial" in NEP 44; it was originally > distinguished from other kinds of documentation by Daniele Procida > (https://documentation.divio.com/tutorials/). > > One goal of the PR, in fact, is to make sure the tutorial stays a > tutorial and doesn't mission-creep into other kinds of introductory > documentation. Procida's insight is that mission creep like this leads > to failed docs. > > At today's docs meeting it was suggested that the PR be announced on > the mailing list for possible further comment. > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cv1038 at wildcats.unh.edu Tue Jun 23 14:48:04 2020 From: cv1038 at wildcats.unh.edu (Chris Vavaliaris) Date: Tue, 23 Jun 2020 11:48:04 -0700 (MST) Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) In-Reply-To: <1591670629042-0.post@n7.nabble.com> References: <1591279296277-0.post@n7.nabble.com> <1591388154629-0.post@n7.nabble.com> <1591670629042-0.post@n7.nabble.com> Message-ID: <1592938084292-0.post@n7.nabble.com> Chris Vavaliaris wrote > Hello, > > - my first reaction would be that the less argument names we change at a > time the better, so that we don't confuse people or cause codes written > with > previous NumPy versions to break. Personally I always think of "ortho" as > "orthonormal", which immediately brings "unit norm" to mind, but I have no > problem whatsoever with changing its name to "unitary" or maybe "unit", > which I'd probably choose if we were writing the routines from scratch. > > - In terms of the "inverse" name option, I do believe that it'd be a > confusing choice since "inverse" is used to describe the inverse FFT; if > we > choose to stick with a name that's based on the fact that this scaling is > opposite to the "norm=None" option, then I'd suggest "norm=opposite" as a > better choice. However, following Ross' comment, I think we could choose a > name based on the fact that the forward transform is now scaled by `n`, > instead of the backward one as in the default "norm=None". In this case, > I'd > suggest "norm=forward", which we can also nicely abbreviate to the > 4-character form "norm=forw" if desirable. > > Chris > > > Feng Yu wrote >> Hi, >> >> 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as 'unitary'. >> Since we are in general working with complex numbers, I do suggest >> unitary >> over ortho. >> (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) and ( >> https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT) >> >> 2. I share Chris's concern about 'inverse', but I could not come up with >> a >> nice name. >> >> 3. Now that we are at this, should we also describe the corresponding >> continuum limit of FFT and iFFT in the documentation? >> >> A paragraph doing so could potentially also help people diagnose some of >> the normalization factor errors. I assumed it is common that one needs to >> translate a CFT into DFT when coding a paper up, and the correct >> compensation to the normalization factors will surface if one does the >> math. -- I had the impression 1 / N corresponds to 1 / 2pi if the >> variable >> is angular frequency, but it's been a while since I did that last time. >> >> - Yu >> >> NumPy-Discussion mailing list > >> NumPy-Discussion@ > >> https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > -- > Sent from: http://numpy-discussion.10968.n7.nabble.com/ > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@ > https://mail.python.org/mailman/listinfo/numpy-discussion Hello all, the discussion on this topic has been stagnant for the past couple of weeks, so I just wanted to ask if anyone has any alternative names for the new normalization option that would like to share. If not, I'd suggest that we move on with "norm=forward", which seems to be a more straightforward choice than the "norm=inverse" naming alternative. I can wait a couple of days for possible new recommendations to be submitted, and will then recommit to the open PR to account for the new kwarg name. In terms of the name for the "norm=ortho" option, I suggest that we keep it as is for now so that we don't introduce two API changes at once. If desired, we can discuss it separately and open a new PR introducing a name such as "norm=unitary" or "unit" as recommended in previous messages. I'm happy to handle that if you think it'd be a useful change. Chris -- Sent from: http://numpy-discussion.10968.n7.nabble.com/ From rainwoodman at gmail.com Tue Jun 23 19:10:22 2020 From: rainwoodman at gmail.com (Feng Yu) Date: Tue, 23 Jun 2020 16:10:22 -0700 Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) In-Reply-To: <1592938084292-0.post@n7.nabble.com> References: <1591279296277-0.post@n7.nabble.com> <1591388154629-0.post@n7.nabble.com> <1591670629042-0.post@n7.nabble.com> <1592938084292-0.post@n7.nabble.com> Message-ID: Your approach sounds good to me. Thanks, Yu On Tue, Jun 23, 2020 at 11:51 AM Chris Vavaliaris wrote: > Chris Vavaliaris wrote > > Hello, > > > > - my first reaction would be that the less argument names we change at a > > time the better, so that we don't confuse people or cause codes written > > with > > previous NumPy versions to break. Personally I always think of "ortho" as > > "orthonormal", which immediately brings "unit norm" to mind, but I have > no > > problem whatsoever with changing its name to "unitary" or maybe "unit", > > which I'd probably choose if we were writing the routines from scratch. > > > > - In terms of the "inverse" name option, I do believe that it'd be a > > confusing choice since "inverse" is used to describe the inverse FFT; if > > we > > choose to stick with a name that's based on the fact that this scaling is > > opposite to the "norm=None" option, then I'd suggest "norm=opposite" as a > > better choice. However, following Ross' comment, I think we could choose > a > > name based on the fact that the forward transform is now scaled by `n`, > > instead of the backward one as in the default "norm=None". In this case, > > I'd > > suggest "norm=forward", which we can also nicely abbreviate to the > > 4-character form "norm=forw" if desirable. > > > > Chris > > > > > > Feng Yu wrote > >> Hi, > >> > >> 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as > 'unitary'. > >> Since we are in general working with complex numbers, I do suggest > >> unitary > >> over ortho. > >> (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) > and ( > >> > https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT) > >> > >> 2. I share Chris's concern about 'inverse', but I could not come up with > >> a > >> nice name. > >> > >> 3. Now that we are at this, should we also describe the corresponding > >> continuum limit of FFT and iFFT in the documentation? > >> > >> A paragraph doing so could potentially also help people diagnose some of > >> the normalization factor errors. I assumed it is common that one needs > to > >> translate a CFT into DFT when coding a paper up, and the correct > >> compensation to the normalization factors will surface if one does the > >> math. -- I had the impression 1 / N corresponds to 1 / 2pi if the > >> variable > >> is angular frequency, but it's been a while since I did that last time. > >> > >> - Yu > >> > >> NumPy-Discussion mailing list > > > >> NumPy-Discussion@ > > > >> https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > > > > > > -- > > Sent from: http://numpy-discussion.10968.n7.nabble.com/ > > _______________________________________________ > > NumPy-Discussion mailing list > > > NumPy-Discussion@ > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > Hello all, > the discussion on this topic has been stagnant for the past couple of > weeks, > so I just wanted to ask if anyone has any alternative names for the new > normalization option that would like to share. > > If not, I'd suggest that we move on with "norm=forward", which seems to be > a > more straightforward choice than the "norm=inverse" naming alternative. I > can wait a couple of days for possible new recommendations to be submitted, > and will then recommit to the open PR to account for the new kwarg name. > > In terms of the name for the "norm=ortho" option, I suggest that we keep it > as is for now so that we don't introduce two API changes at once. If > desired, we can discuss it separately and open a new PR introducing a name > such as "norm=unitary" or "unit" as recommended in previous messages. I'm > happy to handle that if you think it'd be a useful change. > > Chris > > > > > > -- > Sent from: http://numpy-discussion.10968.n7.nabble.com/ > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Tue Jun 23 19:35:13 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 23 Jun 2020 18:35:13 -0500 Subject: [Numpy-discussion] NumPy Community Meeting Wednesday Message-ID: Hi all, There will be a NumPy Community meeting Wednesday May 27th 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From kevin.k.sheppard at gmail.com Wed Jun 24 10:31:15 2020 From: kevin.k.sheppard at gmail.com (Kevin Sheppard) Date: Wed, 24 Jun 2020 15:31:15 +0100 Subject: [Numpy-discussion] ANN: randomgen 1.19.0 release Message-ID: randomgen 1.19.0 has been released with bug fixes and new features. *New Features* - A helper class that lets users define custom bit generators in Python (slow) or numba (fast). This simplifies experimenting with alternative configurations. The UserBitGenerator can be used with numpy.random.Generator to produce variants from a wide range of distributions. https://bashtage.github.io/randomgen/custom-bit-generators.html - New bit generators: - PCG64DXSM - The cheap-multiplier variant that produces output before updating the state. This generator may become the default in NumPy in the future and is the 2.0 version of PCG64. - LCG128Mix - A 128-bit LCG with a settable multiplier, increment, and output function. This generator nests both PCG64 and PCG64DXSM as special cases. It also can act as a standard 128bit LCG/MCG. - EFIIX64 (x48 variant) - Chris Doty's stream cipher-like generator - SFC64 with settable counter increment which allows distinct streams to be produced from the same SeedSequence. - LXM - A generator that mixes the output of a 64 bit-LCG and a 256bit Xorshift. - ExtendedGenerator contains methods for producing variants that are not included in numpy.random.Generator. *Deprecations* Both Generator and RandomState have been officially deprecated. The NumPy versions are both better maintained and feature-rich. *Other* All bit generators have been tested output at least 1TB (many to 4TB) both as single streams, interleaved and interleaved with 4 or 8196 other bit generators. When interleaved, the additional generators were constructed using both SeedSequence.spawn and jumped (when available). https://bashtage.github.io/randomgen/testing.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossbar15 at gmail.com Wed Jun 24 13:37:53 2020 From: rossbar15 at gmail.com (Ross Barnowski) Date: Wed, 24 Jun 2020 10:37:53 -0700 Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) In-Reply-To: References: <1591279296277-0.post@n7.nabble.com> <1591388154629-0.post@n7.nabble.com> <1591670629042-0.post@n7.nabble.com> <1592938084292-0.post@n7.nabble.com> Message-ID: I think it's also important to get the thoughts of the SciPy community on this topic so that we avoid divergence between numpy.fft and scipy.fft. I would recommend sending this discussion to the scipy mailing list as well. ~Ross On Tue, Jun 23, 2020 at 4:11 PM Feng Yu wrote: > Your approach sounds good to me. > > Thanks, > > Yu > > On Tue, Jun 23, 2020 at 11:51 AM Chris Vavaliaris > wrote: > >> Chris Vavaliaris wrote >> > Hello, >> > >> > - my first reaction would be that the less argument names we change at a >> > time the better, so that we don't confuse people or cause codes written >> > with >> > previous NumPy versions to break. Personally I always think of "ortho" >> as >> > "orthonormal", which immediately brings "unit norm" to mind, but I have >> no >> > problem whatsoever with changing its name to "unitary" or maybe "unit", >> > which I'd probably choose if we were writing the routines from scratch. >> > >> > - In terms of the "inverse" name option, I do believe that it'd be a >> > confusing choice since "inverse" is used to describe the inverse FFT; if >> > we >> > choose to stick with a name that's based on the fact that this scaling >> is >> > opposite to the "norm=None" option, then I'd suggest "norm=opposite" as >> a >> > better choice. However, following Ross' comment, I think we could >> choose a >> > name based on the fact that the forward transform is now scaled by `n`, >> > instead of the backward one as in the default "norm=None". In this case, >> > I'd >> > suggest "norm=forward", which we can also nicely abbreviate to the >> > 4-character form "norm=forw" if desirable. >> > >> > Chris >> > >> > >> > Feng Yu wrote >> >> Hi, >> >> >> >> 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as >> 'unitary'. >> >> Since we are in general working with complex numbers, I do suggest >> >> unitary >> >> over ortho. >> >> (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) >> and ( >> >> >> https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT) >> >> >> >> 2. I share Chris's concern about 'inverse', but I could not come up >> with >> >> a >> >> nice name. >> >> >> >> 3. Now that we are at this, should we also describe the corresponding >> >> continuum limit of FFT and iFFT in the documentation? >> >> >> >> A paragraph doing so could potentially also help people diagnose some >> of >> >> the normalization factor errors. I assumed it is common that one needs >> to >> >> translate a CFT into DFT when coding a paper up, and the correct >> >> compensation to the normalization factors will surface if one does the >> >> math. -- I had the impression 1 / N corresponds to 1 / 2pi if the >> >> variable >> >> is angular frequency, but it's been a while since I did that last time. >> >> >> >> - Yu >> >> >> >> NumPy-Discussion mailing list >> > >> >> NumPy-Discussion@ >> > >> >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> > >> > >> > >> > >> > -- >> > Sent from: http://numpy-discussion.10968.n7.nabble.com/ >> > _______________________________________________ >> > NumPy-Discussion mailing list >> >> > NumPy-Discussion@ >> >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> Hello all, >> the discussion on this topic has been stagnant for the past couple of >> weeks, >> so I just wanted to ask if anyone has any alternative names for the new >> normalization option that would like to share. >> >> If not, I'd suggest that we move on with "norm=forward", which seems to >> be a >> more straightforward choice than the "norm=inverse" naming alternative. I >> can wait a couple of days for possible new recommendations to be >> submitted, >> and will then recommit to the open PR to account for the new kwarg name. >> >> In terms of the name for the "norm=ortho" option, I suggest that we keep >> it >> as is for now so that we don't introduce two API changes at once. If >> desired, we can discuss it separately and open a new PR introducing a name >> such as "norm=unitary" or "unit" as recommended in previous messages. I'm >> happy to handle that if you think it'd be a useful change. >> >> Chris >> >> >> >> >> >> -- >> Sent from: http://numpy-discussion.10968.n7.nabble.com/ >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndbecker2 at gmail.com Wed Jun 24 15:29:55 2020 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 24 Jun 2020 15:29:55 -0400 Subject: [Numpy-discussion] reseed random generator (1.19) Message-ID: 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* -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.k.sheppard at gmail.com Wed Jun 24 16:39:00 2020 From: kevin.k.sheppard at gmail.com (Kevin Sheppard) Date: Wed, 24 Jun 2020 21:39:00 +0100 Subject: [Numpy-discussion] reseed random generator (1.19) In-Reply-To: References: Message-ID: Just call rs = default_rng() Again. On Wed, Jun 24, 2020, 20:31 Neal Becker wrote: > 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* > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.nakata.acbs at gmail.com Wed Jun 24 18:11:13 2020 From: christian.nakata.acbs at gmail.com (Christian Nakata) Date: Wed, 24 Jun 2020 19:11:13 -0300 Subject: [Numpy-discussion] About the apply in GSoD Message-ID: Hello members of Numpy Community My name is Christian Takashi Nakata Currently, I'm working with computer vision in my master's degree and your project ideas for the GSoD caught my attention. I've always wanted to work on open source projects, especially in libraries that I usually use. I would like to begin contributing to the Numpy documentation. However, I never worked with open source projects and I wanted to know where I should begin to write a GSoD project proposal. I would like to work with refactoring the current documentation aimed at beginners. For example, in my opinion, the page "NumPy: the absolute basics for beginners" is too verbose. The amount of information on that page can blur useful information from beginner users. The page could be divided into subtopics that jump to other pages, minimizing the amount of information that the user will face for the first time. Together, I intend to create new How Tos so that beginners will find it easier to work with the library. E.g. finishing the "How to read and write data using NumPy" page. Best regards, Christian T. Nakata -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Wed Jun 24 18:38:55 2020 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 24 Jun 2020 18:38:55 -0400 Subject: [Numpy-discussion] reseed random generator (1.19) In-Reply-To: References: Message-ID: On Wed, Jun 24, 2020 at 3:31 PM Neal Becker wrote: > 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. > In general, reseeding an existing generator instance is not a good practice. What effect are you trying to accomplish? I assume that you are asking this because you are currently using `RandomState.seed()`. In what circumstances? The raw `bit_generator.state` property *can* be assigned to, in order to support some advanced use cases (mostly involving de/serialization and similar kinds of meta-programming tasks). It's also been helpful for me to construct worst-case scenarios for testing parallel streams. But it quite deliberately bypasses the notion of deriving the state from a human-friendly seed number. -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From grlee77 at gmail.com Wed Jun 24 18:45:04 2020 From: grlee77 at gmail.com (Gregory Lee) Date: Wed, 24 Jun 2020 18:45:04 -0400 Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) In-Reply-To: References: <1591279296277-0.post@n7.nabble.com> <1591388154629-0.post@n7.nabble.com> <1591670629042-0.post@n7.nabble.com> <1592938084292-0.post@n7.nabble.com> Message-ID: norm='forward' is my preference out of the names suggested so far. The option seems reasonable and should be pretty low maintenance to add. For SciPy, we would probably be willing to make the corresponding changes in the scipy.fft module (but probably not in the outdated scipy.fftpack module). On Wed, Jun 24, 2020 at 1:38 PM Ross Barnowski wrote: > I think it's also important to get the thoughts of the SciPy community on > this topic so that we avoid divergence between numpy.fft and scipy.fft. I > would recommend sending this discussion to the scipy mailing list as well. > > ~Ross > > On Tue, Jun 23, 2020 at 4:11 PM Feng Yu wrote: > >> Your approach sounds good to me. >> >> Thanks, >> >> Yu >> >> On Tue, Jun 23, 2020 at 11:51 AM Chris Vavaliaris < >> cv1038 at wildcats.unh.edu> wrote: >> >>> Chris Vavaliaris wrote >>> > Hello, >>> > >>> > - my first reaction would be that the less argument names we change at >>> a >>> > time the better, so that we don't confuse people or cause codes written >>> > with >>> > previous NumPy versions to break. Personally I always think of "ortho" >>> as >>> > "orthonormal", which immediately brings "unit norm" to mind, but I >>> have no >>> > problem whatsoever with changing its name to "unitary" or maybe "unit", >>> > which I'd probably choose if we were writing the routines from >>> scratch. >>> > >>> > - In terms of the "inverse" name option, I do believe that it'd be a >>> > confusing choice since "inverse" is used to describe the inverse FFT; >>> if >>> > we >>> > choose to stick with a name that's based on the fact that this scaling >>> is >>> > opposite to the "norm=None" option, then I'd suggest "norm=opposite" >>> as a >>> > better choice. However, following Ross' comment, I think we could >>> choose a >>> > name based on the fact that the forward transform is now scaled by `n`, >>> > instead of the backward one as in the default "norm=None". In this >>> case, >>> > I'd >>> > suggest "norm=forward", which we can also nicely abbreviate to the >>> > 4-character form "norm=forw" if desirable. >>> > >>> > Chris >>> > >>> > >>> > Feng Yu wrote >>> >> Hi, >>> >> >>> >> 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as >>> 'unitary'. >>> >> Since we are in general working with complex numbers, I do suggest >>> >> unitary >>> >> over ortho. >>> >> (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) >>> and ( >>> >> >>> https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT >>> ) >>> >> >>> >> 2. I share Chris's concern about 'inverse', but I could not come up >>> with >>> >> a >>> >> nice name. >>> >> >>> >> 3. Now that we are at this, should we also describe the corresponding >>> >> continuum limit of FFT and iFFT in the documentation? >>> >> >>> >> A paragraph doing so could potentially also help people diagnose some >>> of >>> >> the normalization factor errors. I assumed it is common that one >>> needs to >>> >> translate a CFT into DFT when coding a paper up, and the correct >>> >> compensation to the normalization factors will surface if one does the >>> >> math. -- I had the impression 1 / N corresponds to 1 / 2pi if the >>> >> variable >>> >> is angular frequency, but it's been a while since I did that last >>> time. >>> >> >>> >> - Yu >>> >> >>> >> NumPy-Discussion mailing list >>> > >>> >> NumPy-Discussion@ >>> > >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion >>> > >>> > >>> > >>> > >>> > >>> > -- >>> > Sent from: http://numpy-discussion.10968.n7.nabble.com/ >>> > _______________________________________________ >>> > NumPy-Discussion mailing list >>> >>> > NumPy-Discussion@ >>> >>> > https://mail.python.org/mailman/listinfo/numpy-discussion >>> >>> Hello all, >>> the discussion on this topic has been stagnant for the past couple of >>> weeks, >>> so I just wanted to ask if anyone has any alternative names for the new >>> normalization option that would like to share. >>> >>> If not, I'd suggest that we move on with "norm=forward", which seems to >>> be a >>> more straightforward choice than the "norm=inverse" naming alternative. I >>> can wait a couple of days for possible new recommendations to be >>> submitted, >>> and will then recommit to the open PR to account for the new kwarg name. >>> >>> In terms of the name for the "norm=ortho" option, I suggest that we keep >>> it >>> as is for now so that we don't introduce two API changes at once. If >>> desired, we can discuss it separately and open a new PR introducing a >>> name >>> such as "norm=unitary" or "unit" as recommended in previous messages. I'm >>> happy to handle that if you think it'd be a useful change. >>> >>> Chris >>> >>> >>> >>> >>> >>> -- >>> Sent from: http://numpy-discussion.10968.n7.nabble.com/ >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at python.org >>> https://mail.python.org/mailman/listinfo/numpy-discussion >>> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From albuscode at gmail.com Wed Jun 24 20:26:03 2020 From: albuscode at gmail.com (Inessa Pawson) Date: Thu, 25 Jun 2020 10:26:03 +1000 Subject: [Numpy-discussion] new NumPy logo design - cast your vote! Message-ID: One of the most discussed and commented issues in the recent history of NumPy is about to be closed. Don?t forget to cast your vote via reaction on the new NumPy logo design by this Friday, June 26th. Here are the three candidates: https://github.com/numpy/numpy.org/issues/326 https://github.com/numpy/numpy.org/issues/327 https://github.com/numpy/numpy.org/issues/328 For further info please refer to github.com/numpy/numpy.org/issues/37 -- Every good wish, *Inessa Pawson* Albus Code inessa at albuscode.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Thu Jun 25 04:16:36 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 25 Jun 2020 10:16:36 +0200 Subject: [Numpy-discussion] new NumPy logo design - cast your vote! In-Reply-To: References: Message-ID: On Thu, Jun 25, 2020 at 2:27 AM Inessa Pawson wrote: > One of the most discussed and commented issues in the recent history of > NumPy is about to be closed. Don?t forget to cast your vote via reaction on > the new NumPy logo design by this Friday, June 26th. > Thanks Inessa! Here are the three candidates: > https://github.com/numpy/numpy.org/issues/326 > https://github.com/numpy/numpy.org/issues/327 > https://github.com/numpy/numpy.org/issues/328 > > For further info please refer to github.com/numpy/numpy.org/issues/37 > A small addition since that's a super long issue with the relevant info near the end (at https://github.com/numpy/numpy.org/issues/37#issuecomment-645328444): please cast your vote: - if and only if you have contributed to NumPy in the past (any contribution counts, doesn't have to be code - e.g. you helped with fundraising or survey design) - by Saturday 27 June, midnight Eastern Time - by giving a thumbs up to any of the three logos linked above (you can give multiple thumbs-up) Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From melissawm at gmail.com Thu Jun 25 09:03:24 2020 From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=) Date: Thu, 25 Jun 2020 10:03:24 -0300 Subject: [Numpy-discussion] About the apply in GSoD In-Reply-To: References: Message-ID: Hello Christian, Thanks for your interest in our Google Season of Docs projects. It is great to hear from you! If you are interested, I would advise working on the following: - Familiarizing yourself with the NumPy docs and the workflow for building them (https://numpy.org/devdocs/dev/howto-docs.html) - Reading NEP 44 to have an idea of the current vision and focus for the docs (https://numpy.org/neps/nep-0044-restructuring-numpy-docs.html) - Working on your own proposal, so we can analyze it later. You have until July 8 to do this, and if you need help or have questions about any of the above, please get in touch so we can help. Make sure you get in touch with the mentors directly by sending your message to numpy-scipy-gsod at googlegroups.com . Any information you need about the program is in the official GSoD website ( https://developers.google.com/season-of-docs), and in our proposal ( https://github.com/numpy/numpy/wiki/Google-Season-of-Docs-2020-Project-Ideas). Welcome! On Wed, Jun 24, 2020 at 7:12 PM Christian Nakata < christian.nakata.acbs at gmail.com> wrote: > Hello members of Numpy Community > > My name is Christian Takashi Nakata > Currently, I'm working with computer vision in my master's degree and your > project ideas for the GSoD caught my attention. > I've always wanted to work on open source projects, especially in > libraries that I usually use. > > I would like to begin contributing to the Numpy documentation. > However, I never worked with open source projects and I wanted to know > where I should begin to write a GSoD project proposal. > > I would like to work with refactoring the current documentation aimed at > beginners. > For example, in my opinion, the page "NumPy: the absolute basics for > beginners" is too verbose. > The amount of information on that page can blur useful information from > beginner users. > The page could be divided into subtopics that jump to other pages, > minimizing the amount of information that the user will face for the first > time. > > Together, I intend to create new How Tos so that beginners will find it > easier to work with the library. > E.g. finishing the "How to read and write data using NumPy" page. > > Best regards, > Christian T. Nakata > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melissawm at gmail.com Thu Jun 25 09:04:12 2020 From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=) Date: Thu, 25 Jun 2020 10:04:12 -0300 Subject: [Numpy-discussion] About the apply in GSoD In-Reply-To: References: Message-ID: (Oh, and if you need help contributing/submitting pull requests/navigating git, don't hesitate to ask and we'll guide you around!) On Thu, Jun 25, 2020 at 10:03 AM Melissa Mendon?a wrote: > Hello Christian, > > Thanks for your interest in our Google Season of Docs projects. It is > great to hear from you! > > If you are interested, I would advise working on the following: > > - Familiarizing yourself with the NumPy docs and the workflow for building > them (https://numpy.org/devdocs/dev/howto-docs.html) > - Reading NEP 44 to have an idea of the current vision and focus for the > docs (https://numpy.org/neps/nep-0044-restructuring-numpy-docs.html) > - Working on your own proposal, so we can analyze it later. > > You have until July 8 to do this, and if you need help or have questions > about any of the above, please get in touch so we can help. Make sure you > get in touch with the mentors directly by sending your message to > numpy-scipy-gsod at googlegroups.com . Any information you need about the > program is in the official GSoD website ( > https://developers.google.com/season-of-docs), and in our proposal ( > https://github.com/numpy/numpy/wiki/Google-Season-of-Docs-2020-Project-Ideas). > > > Welcome! > > > > On Wed, Jun 24, 2020 at 7:12 PM Christian Nakata < > christian.nakata.acbs at gmail.com> wrote: > >> Hello members of Numpy Community >> >> My name is Christian Takashi Nakata >> Currently, I'm working with computer vision in my master's degree and >> your project ideas for the GSoD caught my attention. >> I've always wanted to work on open source projects, especially in >> libraries that I usually use. >> >> I would like to begin contributing to the Numpy documentation. >> However, I never worked with open source projects and I wanted to know >> where I should begin to write a GSoD project proposal. >> >> I would like to work with refactoring the current documentation aimed at >> beginners. >> For example, in my opinion, the page "NumPy: the absolute basics for >> beginners" is too verbose. >> The amount of information on that page can blur useful information from >> beginner users. >> The page could be divided into subtopics that jump to other pages, >> minimizing the amount of information that the user will face for the first >> time. >> >> Together, I intend to create new How Tos so that beginners will find it >> easier to work with the library. >> E.g. finishing the "How to read and write data using NumPy" page. >> >> Best regards, >> Christian T. Nakata >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sabertooth2022 at gmail.com Thu Jun 25 13:27:42 2020 From: sabertooth2022 at gmail.com (Saber Tooth) Date: Thu, 25 Jun 2020 22:57:42 +0530 Subject: [Numpy-discussion] Google Summer of Docs Faq and Tutorial Proposed Structure . In-Reply-To: References: Message-ID: 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 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&pagesize=15 > 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 @Ralf Gommers > 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_HqJl4/edit?usp=sharing > > > Link to FAQs Proposed structure : > https://docs.google.com/document/d/1q-BYO-GqlBIsMizCzjbANORz6OOaC-6oEzuE1_HqJl4/edit#bookmark=id.2vkitb6djmq0 > > Link to Tutorials Proposed structure : > https://docs.google.com/document/d/1q-BYO-GqlBIsMizCzjbANORz6OOaC-6oEzuE1_HqJl4/edit#bookmark=id.pwfvp3lbd2fx > > Thanks , > Mrinal Tyagi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo80042 at gmail.com Sat Jun 27 00:53:17 2020 From: leo80042 at gmail.com (leofang) Date: Fri, 26 Jun 2020 21:53:17 -0700 (MST) Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) In-Reply-To: References: <1591279296277-0.post@n7.nabble.com> <1591388154629-0.post@n7.nabble.com> <1591670629042-0.post@n7.nabble.com> <1592938084292-0.post@n7.nabble.com> Message-ID: <1593233597029-0.post@n7.nabble.com> Hi all, Since I brought this issue from CuPy to Numpy, I'd like to see a decision made sooner than later so that downstream libraries like SciPy and CuPy can act accordingly. I think norm='forward' is fine. If there're still people unhappy with it after my reply, I'd suggest norm='reverse'. It has the same meaning, but is less confusing (than 'inverse' or other choices on the table) to me. Best, Leo -- Sent from: http://numpy-discussion.10968.n7.nabble.com/ From sebastian at sipsolutions.net Sat Jun 27 10:39:57 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Sat, 27 Jun 2020 09:39:57 -0500 Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) In-Reply-To: <1593233597029-0.post@n7.nabble.com> References: <1591279296277-0.post@n7.nabble.com> <1591388154629-0.post@n7.nabble.com> <1591670629042-0.post@n7.nabble.com> <1592938084292-0.post@n7.nabble.com> <1593233597029-0.post@n7.nabble.com> Message-ID: On Fri, 2020-06-26 at 21:53 -0700, leofang wrote: > Hi all, > > > Since I brought this issue from CuPy to Numpy, I'd like to see a > decision > made sooner than later so that downstream libraries like SciPy and > CuPy can > act accordingly. I think norm='forward' is fine. If there're still > people > unhappy with it after my reply, I'd suggest norm='reverse'. It has > the same > meaning, but is less confusing (than 'inverse' or other choices on > the > table) to me. > I expect "forward" is good (if I misread something please correct me), and I think we can go ahead with it, sorry for the delay. However, I have send an email to scipy-dev, since we should give them at least a heads-up, and if you do not mind, I would wait a few days to actually merge (although we can also simply reverse, as long as CuPy does not have a release with it). It might be nice to expand the kwarg docs slightly with a sentence for each normalization mode? Refering to `np.fft` docs is good, but if we can squeeze in a short refresher and refer there for details/formula it would be nicer. I feel "forward" is very intuitive, but only after pointing out that it is related to whether the fft or ifft has the normalization factor. Cheers, Sebastian > > Best, > Leo > > > > -- > Sent from: http://numpy-discussion.10968.n7.nabble.com/ > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rakesh.nvasudev at gmail.com Sat Jun 27 19:08:25 2020 From: rakesh.nvasudev at gmail.com (Rakesh Vasudevan) Date: Sat, 27 Jun 2020 16:08:25 -0700 Subject: [Numpy-discussion] Improving Complex Comparison/Ordering in Numpy In-Reply-To: References: Message-ID: Hi all, Following up on this. Created a WIP PR https://github.com/numpy/numpy/pull/16700 As stated in the original thread, We need to start by having a sort() function for complex numbers that can do it based on keys, rather than plain arithmetic ordering. There are two broad ways to approach a sorting function that supports keys (Not just for complex numbers). 1. Add a key kwarg to the sort() (function and method). To support key based sorting on arrays. 2. Use a new function on the lines off sortby(c_arr, key=(c_arr.real, c_arr.imag) In this PR I have chosen approach 1 for the following reasons 1. Approach 1 means it is easier to deal with both in-place method and the function. Since we can make the change in the c-sort function, we have minimal change in the python layer. This I hope results, minimal impact on current code that handles complex sorting. One example within numpy is is linalg module's svd() function. 2. With approach 2 when we deprecate complex arithmetic ordering, existing methods using sort() for complex types, need to update their signature. As it stands the PR does the following 3 things within the Python-C Array method implementation of sort 1. Checks for complex type- If array is of complex-type, it creates a default key(When no key is passed) which mimics the current arithmetic ordering in Numpy . 2. Uses the keys to perform a Py_LexSort and generate indices. 3. We perform the take_along_axis via C call back and copy over the result to the original array (pseudo in-place). I am requesting feedback/help on implementing take_along_axis logic in C level in an in-place manner and the approach in general. This will further feed into max() and min() as well. Once we figure this out. Next step would be to deprecate arithmetic ordering for complex types (Which I think will be a PR on it's own) Regards Rakesh On Thu, Jun 4, 2020 at 9:21 PM Brock Mendel wrote: > Corresponding pandas issue: > https://github.com/pandas-dev/pandas/issues/28050 > > On Thu, Jun 4, 2020 at 9:17 PM Rakesh Vasudevan > wrote: > >> Hi all, >> >> As a follow up to gh-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 "", line 1, in >> 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 >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndbecker2 at gmail.com Sun Jun 28 15:36:51 2020 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 28 Jun 2020 15:36:51 -0400 Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) In-Reply-To: References: <1591279296277-0.post@n7.nabble.com> <1591388154629-0.post@n7.nabble.com> <1591670629042-0.post@n7.nabble.com> <1592938084292-0.post@n7.nabble.com> <1593233597029-0.post@n7.nabble.com> Message-ID: Honestly, I don't find "forward" very informative. There isn't any real convention on whether FFT of IFFT have any normalization. To the best of my experience, either forward or inverse could be normalized by 1/N, or each normalized by 1/sqrt(N), or neither could be normalized. I will say my expertise is in signal processing and communications. Perhaps norm = {full, half, none} would be clearest to me. Thanks, Neal On Sat, Jun 27, 2020 at 10:40 AM Sebastian Berg wrote: > On Fri, 2020-06-26 at 21:53 -0700, leofang wrote: > > Hi all, > > > > > > Since I brought this issue from CuPy to Numpy, I'd like to see a > > decision > > made sooner than later so that downstream libraries like SciPy and > > CuPy can > > act accordingly. I think norm='forward' is fine. If there're still > > people > > unhappy with it after my reply, I'd suggest norm='reverse'. It has > > the same > > meaning, but is less confusing (than 'inverse' or other choices on > > the > > table) to me. > > > > I expect "forward" is good (if I misread something please correct me), > and I think we can go ahead with it, sorry for the delay. However, I > have send an email to scipy-dev, since we should give them at least a > heads-up, and if you do not mind, I would wait a few days to actually > merge (although we can also simply reverse, as long as CuPy does not > have a release with it). > > It might be nice to expand the kwarg docs slightly with a sentence for > each normalization mode? Refering to `np.fft` docs is good, but if we > can squeeze in a short refresher and refer there for details/formula it > would be nicer. > I feel "forward" is very intuitive, but only after pointing out that it > is related to whether the fft or ifft has the normalization factor. > > Cheers, > > Sebastian > > > > > > Best, > > Leo > > > > > > > > -- > > Sent from: http://numpy-discussion.10968.n7.nabble.com/ > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -- *Those who don't understand recursion are doomed to repeat it* -------------- next part -------------- An HTML attachment was scrubbed... URL: From deak.andris at gmail.com Sun Jun 28 18:14:39 2020 From: deak.andris at gmail.com (Andras Deak) Date: Mon, 29 Jun 2020 00:14:39 +0200 Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) In-Reply-To: References: <1591279296277-0.post@n7.nabble.com> <1591388154629-0.post@n7.nabble.com> <1591670629042-0.post@n7.nabble.com> <1592938084292-0.post@n7.nabble.com> <1593233597029-0.post@n7.nabble.com> Message-ID: On Sun, Jun 28, 2020 at 9:37 PM Neal Becker wrote: > > Honestly, I don't find "forward" very informative. There isn't any real convention on whether FFT of IFFT have any normalization. > To the best of my experience, either forward or inverse could be normalized by 1/N, or each normalized by 1/sqrt(N), or neither > could be normalized. I will say my expertise is in signal processing and communications. > > Perhaps > norm = {full, half, none} would be clearest to me. If I understand your point correctly and the discussion so far, the intention here is to use the keyword to denote the convention for an FFT-IFFT pair rather than just normalization in a single transformation (either FFT or IFFT). The idea being that calling ifft on the output of fft while using the same `norm` would be more or less identity. This would work for "half", but not for, say, "full". We need to come up with a name that specifies where normalization happens with regards to the forward-inverse pair. Does this make sense, considering your point? Andr?s > > Thanks, > Neal > > On Sat, Jun 27, 2020 at 10:40 AM Sebastian Berg wrote: >> >> On Fri, 2020-06-26 at 21:53 -0700, leofang wrote: >> > Hi all, >> > >> > >> > Since I brought this issue from CuPy to Numpy, I'd like to see a >> > decision >> > made sooner than later so that downstream libraries like SciPy and >> > CuPy can >> > act accordingly. I think norm='forward' is fine. If there're still >> > people >> > unhappy with it after my reply, I'd suggest norm='reverse'. It has >> > the same >> > meaning, but is less confusing (than 'inverse' or other choices on >> > the >> > table) to me. >> > >> >> I expect "forward" is good (if I misread something please correct me), >> and I think we can go ahead with it, sorry for the delay. However, I >> have send an email to scipy-dev, since we should give them at least a >> heads-up, and if you do not mind, I would wait a few days to actually >> merge (although we can also simply reverse, as long as CuPy does not >> have a release with it). >> >> It might be nice to expand the kwarg docs slightly with a sentence for >> each normalization mode? Refering to `np.fft` docs is good, but if we >> can squeeze in a short refresher and refer there for details/formula it >> would be nicer. >> I feel "forward" is very intuitive, but only after pointing out that it >> is related to whether the fft or ifft has the normalization factor. >> >> Cheers, >> >> Sebastian >> >> >> > >> > Best, >> > Leo >> > >> > >> > >> > -- >> > Sent from: http://numpy-discussion.10968.n7.nabble.com/ >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion at python.org >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion > > > > -- > Those who don't understand recursion are doomed to repeat it > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion From peterbell10 at live.co.uk Sun Jun 28 21:59:19 2020 From: peterbell10 at live.co.uk (Peter Bell) Date: Mon, 29 Jun 2020 01:59:19 +0000 Subject: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option) In-Reply-To: References: <1591279296277-0.post@n7.nabble.com> <1591388154629-0.post@n7.nabble.com> <1591670629042-0.post@n7.nabble.com> <1592938084292-0.post@n7.nabble.com> <1593233597029-0.post@n7.nabble.com> , Message-ID: >> Honestly, I don't find "forward" very informative. There isn't any real convention on whether FFT of IFFT have any normalization. >> To the best of my experience, either forward or inverse could be normalized by 1/N, or each normalized by 1/sqrt(N), or neither >> could be normalized. I will say my expertise is in signal processing and communications. >> >> Perhaps >> norm = {full, half, none} would be clearest to me. >If I understand your point correctly and the discussion so far, the >intention here is to use the keyword to denote the convention for an >FFT-IFFT pair rather than just normalization in a single >transformation (either FFT or IFFT). >The idea being that calling ifft on the output of fft while using the >same `norm` would be more or less identity. This would work for >"half", but not for, say, "full". We need to come up with a name that >specifies where normalization happens with regards to the >forward-inverse pair. For what it's worth, I'm not sure that norm referring to a pair of transforms was ever a conscious decision. The numpy issue that first proposed the norm argument was gh-2142 which references scipy.fftpack's discrete cosine transforms. However, fftpack's dct never applied a 1/N normalization factor in either direction. So, norm=None really did mean "no normalization". It was then carried over to NumPy with None instead meaning "default normalization". Unfortunately, this means norm=None could easily be mistaken for "no normalization", and would make accepting norm="none" terribly confusing. To break this confusion, I think the documentation should refer to norm={"backward", "ortho", "forward"} where "backward" is a synonym for norm=None. As an aside, the history with the dct makes it clear the choice was "ortho" and not "unitary" because the dct is a real transform. -Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndbecker2 at gmail.com Mon Jun 29 08:00:23 2020 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 29 Jun 2020 08:00:23 -0400 Subject: [Numpy-discussion] reseed random generator (1.19) In-Reply-To: References: Message-ID: I was using this to reset the generator, in order to repeat the same sequence again for testing purposes. On Wed, Jun 24, 2020 at 6:40 PM Robert Kern wrote: > On Wed, Jun 24, 2020 at 3:31 PM Neal Becker wrote: > >> 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. >> > > In general, reseeding an existing generator instance is not a good > practice. What effect are you trying to accomplish? I assume that you are > asking this because you are currently using `RandomState.seed()`. In what > circumstances? > > The raw `bit_generator.state` property *can* be assigned to, in order to > support some advanced use cases (mostly involving de/serialization and > similar kinds of meta-programming tasks). It's also been helpful for me to > construct worst-case scenarios for testing parallel streams. But it quite > deliberately bypasses the notion of deriving the state from a > human-friendly seed number. > > -- > Robert Kern > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -- *Those who don't understand recursion are doomed to repeat it* -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.k.sheppard at gmail.com Mon Jun 29 08:20:29 2020 From: kevin.k.sheppard at gmail.com (Kevin Sheppard) Date: Mon, 29 Jun 2020 13:20:29 +0100 Subject: [Numpy-discussion] reseed random generator (1.19) In-Reply-To: References: , Message-ID: <2C4AB2E0-D641-4AF8-B2F2-C959F133D483@hxcore.ol> An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Mon Jun 29 09:20:18 2020 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Mon, 29 Jun 2020 16:20:18 +0300 Subject: [Numpy-discussion] reseed random generator (1.19) In-Reply-To: <2C4AB2E0-D641-4AF8-B2F2-C959F133D483@hxcore.ol> References: <2C4AB2E0-D641-4AF8-B2F2-C959F133D483@hxcore.ol> Message-ID: (apologies for jumping into a conversation) So what is the recommendation for instantiating a number of generators with manually controlled seeds? The use case is running a series of MC simulations with reproducible streams. The runs are independent and are run in parallel in separate OS processes, where I do not control the time each process starts (jobs are submitted to the batch queue), so default seeding seems dubious? Previously, I would just do roughly seeds = [1234, 1235, 1236, ...] rngs = [np.random.RandomState(seed) for seed in seeds] ... and each process operates with its own `rng`. What would be the recommended way with the new `Generator` framework? A human-friendly way would be preferable if possible. Thanks, Evgeni On Mon, Jun 29, 2020 at 3:20 PM Kevin Sheppard wrote: > > If you want to use the same entropy-initialized generator for temporarily-reproducible experiments, then you can use > > > > gen = np.random.default_rng() > > state = gen.bit_generator.state > > gen.standard_normal() > > # 0.5644742559549797, will vary across runs > > gen.bit_generator.state = state > > gen.standard_normal() > > # Always the same as before 0.5644742559549797 > > > > The equivalent to the old way of calling seed to reseed is: > > > > SEED = 918273645 > > gen = np.random.default_rng(SEED) > > gen.standard_normal() > > # 0.12345677 > > gen = np.random.default_rng(SEED) > > gen.standard_normal() > > # Identical value > > > > Rather than reseeding the same object, you just create a new object. At some point in the development of Generator both methods were timed and there was no performance to reusing the same object by reseeding. > > > > Kevin > > > > > > > > From: Neal Becker > Sent: Monday, June 29, 2020 1:01 PM > To: Discussion of Numerical Python > Subject: Re: [Numpy-discussion] reseed random generator (1.19) > > > > I was using this to reset the generator, in order to repeat the same sequence again for testing purposes. > > > > On Wed, Jun 24, 2020 at 6:40 PM Robert Kern wrote: > > On Wed, Jun 24, 2020 at 3:31 PM Neal Becker wrote: > > 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. > > > > In general, reseeding an existing generator instance is not a good practice. What effect are you trying to accomplish? I assume that you are asking this because you are currently using `RandomState.seed()`. In what circumstances? > > > > The raw `bit_generator.state` property *can* be assigned to, in order to support some advanced use cases (mostly involving de/serialization and similar kinds of meta-programming tasks). It's also been helpful for me to construct worst-case scenarios for testing parallel streams. But it quite deliberately bypasses the notion of deriving the state from a human-friendly seed number. > > > > -- > > Robert Kern > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > -- > > Those who don't understand recursion are doomed to repeat it > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion From kevin.k.sheppard at gmail.com Mon Jun 29 10:37:30 2020 From: kevin.k.sheppard at gmail.com (Kevin Sheppard) Date: Mon, 29 Jun 2020 15:37:30 +0100 Subject: [Numpy-discussion] reseed random generator (1.19) In-Reply-To: References: <2C4AB2E0-D641-4AF8-B2F2-C959F133D483@hxcore.ol>, Message-ID: An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Mon Jun 29 10:42:48 2020 From: matti.picus at gmail.com (Matti Picus) Date: Mon, 29 Jun 2020 17:42:48 +0300 Subject: [Numpy-discussion] reseed random generator (1.19) In-Reply-To: References: <2C4AB2E0-D641-4AF8-B2F2-C959F133D483@hxcore.ol> Message-ID: <126d8f74-55bd-ce73-f34e-a42a8eac86e5@gmail.com> An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Mon Jun 29 10:51:23 2020 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 29 Jun 2020 10:51:23 -0400 Subject: [Numpy-discussion] reseed random generator (1.19) In-Reply-To: References: Message-ID: On Mon, Jun 29, 2020 at 8:02 AM Neal Becker wrote: > I was using this to reset the generator, in order to repeat the same > sequence again for testing purposes. > In general, you should just pass in a new Generator that was created with the same seed. def function_to_test(rg): x = rg.standard_normal() ... SEED = 12345... rg = np.random.default_rng(SEED) function_to_test(rg) rg = npp.random.default_rng(SEED) function_to_test(rg) Resetting the state of the underlying BitGenerator in-place is possible, as Kevin showed, but if you can refactor your code so that there isn't a persistent Generator object between these runs, that's probably better. It's a code smell if you can't just pass in a fresh Generator; in general, it means that your code is harder to use, not just because we don't expose an in-place seed() method. -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Mon Jun 29 11:00:54 2020 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Mon, 29 Jun 2020 18:00:54 +0300 Subject: [Numpy-discussion] reseed random generator (1.19) In-Reply-To: References: <2C4AB2E0-D641-4AF8-B2F2-C959F133D483@hxcore.ol> Message-ID: Thanks Kevin! A possibly dumb follow-up question: in your example, > entropy = 382193877439745928479635728 is it relevant that `entropy` is a long integer? I.e., what are the constraints on its value, can one use entropy = 1234 or entropy = 0 or entropy = 1 instead? On Mon, Jun 29, 2020 at 5:37 PM Kevin Sheppard wrote: > > The best practice is to use a SeedSequence to spawn child SeedSequences, and then to use these children to initialize your generators or bit generators. > > > > > > from numpy.random import SeedSequence, Generator, PCG64, default_rng > > > > entropy = 382193877439745928479635728 > > > > seed_seq = SeedSequence(entropy) > > NUM_STREAMS = 2**15 > > children = seed_seq.spawn(NUM_STREAMS) > > # if you want the current best bit generator, which may change > > rngs = [default_rng(child) for child in children] > > # If you want the most control across version, set the bit generator > > # this uses PCG64, which is the current default. Each bit generator needs to be wrapped in a generator > > rngs = [Generator(PCG64(child)) for child in children] > > > > Kevin > > > > > > From: Evgeni Burovski > Sent: Monday, June 29, 2020 2:21 PM > To: Discussion of Numerical Python > Subject: Re: [Numpy-discussion] reseed random generator (1.19) > > > > (apologies for jumping into a conversation) > > So what is the recommendation for instantiating a number of generators > > with manually controlled seeds? > > > > The use case is running a series of MC simulations with reproducible > > streams. The runs are independent and are run in parallel in separate > > OS processes, where I do not control the time each process starts > > (jobs are submitted to the batch queue), so default seeding seems > > dubious? > > > > Previously, I would just do roughly > > > > seeds = [1234, 1235, 1236, ...] > > rngs = [np.random.RandomState(seed) for seed in seeds] > > ... > > and each process operates with its own `rng`. > > What would be the recommended way with the new `Generator` framework? > > A human-friendly way would be preferable if possible. > > > > Thanks, > > > > Evgeni > > > > > > On Mon, Jun 29, 2020 at 3:20 PM Kevin Sheppard > > wrote: > > > > > > If you want to use the same entropy-initialized generator for temporarily-reproducible experiments, then you can use > > > > > > > > > > > > gen = np.random.default_rng() > > > > > > state = gen.bit_generator.state > > > > > > gen.standard_normal() > > > > > > # 0.5644742559549797, will vary across runs > > > > > > gen.bit_generator.state = state > > > > > > gen.standard_normal() > > > > > > # Always the same as before 0.5644742559549797 > > > > > > > > > > > > The equivalent to the old way of calling seed to reseed is: > > > > > > > > > > > > SEED = 918273645 > > > > > > gen = np.random.default_rng(SEED) > > > > > > gen.standard_normal() > > > > > > # 0.12345677 > > > > > > gen = np.random.default_rng(SEED) > > > > > > gen.standard_normal() > > > > > > # Identical value > > > > > > > > > > > > Rather than reseeding the same object, you just create a new object. At some point in the development of Generator both methods were timed and there was no performance to reusing the same object by reseeding. > > > > > > > > > > > > Kevin > > > > > > > > > > > > > > > > > > > > > > > > From: Neal Becker > > > Sent: Monday, June 29, 2020 1:01 PM > > > To: Discussion of Numerical Python > > > Subject: Re: [Numpy-discussion] reseed random generator (1.19) > > > > > > > > > > > > I was using this to reset the generator, in order to repeat the same sequence again for testing purposes. > > > > > > > > > > > > On Wed, Jun 24, 2020 at 6:40 PM Robert Kern wrote: > > > > > > On Wed, Jun 24, 2020 at 3:31 PM Neal Becker wrote: > > > > > > 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. > > > > > > > > > > > > In general, reseeding an existing generator instance is not a good practice. What effect are you trying to accomplish? I assume that you are asking this because you are currently using `RandomState.seed()`. In what circumstances? > > > > > > > > > > > > The raw `bit_generator.state` property *can* be assigned to, in order to support some advanced use cases (mostly involving de/serialization and similar kinds of meta-programming tasks). It's also been helpful for me to construct worst-case scenarios for testing parallel streams. But it quite deliberately bypasses the notion of deriving the state from a human-friendly seed number. > > > > > > > > > > > > -- > > > > > > Robert Kern > > > > > > _______________________________________________ > > > NumPy-Discussion mailing list > > > NumPy-Discussion at python.org > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > > > > > > > > > -- > > > > > > Those who don't understand recursion are doomed to repeat it > > > > > > > > > > > > _______________________________________________ > > > NumPy-Discussion mailing list > > > NumPy-Discussion at python.org > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion From kevin.k.sheppard at gmail.com Mon Jun 29 11:09:07 2020 From: kevin.k.sheppard at gmail.com (Kevin Sheppard) Date: Mon, 29 Jun 2020 16:09:07 +0100 Subject: [Numpy-discussion] reseed random generator (1.19) In-Reply-To: References: <2C4AB2E0-D641-4AF8-B2F2-C959F133D483@hxcore.ol> , Message-ID: <53BDD45B-693A-42DA-9165-DDF79A75B3D7@hxcore.ol> An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Mon Jun 29 11:30:00 2020 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 29 Jun 2020 11:30:00 -0400 Subject: [Numpy-discussion] reseed random generator (1.19) In-Reply-To: <53BDD45B-693A-42DA-9165-DDF79A75B3D7@hxcore.ol> References: <2C4AB2E0-D641-4AF8-B2F2-C959F133D483@hxcore.ol> <53BDD45B-693A-42DA-9165-DDF79A75B3D7@hxcore.ol> Message-ID: On Mon, Jun 29, 2020 at 11:10 AM Kevin Sheppard wrote: > It can be anything, but ?good practice? is to use a number that would have > 2 properties: > > > > 1. When expressed as binary number, it would have a large number of > both 0s and 1s > > The properties of the SeedSequence algorithm render this irrelevant, fortunately. While there are seed numbers that might create "bad" outputs from SeedSequence with overly low or high Hamming weight (number of 1s), they are scattered around the input space so you have to adversarially reverse the SeedSequence algorithm to find them. IMO, the only reason to avoid seed numbers like this has more to do with the fact that there are a relatively small number of these seeds. If you are deliberately picking from that small set somehow, it's more likely that other researchers are too, and you are more likely to reuse that same seed. > > 1. The total number of digits in the binary representation is > somewhere between 32 and 128. > > I like using the standard library `secrets` module. >>> import secrets >>> secrets.randbelow(1<<128) 8080125189471896523368405732926911908 If you want an easy-to-follow rule, just use the above snippet to get a 128-bit number. More than 128 bits won't do you any good (at least by default, the internal bottleneck inside of SeedSequence is a 128-bit pool), and 128-bit numbers are just about small enough to copy-paste comfortably. We have thought about wrapping that up in a numpy.random function (e.g. `np.random.simple_seed()` or something like that) for convenience, but we wanted to wait a bit before commiting to an API. -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Mon Jun 29 16:05:57 2020 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 29 Jun 2020 16:05:57 -0400 Subject: [Numpy-discussion] reseed random generator (1.19) In-Reply-To: References: <2C4AB2E0-D641-4AF8-B2F2-C959F133D483@hxcore.ol> <53BDD45B-693A-42DA-9165-DDF79A75B3D7@hxcore.ol> Message-ID: On Mon, Jun 29, 2020 at 11:30 AM Robert Kern wrote: > On Mon, Jun 29, 2020 at 11:10 AM Kevin Sheppard < > kevin.k.sheppard at gmail.com> wrote: > >> >> 1. The total number of digits in the binary representation is >> somewhere between 32 and 128. >> >> > I like using the standard library `secrets` module. > > >>> import secrets > >>> secrets.randbelow(1<<128) > 8080125189471896523368405732926911908 > > If you want an easy-to-follow rule, just use the above snippet to get a > 128-bit number. More than 128 bits won't do you any good (at least by > default, the internal bottleneck inside of SeedSequence is a 128-bit pool), > and 128-bit numbers are just about small enough to copy-paste comfortably. > Sorry, `secrets.randbits(128)` is the cleaner form of this. -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From cimrman3 at ntc.zcu.cz Tue Jun 30 05:31:02 2020 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Tue, 30 Jun 2020 11:31:02 +0200 Subject: [Numpy-discussion] ANN: SfePy 2020.2 Message-ID: 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 From sebastian at sipsolutions.net Tue Jun 30 19:45:56 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 30 Jun 2020 18:45:56 -0500 Subject: [Numpy-discussion] NumPy Development Meeting Tomorrow - Triage Focus Message-ID: <1a1a203104bdd03485efbe7d4634edd51472a1f8.camel@sipsolutions.net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: