From numpy_gsod at bigriver.xyz  Fri May  1 08:52:31 2020
From: numpy_gsod at bigriver.xyz (Ben Nathanson)
Date: Fri, 1 May 2020 08:52:31 -0400
Subject: [Numpy-discussion] Season of Docs technical writer
Message-ID: <CAA7-tfjW8_UWXx=JZ21SB=ZnpvhAZnFoKegm2AT_nEzp5SQWag@mail.gmail.com>

I've updated my page (https://bennathanson.com/numpy2020) to include a
section on Curation and Adaptation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200501/91525011/attachment.html>

From stefanv at berkeley.edu  Fri May  1 09:08:31 2020
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Fri, 01 May 2020 06:08:31 -0700
Subject: [Numpy-discussion] Season of Docs technical writer
In-Reply-To: <CAA7-tfjW8_UWXx=JZ21SB=ZnpvhAZnFoKegm2AT_nEzp5SQWag@mail.gmail.com>
References: <CAA7-tfjW8_UWXx=JZ21SB=ZnpvhAZnFoKegm2AT_nEzp5SQWag@mail.gmail.com>
Message-ID: <c965eeb2-b87c-40b4-933e-7e9f1bd3e035@www.fastmail.com>

Hi Ben,

On Fri, May 1, 2020, at 05:52, Ben Nathanson wrote:
> I've updated my page (https://bennathanson.com/numpy2020) to include a section on Curation and Adaptation.

I enjoyed reading your page, and appreciate the wit sprinkled through your writing. I look forward to working with you this season!

Best regards,
St?fan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200501/359fd410/attachment-0001.html>

From oberoi011115tina at gmail.com  Fri May  1 11:52:08 2020
From: oberoi011115tina at gmail.com (Tina Oberoi)
Date: Fri, 1 May 2020 21:22:08 +0530
Subject: [Numpy-discussion] Closing resolved good-first-issues
Message-ID: <CAM2id8y+iLUhiLe50CoW6kVhF4s3PCi02Hr4y+Bu_CqMtj5QXw@mail.gmail.com>

Hi all,

I observed that there are many good-first-issues that are resolved but yet
open. It would be a great help for new contributors if we could close them
and label new good-first-issues (if not labelled already).

Thanks and Regards
Tina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200501/efc9eb87/attachment.html>

From ralf.gommers at gmail.com  Fri May  1 12:05:14 2020
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Fri, 1 May 2020 18:05:14 +0200
Subject: [Numpy-discussion] Closing resolved good-first-issues
In-Reply-To: <CAM2id8y+iLUhiLe50CoW6kVhF4s3PCi02Hr4y+Bu_CqMtj5QXw@mail.gmail.com>
References: <CAM2id8y+iLUhiLe50CoW6kVhF4s3PCi02Hr4y+Bu_CqMtj5QXw@mail.gmail.com>
Message-ID: <CABL7CQjRftPHwRNtt2GqcOcRm7=+nxvbgmY9VRAoyLPh=uYYKQ@mail.gmail.com>

On Fri, May 1, 2020 at 5:53 PM Tina Oberoi <oberoi011115tina at gmail.com>
wrote:

> Hi all,
>
> I observed that there are many good-first-issues that are resolved but yet
> open. It would be a great help for new contributors if we could close them
> and label new good-first-issues (if not labelled already).
>

Hi Tina, thanks for pointing that out. I have added you to the triage team,
so you are able to close issues that you already noticed are fixed. I'll
have a look at labelling some new ones now.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200501/4ff05753/attachment.html>

From anirudh2290 at gmail.com  Fri May  1 16:58:33 2020
From: anirudh2290 at gmail.com (Anirudh Subramanian)
Date: Fri, 1 May 2020 13:58:33 -0700
Subject: [Numpy-discussion] Deprecate inexact matches for mode, order etc ?
Message-ID: <CAFVLAA-K0sEzD+9N4diTydnKRC_b_CJ-ZgM=npRJEY2vNH9=5A@mail.gmail.com>

Hi all,

I added a proposal to deprecate inexact and case insensitive matches for
mode, order, searchside and sortkind. in
https://github.com/numpy/numpy/pull/16056 , and this stemmed from a
discussion started in
https://github.com/numpy/numpy/pull/16007#discussion_r410517462

Currently, numpy allows :
np.ravel_multi_index(arr, (7, 6), mode='Clip')
np.ravel_multi_index(arr, (7, 6), mode='C')
np.ravel_multi_index(arr, (7, 6), mode='cat')

We have a similar story for order, searchside and sortkind. After the
change, all non exact and case insensitive matches will give a
deprecationwarning i.e. only exact matches for mode('clip', 'wrap' and
'raise'), order('C', 'F', 'A', 'K'), searchside ('left', 'right') and
sortkind ('merge', 'heap', 'stable', 'quick') will be valid.

The PR also includes 'byteorder' but i am not too sure about this since
(as pointed out in the PR) sys.byteorder uses 'big', 'little' etc. while
the numpy documentation uses single capital character to indicate byteorder
('S', 'L?, 'B', 'N', 'I').

Anirudh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200501/a1919bb8/attachment.html>

From sebastian at sipsolutions.net  Sat May  2 14:41:43 2020
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Sat, 02 May 2020 13:41:43 -0500
Subject: [Numpy-discussion] Deprecate inexact matches for mode,
 order etc ?
In-Reply-To: <CAFVLAA-K0sEzD+9N4diTydnKRC_b_CJ-ZgM=npRJEY2vNH9=5A@mail.gmail.com>
References: <CAFVLAA-K0sEzD+9N4diTydnKRC_b_CJ-ZgM=npRJEY2vNH9=5A@mail.gmail.com>
Message-ID: <05689fe281648192fdea7987871b14ab225d9167.camel@sipsolutions.net>

On Fri, 2020-05-01 at 13:58 -0700, Anirudh Subramanian wrote:
> Hi all,
> 
> I added a proposal to deprecate inexact and case insensitive matches
> for
> mode, order, searchside and sortkind. in
> https://github.com/numpy/numpy/pull/16056 , and this stemmed from a
> discussion started in
> https://github.com/numpy/numpy/pull/16007#discussion_r410517462
> 
> Currently, numpy allows :
> np.ravel_multi_index(arr, (7, 6), mode='Clip')
> np.ravel_multi_index(arr, (7, 6), mode='C')
> np.ravel_multi_index(arr, (7, 6), mode='cat')
> 
> We have a similar story for order, searchside and sortkind. After the
> change, all non exact and case insensitive matches will give a
> deprecationwarning i.e. only exact matches for mode('clip', 'wrap'
> and
> 'raise'), order('C', 'F', 'A', 'K'), searchside ('left', 'right') and
> sortkind ('merge', 'heap', 'stable', 'quick') will be valid.
> 
> The PR also includes 'byteorder' but i am not too sure about this
> since
> (as pointed out in the PR) sys.byteorder uses 'big', 'little' etc.
> while
> the numpy documentation uses single capital character to indicate
> byteorder
> ('S', 'L?, 'B', 'N', 'I').


Thanks for working on this.

For the byteorder, maybe we should just allow both for now? SciPy uses
"S" once, that is the default though. `=`, `>`, `<` (or "native", etc.)
are much nicer than `N`, `B`, `L` anyway, because that is what we
print. (I am not sure that `I`, which is also spelled `|`, has a useful
meaning as an argument to be honest.)

I think I would prefer allowing all of `>`, `B`, and `big`. But change
the documentation to not mention the single letter `B`. And some future
people/us can think about deprecating them in a few years...

In any case, I am absolutely +1 but would be very happy to e.g. keep
allowing single letter abbreviations if anyone thinks that they are
occasionally used out there.

Cheers,

Sebastian


> 
> Anirudh
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion



From ralf.gommers at gmail.com  Sat May  2 16:14:44 2020
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 2 May 2020 22:14:44 +0200
Subject: [Numpy-discussion] Update the Code of Conduct Committee
 Membership (new members wanted)
In-Reply-To: <6ca65ab6bb3c75184a053ec0ec0831ed4ff77fa3.camel@sipsolutions.net>
References: <6ca65ab6bb3c75184a053ec0ec0831ed4ff77fa3.camel@sipsolutions.net>
Message-ID: <CABL7CQgvyJLzq6gxuSN5mMj-hiocyKZUssvbPiQZMPXgrw71nQ@mail.gmail.com>

On Thu, Apr 23, 2020 at 11:38 PM Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> Hi all,
>
> it has come up in the last community call that many of our committee
> membership lists have not been updated in a while.
> This is not a big issue as such.  But, while these committees are not
> very active on a day-to-day basis, they are an important part of the
> community and it is better to update them regularly and thus also
> ensure they remain representative of the community.
>

Thanks Sebastian!


> We would like to start by updating the members of the Code of Conduct
> (CoC) committee.  The CoC committee is in charge of responding and
> following up to any reports of CoC breaches, as stated in:
>
>
> https://docs.scipy.org/doc/numpy/dev/conduct/code_of_conduct.html#incident-reporting-resolution-code-of-conduct-enforcement
>
> If you are interested in or happy to serve on our CoC committee please
> let me or e.g. Ralf Gommers know, join the next community meeting
> (April 29th, 11:00PDT/18:00UTC), or reply on the list.
>
> I hope we will be able to discuss and reach a consensus between those
> interested and involved quickly (possibly already on the next community
> call).  In either case, before any changes they will be run by the
> mailing list to ensure community consensus.
>

Following up on this: Melissa and Anirudh both volunteered for this (thank
you!), and in the last community call we discussed this (thumbs up from
everyone there), and gave me the assignment to follow up on this list.

Both Melissa and Anirudh have experience with CoC's, Melissa for the SciPy
conference and Anirudh in the MXNet community. They're also two of the most
active current contributors. So it will be great to have them on the
committee.

We also discussed that it would be good to have at least one current member
remain, to have one steering council member who knows the project history
well on the committee. Both Stefan and I have said that we're happy to stay
on. So I would suggest that Stefan and I get together and figure out who of
us that will be. And then we update the website and the CoC committee's
private email list.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200502/37615953/attachment.html>

From warren.weckesser at gmail.com  Sat May  2 16:22:35 2020
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Sat, 2 May 2020 16:22:35 -0400
Subject: [Numpy-discussion] Update the Code of Conduct Committee
 Membership (new members wanted)
In-Reply-To: <CABL7CQgvyJLzq6gxuSN5mMj-hiocyKZUssvbPiQZMPXgrw71nQ@mail.gmail.com>
References: <6ca65ab6bb3c75184a053ec0ec0831ed4ff77fa3.camel@sipsolutions.net>
 <CABL7CQgvyJLzq6gxuSN5mMj-hiocyKZUssvbPiQZMPXgrw71nQ@mail.gmail.com>
Message-ID: <CAGzF1ueomYE7HAnfBme-qjnARFfK1nPFpYT6pDi4tejhGX=ZcA@mail.gmail.com>

On 5/2/20, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> On Thu, Apr 23, 2020 at 11:38 PM Sebastian Berg
> <sebastian at sipsolutions.net>
> wrote:
>
>> Hi all,
>>
>> it has come up in the last community call that many of our committee
>> membership lists have not been updated in a while.
>> This is not a big issue as such.  But, while these committees are not
>> very active on a day-to-day basis, they are an important part of the
>> community and it is better to update them regularly and thus also
>> ensure they remain representative of the community.
>>
>
> Thanks Sebastian!
>
>
>> We would like to start by updating the members of the Code of Conduct
>> (CoC) committee.  The CoC committee is in charge of responding and
>> following up to any reports of CoC breaches, as stated in:
>>
>>
>> https://docs.scipy.org/doc/numpy/dev/conduct/code_of_conduct.html#incident-reporting-resolution-code-of-conduct-enforcement
>>
>> If you are interested in or happy to serve on our CoC committee please
>> let me or e.g. Ralf Gommers know, join the next community meeting
>> (April 29th, 11:00PDT/18:00UTC), or reply on the list.
>>
>> I hope we will be able to discuss and reach a consensus between those
>> interested and involved quickly (possibly already on the next community
>> call).  In either case, before any changes they will be run by the
>> mailing list to ensure community consensus.
>>
>
> Following up on this: Melissa and Anirudh both volunteered for this (thank
> you!), and in the last community call we discussed this (thumbs up from
> everyone there), and gave me the assignment to follow up on this list.
>
> Both Melissa and Anirudh have experience with CoC's, Melissa for the SciPy
> conference and Anirudh in the MXNet community. They're also two of the most
> active current contributors. So it will be great to have them on the
> committee.
>
> We also discussed that it would be good to have at least one current member
> remain, to have one steering council member who knows the project history
> well on the committee. Both Stefan and I have said that we're happy to stay
> on. So I would suggest that Stefan and I get together and figure out who of
> us that will be. And then we update the website and the CoC committee's
> private email list.
>

Sounds good.  Thanks Sebastian, Ralf, Anirudh and Melissa!

Warren


> Cheers,
> Ralf
>

From oberoi011115tina at gmail.com  Sun May  3 06:39:41 2020
From: oberoi011115tina at gmail.com (Tina Oberoi)
Date: Sun, 3 May 2020 16:09:41 +0530
Subject: [Numpy-discussion] Closing resolved good-first-issues
Message-ID: <CAM2id8wv74SxycV8jbt78P25wKwHFi-Z3MawE7vyreB44hSQiQ@mail.gmail.com>

Fri, 1 May 2020 18:05:14  Ralf Gommers <ralf.gommers at gmail.com>
wrote:

>
> Hi Tina, thanks for pointing that out. I have added you to the triage
team,
> so you are able to close issues that you already noticed are fixed. I'll
> have a look at labelling some new ones now.

These are the issues that have pull requests merged but still open, Please
let me know if I am wrong else we can close these issues:
-  Issue #9476 <https://github.com/numpy/numpy/issues/9476>
-  Issue #2802 <https://github.com/numpy/numpy/issues/2802>
-  Issue #11875 <https://github.com/numpy/numpy/issues/11875>
-  Issue #13114 <https://github.com/numpy/numpy/issues/13114>
-  Issue #13758 <https://github.com/numpy/numpy/issues/13758>

Thanks and Regards
Tina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200503/9ad7aa1a/attachment-0001.html>

From charlesr.harris at gmail.com  Sun May  3 12:16:52 2020
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 3 May 2020 10:16:52 -0600
Subject: [Numpy-discussion] NumPy 1.18.4 release
Message-ID: <CAB6mnxJ6Gnagyvnceh2aiyvbqvkRxaFw3X7GBwcspYao5FkZZA@mail.gmail.com>

Hi All,

On behalf of the NumPy team I am pleased to announce that NumPy 1.18.4 has
been released. This is the last planned release in the 1.18.x series. It
reverts the bool("0") behavior introduced in 1.18.3 and fixes a bug in
Generator.integers. There is also a link to a new troubleshooting section
in the documentation included in the error message emitted when numpy
import fails.

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 <https://pypi.org/project/numpy/1.18.4>,
source archives and release notes are available from Github
<https://github.com/numpy/numpy/releases/tag/v1.18.4>.

*Contributors*

A total of 4 people contributed to this release.  People with a "+" by their
names contributed a patch for the first time.

   - Charles Harris
   - Matti Picus
   - Sebastian Berg
   - Warren Weckesser


*Pull requests merged*

A total of 6 pull requests were merged for this release.

   - #16055: BLD: add i686 for 1.18 builds
   - #16090: BUG: random: Generator.integers(2**32) always returned 0.
   - #16091: BLD: fix path to libgfortran on macOS
   - #16109: REV: Reverts side-effect changes to casting
   - #16114: BLD: put openblas library in local directory on windows
   - #16132: DOC: Change import error "howto" to link to new
   troubleshooting...


Cheers,

Charles Harris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200503/cc59cdd6/attachment.html>

From anntzer.lee at gmail.com  Sun May  3 16:35:45 2020
From: anntzer.lee at gmail.com (Antony Lee)
Date: Sun, 3 May 2020 22:35:45 +0200
Subject: [Numpy-discussion] ANN: mplcairo 0.3 release
Message-ID: <CAGRr6BFh6pxnmUdA_nAgw1-U+VUmXENN=nOyCXBONZq6_hrYdQ@mail.gmail.com>

Dear all,

I am pleased to announce the release of mplcairo 0.3.

mplcairo is a Matplotlib backend based on the well-known cairo library,
supporting output to both raster (including interactively) and vector
formats.  In other words, it provides the functionality of Matplotlib's
{,qt5,gtk3,wx,tk,macos}{agg,cairo}, pdf, ps, and svg backends.

Per Matplotlib's standard API, the backend can be selected by calling

    matplotlib.use("module://mplcairo.qt")

or setting your MPLBACKEND environment variable to `module://mplcairo.qt`
for Qt5, and similarly for other toolkits.

mplcairo 0.3 adds support for OpenType font features (see
`examples/opentype_features.py`), pdftex.map font effects, simplifications
to the build, and as well as the usual bugfixes over 0.2.

Enjoy,

Antony Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200503/e0b05fad/attachment.html>

From charlesr.harris at gmail.com  Sun May  3 17:25:53 2020
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 3 May 2020 15:25:53 -0600
Subject: [Numpy-discussion] NumPy nightly wheel builds
Message-ID: <CAB6mnxLdTOhUmGPz2Crqf=4rrs-pq2U+PX45r735wuNagda3xA@mail.gmail.com>

Hi All,

The NumPy "nightly" wheel builds, actually built weekly on Sunday mornings,
have moved to  https://anaconda.org/scipy-wheels-nightly/numpy/files. They
can be installed/downloaded using pip:

pip install -i https://pypi.anaconda.org/scipy-wheels-nightly/simple numpy

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200503/9325fe6c/attachment.html>

From andyfaff at gmail.com  Sun May  3 19:33:32 2020
From: andyfaff at gmail.com (Andrew Nelson)
Date: Mon, 4 May 2020 09:33:32 +1000
Subject: [Numpy-discussion] NumPy nightly wheel builds
In-Reply-To: <CAB6mnxLdTOhUmGPz2Crqf=4rrs-pq2U+PX45r735wuNagda3xA@mail.gmail.com>
References: <CAB6mnxLdTOhUmGPz2Crqf=4rrs-pq2U+PX45r735wuNagda3xA@mail.gmail.com>
Message-ID: <CAAbtOZd1GiatxQprJnV8s89vYj73J7v4HWrZQ=uHhZEdZr+5pg@mail.gmail.com>

On Mon, 4 May 2020, 07:26 Charles R Harris, <charlesr.harris at gmail.com>
wrote:

> Hi All,
>
> The NumPy "nightly" wheel builds, actually built weekly on Sunday
> mornings, have moved to
> https://anaconda.org/scipy-wheels-nightly/numpy/files. They can be
> installed/downloaded using pip:
>


That's awesome, thank you. Would it be possible to make a Python 3.9 build
as well?

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200504/67b66f88/attachment.html>

From charlesr.harris at gmail.com  Sun May  3 20:17:27 2020
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 3 May 2020 18:17:27 -0600
Subject: [Numpy-discussion] NumPy nightly wheel builds
In-Reply-To: <CAAbtOZd1GiatxQprJnV8s89vYj73J7v4HWrZQ=uHhZEdZr+5pg@mail.gmail.com>
References: <CAB6mnxLdTOhUmGPz2Crqf=4rrs-pq2U+PX45r735wuNagda3xA@mail.gmail.com>
 <CAAbtOZd1GiatxQprJnV8s89vYj73J7v4HWrZQ=uHhZEdZr+5pg@mail.gmail.com>
Message-ID: <CAB6mnxLpTRzpHhxGsBRruuf3k56=gn6vPOJqQ4f_VR5XijD8_A@mail.gmail.com>

On Sun, May 3, 2020 at 5:34 PM Andrew Nelson <andyfaff at gmail.com> wrote:

>
>
> On Mon, 4 May 2020, 07:26 Charles R Harris, <charlesr.harris at gmail.com>
> wrote:
>
>> Hi All,
>>
>> The NumPy "nightly" wheel builds, actually built weekly on Sunday
>> mornings, have moved to
>> https://anaconda.org/scipy-wheels-nightly/numpy/files. They can be
>> installed/downloaded using pip:
>>
>
>
> That's awesome, thank you. Would it be possible to make a Python 3.9 build
> as well?
>

We will do that when Python 3.9 gets closer to release. We will probably
start CI testing when betas begin and support 3.9 in NumPy 1.20.x series.
Nightly builds, we will see. The manylinux* docker images and OpenBLAS
libraries will need to be updated and we will probably want to wait for the
official Python 3.9 release to do that.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200503/c89ca923/attachment-0001.html>

From andyfaff at gmail.com  Sun May  3 20:19:48 2020
From: andyfaff at gmail.com (Andrew Nelson)
Date: Mon, 4 May 2020 10:19:48 +1000
Subject: [Numpy-discussion] NumPy nightly wheel builds
In-Reply-To: <CAB6mnxLpTRzpHhxGsBRruuf3k56=gn6vPOJqQ4f_VR5XijD8_A@mail.gmail.com>
References: <CAB6mnxLdTOhUmGPz2Crqf=4rrs-pq2U+PX45r735wuNagda3xA@mail.gmail.com>
 <CAAbtOZd1GiatxQprJnV8s89vYj73J7v4HWrZQ=uHhZEdZr+5pg@mail.gmail.com>
 <CAB6mnxLpTRzpHhxGsBRruuf3k56=gn6vPOJqQ4f_VR5XijD8_A@mail.gmail.com>
Message-ID: <CAAbtOZf9+jx=exKGpc2wv5uCg_u4WSkyE=uPW0Mp5RTXqBaDfQ@mail.gmail.com>

Python 3.9 beta is ~ May 18
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200504/bd4246d0/attachment.html>

From matti.picus at gmail.com  Mon May  4 02:40:33 2020
From: matti.picus at gmail.com (Matti Picus)
Date: Mon, 4 May 2020 09:40:33 +0300
Subject: [Numpy-discussion] Closing resolved good-first-issues
In-Reply-To: <CAM2id8wv74SxycV8jbt78P25wKwHFi-Z3MawE7vyreB44hSQiQ@mail.gmail.com>
References: <CAM2id8wv74SxycV8jbt78P25wKwHFi-Z3MawE7vyreB44hSQiQ@mail.gmail.com>
Message-ID: <d9620830-8eb1-db65-b0ff-e2d31843857b@gmail.com>


On 3/5/20 1:39 pm, Tina Oberoi wrote:
>
> These are the issues that have pull requests merged but still open, 
> Please let me know if I am wrong else we can close these issues:
> - Issue #9476 <https://github.com/numpy/numpy/issues/9476>
> - Issue #2802 <https://github.com/numpy/numpy/issues/2802>
> - Issue #11875 <https://github.com/numpy/numpy/issues/11875>
> - Issue #13114 <https://github.com/numpy/numpy/issues/13114>
> - Issue #13758 <https://github.com/numpy/numpy/issues/13758>
>
> Thanks and Regards
> Tina
>

Tina it would be helpful to directly comment on the issues in question. 
If you are unsure the issues are actually resolved, you can add a 
comment? "Can we close this, probably resolved by ...". If you are sure 
they are resolved, go ahead and close them with a message "Resolved by 
...". If it appears they are too complicated for the "good first issue" 
label, you can just remove the label.


Matti


From ralf.gommers at gmail.com  Mon May  4 06:22:10 2020
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 4 May 2020 12:22:10 +0200
Subject: [Numpy-discussion] Closing resolved good-first-issues
In-Reply-To: <d9620830-8eb1-db65-b0ff-e2d31843857b@gmail.com>
References: <CAM2id8wv74SxycV8jbt78P25wKwHFi-Z3MawE7vyreB44hSQiQ@mail.gmail.com>
 <d9620830-8eb1-db65-b0ff-e2d31843857b@gmail.com>
Message-ID: <CABL7CQhatO2qL3x4MhmgWCP_3J1ttd6f_x_rdXcCXXij8vvRsg@mail.gmail.com>

On Mon, May 4, 2020 at 8:40 AM Matti Picus <matti.picus at gmail.com> wrote:

>
> On 3/5/20 1:39 pm, Tina Oberoi wrote:
> >
> > These are the issues that have pull requests merged but still open,
> > Please let me know if I am wrong else we can close these issues:
> > - Issue #9476 <https://github.com/numpy/numpy/issues/9476>
> > - Issue #2802 <https://github.com/numpy/numpy/issues/2802>
> > - Issue #11875 <https://github.com/numpy/numpy/issues/11875>
> > - Issue #13114 <https://github.com/numpy/numpy/issues/13114>
> > - Issue #13758 <https://github.com/numpy/numpy/issues/13758>
> >
> > Thanks and Regards
> > Tina
>

Thanks for this list Tina!


> Tina it would be helpful to directly comment on the issues in question.
> If you are unsure the issues are actually resolved, you can add a
> comment  "Can we close this, probably resolved by ...". If you are sure
> they are resolved, go ahead and close them with a message "Resolved by
> ...".


I agree with that advice, if it's clear-cut you can do this. Most cases
were pretty complicated though to assess.

If it appears they are too complicated for the "good first issue"
> label, you can just remove the label.
>

A request to maintainers as well: please keep "good first issue" for
actually easy things. 3 of these were easy (one of which turned into a hard
one during the conversation), but 2 were definitely not.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200504/140b1644/attachment.html>

From albuscode at gmail.com  Mon May  4 22:50:45 2020
From: albuscode at gmail.com (Inessa Pawson)
Date: Mon, 4 May 2020 19:50:45 -0700 (MST)
Subject: [Numpy-discussion] Season of Docs technical writer
In-Reply-To: <CAA7-tfjW8_UWXx=JZ21SB=ZnpvhAZnFoKegm2AT_nEzp5SQWag@mail.gmail.com>
References: <CAA7-tfjW8_UWXx=JZ21SB=ZnpvhAZnFoKegm2AT_nEzp5SQWag@mail.gmail.com>
Message-ID: <1588647045749-0.post@n7.nabble.com>

Hi, Ben!
You have certainly set the bar very high for this year?s Season of Docs
writers with your proposal. Reading it has brighten up my morning!
-- 
Every good wish,
Inessa Pawson 




--
Sent from: http://numpy-discussion.10968.n7.nabble.com/

From sebastian at sipsolutions.net  Tue May  5 12:48:00 2020
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Tue, 05 May 2020 11:48:00 -0500
Subject: [Numpy-discussion] NumPy Development Meeting Tomorrow - Triage Focus
Message-ID: <0823e8a3a9903492d4027128b39c72a425d15585.camel@sipsolutions.net>

Hi all,

Our bi-weekly triage-focused NumPy development meeting is tomorrow
(Wednesday, May 6th) 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


From bennet at umich.edu  Wed May  6 00:44:37 2020
From: bennet at umich.edu (Bennet Fauber)
Date: Wed, 6 May 2020 00:44:37 -0400
Subject: [Numpy-discussion] Documentation Team Meeting - Monday April 27
In-Reply-To: <CAC7J6VbBZDUmKwUDfps+Ueeybc1MsMXKhrju=qYSGGWnp42yVQ@mail.gmail.com>
References: <CAC7J6VapAGeK9a3j=ZARwaBqOh6NB5a1upep+qq6-=AiMN_6UQ@mail.gmail.com>
 <CAC7J6VbBZDUmKwUDfps+Ueeybc1MsMXKhrju=qYSGGWnp42yVQ@mail.gmail.com>
Message-ID: <CAB2ovotJfcGpYVs-3EiUKyKywzWhD5tsdLzGAVik=9eN_6dSyQ@mail.gmail.com>

I added a link to the NumPy regression example tutorial I created to
the HackMD document near the bottom of the notes for the last meeting.

It is quite long, a function of it being based on material for several
one-hour, hands-on training sessions for very beginning Python users
(about half the class had used Python for less than two hours) that I
gave over four days.  I try to lay out a bit of the theory, a bit of
making a plan for the project, and some opinions.  I'm sure it would
need to be modified a good deal to fit into the NumPy scheme of
things.  It is definitely a draft.  Hopefully there is something
useful in it.

-- bennet

On Mon, Apr 27, 2020 at 6:51 AM Melissa Mendon?a <melissawm at gmail.com> wrote:
>
> Hi all!
>
> Sorry for the late reminder, but today (April 27) 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!
>
> ** 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=20200406T15&p1=1440&ah=1
>
> - Melissa
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

From anirudh2290 at gmail.com  Fri May  8 14:55:43 2020
From: anirudh2290 at gmail.com (Anirudh Subramanian)
Date: Fri, 8 May 2020 11:55:43 -0700
Subject: [Numpy-discussion] divmod(1.0, 0.0) bug
Message-ID: <CAFVLAA9z4EoEPT8E7Ope1ctM71kJTmXAsKnb+6z_Rza=Ab42tA@mail.gmail.com>

Hi all,

There has been a discussion about divmod (1.0, 0.0) bug here :
https://github.com/numpy/numpy/issues/14900 and
https://github.com/numpy/numpy/pull/16161 .

*SUMMARY*

Currently divmod(1.0, 0.0) sets the "Invalid error" and returns (nan, nan).
This is not consistent with IEEE 754
<https://en.wikipedia.org/wiki/IEEE_754> standard which says that 1.0/0.0
divisions should return inf and raise dividebyzero error. Although this may
not apply to divmod, it should apply to floor_divide and mod.
I have summarized in the table below, summarizing current state and
expected state.

Operator Warning message Expected warning Result Expected Result
np.divmod Invalid error invalid and dividebyzero ?? nan, nan inf, nan
np.fmod(1.0, 0.0) Invalid error Invalid nan nan
np.floor_divide(1.0, 0.0) Invalid error Dividebyzero nan inf
np.remainder(1.0, 0.0) Invalid error Invalid nan nan


For remainder and fmod above, according to the standard, it is supposed to
raise invalid error. We need to change the code to also raise dividebyzero
error for floor_divide.

The question is what to do for np.divmod (since this is not defined by
standard). My opinion is in this case we need to set both dividebyzero and
invalid error flags since its a combination of these two operations.

*USER IMPACT*

This is going to cause a breaking change/silent incorrect results to
atleast some users who are either doing one or two of the following:
1. expecting nans from their output and check isnan but not isinf in their
code and accordingly do further computations.
2. who currently call raise only on invalid and not dividebyzero errors for
any of  the above listed operations.

Considering this we can try one of the two things:
1. Create a futurewarning for every divmod(1.0, 0.0) path. This may be very
noisy and I cannot think of an action for a user to take to suppress this.
2. Since bug fixes are exempt from backwards compatibility policy
<https://numpy.org/neps/nep-0023-backwards-compatibility.html> just notify
in the release notes, maybe after a couple of releases. (More Impactful)

*OTHER ISSUES?*

Depending on the compiler, and if it implements annex F of the C standard,
it may not support 1.0/0.0 operation and may crash. Also this is the case
for true_divide also, so we wont be breaking more users than we currently
are.

Would like to hear your thoughts about this!

Anirudh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200508/30dafdf9/attachment.html>

From jbrockmendel at gmail.com  Fri May  8 19:10:02 2020
From: jbrockmendel at gmail.com (Brock Mendel)
Date: Fri, 8 May 2020 16:10:02 -0700
Subject: [Numpy-discussion] divmod(1.0, 0.0) bug
In-Reply-To: <CAFVLAA9z4EoEPT8E7Ope1ctM71kJTmXAsKnb+6z_Rza=Ab42tA@mail.gmail.com>
References: <CAFVLAA9z4EoEPT8E7Ope1ctM71kJTmXAsKnb+6z_Rza=Ab42tA@mail.gmail.com>
Message-ID: <CAKf8g9T2OOht99qqjbMSKXM6dm_HPwXO+xEQwn99iUokw_o0Jw@mail.gmail.com>

FWIW in pandas we post-process floordiv (and divmod) ops to get the
"Expected Result" behavior from the OP.


On Fri, May 8, 2020 at 11:56 AM Anirudh Subramanian <anirudh2290 at gmail.com>
wrote:

> Hi all,
>
> There has been a discussion about divmod (1.0, 0.0) bug here :
> https://github.com/numpy/numpy/issues/14900 and
> https://github.com/numpy/numpy/pull/16161 .
>
> *SUMMARY*
>
> Currently divmod(1.0, 0.0) sets the "Invalid error" and returns (nan,
> nan). This is not consistent with IEEE 754
> <https://en.wikipedia.org/wiki/IEEE_754> standard which says that 1.0/0.0
> divisions should return inf and raise dividebyzero error. Although this may
> not apply to divmod, it should apply to floor_divide and mod.
> I have summarized in the table below, summarizing current state and
> expected state.
>
> Operator Warning message Expected warning Result Expected Result
> np.divmod Invalid error invalid and dividebyzero ?? nan, nan inf, nan
> np.fmod(1.0, 0.0) Invalid error Invalid nan nan
> np.floor_divide(1.0, 0.0) Invalid error Dividebyzero nan inf
> np.remainder(1.0, 0.0) Invalid error Invalid nan nan
>
>
> For remainder and fmod above, according to the standard, it is supposed to
> raise invalid error. We need to change the code to also raise dividebyzero
> error for floor_divide.
>
> The question is what to do for np.divmod (since this is not defined by
> standard). My opinion is in this case we need to set both dividebyzero and
> invalid error flags since its a combination of these two operations.
>
> *USER IMPACT*
>
> This is going to cause a breaking change/silent incorrect results to
> atleast some users who are either doing one or two of the following:
> 1. expecting nans from their output and check isnan but not isinf in their
> code and accordingly do further computations.
> 2. who currently call raise only on invalid and not dividebyzero errors
> for any of  the above listed operations.
>
> Considering this we can try one of the two things:
> 1. Create a futurewarning for every divmod(1.0, 0.0) path. This may be
> very noisy and I cannot think of an action for a user to take to suppress
> this.
> 2. Since bug fixes are exempt from backwards compatibility policy
> <https://numpy.org/neps/nep-0023-backwards-compatibility.html> just
> notify in the release notes, maybe after a couple of releases. (More
> Impactful)
>
> *OTHER ISSUES?*
>
> Depending on the compiler, and if it implements annex F of the C standard,
> it may not support 1.0/0.0 operation and may crash. Also this is the case
> for true_divide also, so we wont be breaking more users than we currently
> are.
>
> Would like to hear your thoughts about this!
>
> Anirudh
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200508/579767fa/attachment.html>

From shoyer at gmail.com  Fri May  8 20:13:37 2020
From: shoyer at gmail.com (Stephan Hoyer)
Date: Fri, 8 May 2020 17:13:37 -0700
Subject: [Numpy-discussion] divmod(1.0, 0.0) bug
In-Reply-To: <CAKf8g9T2OOht99qqjbMSKXM6dm_HPwXO+xEQwn99iUokw_o0Jw@mail.gmail.com>
References: <CAFVLAA9z4EoEPT8E7Ope1ctM71kJTmXAsKnb+6z_Rza=Ab42tA@mail.gmail.com>
 <CAKf8g9T2OOht99qqjbMSKXM6dm_HPwXO+xEQwn99iUokw_o0Jw@mail.gmail.com>
Message-ID: <CAEQ_TvdgYaShQT4udZE0Cw-A6uDwyNXXvG4KC_Loi5gSZMj=Vw@mail.gmail.com>

On Fri, May 8, 2020 at 4:10 PM Brock Mendel <jbrockmendel at gmail.com> wrote:

> FWIW in pandas we post-process floordiv (and divmod) ops to get the
> "Expected Result" behavior from the OP.
>
>
> On Fri, May 8, 2020 at 11:56 AM Anirudh Subramanian <anirudh2290 at gmail.com>
> wrote:
>
>> Hi all,
>>
>> There has been a discussion about divmod (1.0, 0.0) bug here :
>> https://github.com/numpy/numpy/issues/14900 and
>> https://github.com/numpy/numpy/pull/16161 .
>>
>> *SUMMARY*
>>
>> Currently divmod(1.0, 0.0) sets the "Invalid error" and returns (nan,
>> nan). This is not consistent with IEEE 754
>> <https://en.wikipedia.org/wiki/IEEE_754> standard which says that
>> 1.0/0.0 divisions should return inf and raise dividebyzero error. Although
>> this may not apply to divmod, it should apply to floor_divide and mod.
>> I have summarized in the table below, summarizing current state and
>> expected state.
>>
>> Operator Warning message Expected warning Result Expected Result
>> np.divmod Invalid error invalid and dividebyzero ?? nan, nan inf, nan
>> np.fmod(1.0, 0.0) Invalid error Invalid nan nan
>> np.floor_divide(1.0, 0.0) Invalid error Dividebyzero nan inf
>> np.remainder(1.0, 0.0) Invalid error Invalid nan nan
>>
>>
>> For remainder and fmod above, according to the standard, it is supposed
>> to raise invalid error. We need to change the code to also raise
>> dividebyzero error for floor_divide.
>>
>> The question is what to do for np.divmod (since this is not defined by
>> standard). My opinion is in this case we need to set both dividebyzero and
>> invalid error flags since its a combination of these two operations.
>>
>> *USER IMPACT*
>>
>> This is going to cause a breaking change/silent incorrect results to
>> atleast some users who are either doing one or two of the following:
>> 1. expecting nans from their output and check isnan but not isinf in
>> their code and accordingly do further computations.
>> 2. who currently call raise only on invalid and not dividebyzero errors
>> for any of  the above listed operations.
>>
>> Considering this we can try one of the two things:
>> 1. Create a futurewarning for every divmod(1.0, 0.0) path. This may be
>> very noisy and I cannot think of an action for a user to take to suppress
>> this.
>> 2. Since bug fixes are exempt from backwards compatibility policy
>> <https://numpy.org/neps/nep-0023-backwards-compatibility.html> just
>> notify in the release notes, maybe after a couple of releases. (More
>> Impactful)
>>
>
I agree, I think these behaviors could be considered bugs and fixed without
warning. (However, note that the backwards compatibility policy you link to
is only a draft, not officially accepted.)

My guess is that these code paths have been rarely exercised, because floor
division and divmod are most useful for integers.


>
>> *OTHER ISSUES?*
>>
>> Depending on the compiler, and if it implements annex F of the C
>> standard, it may not support 1.0/0.0 operation and may crash. Also this is
>> the case for true_divide also, so we wont be breaking more users than we
>> currently are.
>>
>> Would like to hear your thoughts about this!
>>
>> Anirudh
>>
>> _______________________________________________
>> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200508/575366af/attachment-0001.html>

From anirudh2290 at gmail.com  Sat May  9 01:51:51 2020
From: anirudh2290 at gmail.com (Anirudh Subramanian)
Date: Fri, 8 May 2020 22:51:51 -0700
Subject: [Numpy-discussion] divmod(1.0, 0.0) bug
In-Reply-To: <CAEQ_TvdgYaShQT4udZE0Cw-A6uDwyNXXvG4KC_Loi5gSZMj=Vw@mail.gmail.com>
References: <CAFVLAA9z4EoEPT8E7Ope1ctM71kJTmXAsKnb+6z_Rza=Ab42tA@mail.gmail.com>
 <CAKf8g9T2OOht99qqjbMSKXM6dm_HPwXO+xEQwn99iUokw_o0Jw@mail.gmail.com>
 <CAEQ_TvdgYaShQT4udZE0Cw-A6uDwyNXXvG4KC_Loi5gSZMj=Vw@mail.gmail.com>
Message-ID: <CAFVLAA93GporVnJ6qc3OdGc28fwJx5us1nPkkZNM7Z1uN54+Yg@mail.gmail.com>

Thanks for your inputs, Brock and Stephan.

> (However, note that the backwards compatibility policy you link to is
only a draft, not officially accepted.)

Yes, I didn't realize that. Thanks for pointing that out. In practice from
the little I have seen, I find the NEP very close to what is being followed
in numpy.

Anirudh

On Fri, May 8, 2020 at 5:14 PM Stephan Hoyer <shoyer at gmail.com> wrote:

> On Fri, May 8, 2020 at 4:10 PM Brock Mendel <jbrockmendel at gmail.com>
> wrote:
>
>> FWIW in pandas we post-process floordiv (and divmod) ops to get the
>> "Expected Result" behavior from the OP.
>>
>>
>> On Fri, May 8, 2020 at 11:56 AM Anirudh Subramanian <
>> anirudh2290 at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> There has been a discussion about divmod (1.0, 0.0) bug here :
>>> https://github.com/numpy/numpy/issues/14900 and
>>> https://github.com/numpy/numpy/pull/16161 .
>>>
>>> *SUMMARY*
>>>
>>> Currently divmod(1.0, 0.0) sets the "Invalid error" and returns (nan,
>>> nan). This is not consistent with IEEE 754
>>> <https://en.wikipedia.org/wiki/IEEE_754> standard which says that
>>> 1.0/0.0 divisions should return inf and raise dividebyzero error. Although
>>> this may not apply to divmod, it should apply to floor_divide and mod.
>>> I have summarized in the table below, summarizing current state and
>>> expected state.
>>>
>>> Operator Warning message Expected warning Result Expected Result
>>> np.divmod Invalid error invalid and dividebyzero ?? nan, nan inf, nan
>>> np.fmod(1.0, 0.0) Invalid error Invalid nan nan
>>> np.floor_divide(1.0, 0.0) Invalid error Dividebyzero nan inf
>>> np.remainder(1.0, 0.0) Invalid error Invalid nan nan
>>>
>>>
>>> For remainder and fmod above, according to the standard, it is supposed
>>> to raise invalid error. We need to change the code to also raise
>>> dividebyzero error for floor_divide.
>>>
>>> The question is what to do for np.divmod (since this is not defined by
>>> standard). My opinion is in this case we need to set both dividebyzero and
>>> invalid error flags since its a combination of these two operations.
>>>
>>> *USER IMPACT*
>>>
>>> This is going to cause a breaking change/silent incorrect results to
>>> atleast some users who are either doing one or two of the following:
>>> 1. expecting nans from their output and check isnan but not isinf in
>>> their code and accordingly do further computations.
>>> 2. who currently call raise only on invalid and not dividebyzero errors
>>> for any of  the above listed operations.
>>>
>>> Considering this we can try one of the two things:
>>> 1. Create a futurewarning for every divmod(1.0, 0.0) path. This may be
>>> very noisy and I cannot think of an action for a user to take to suppress
>>> this.
>>> 2. Since bug fixes are exempt from backwards compatibility policy
>>> <https://numpy.org/neps/nep-0023-backwards-compatibility.html> just
>>> notify in the release notes, maybe after a couple of releases. (More
>>> Impactful)
>>>
>>
> I agree, I think these behaviors could be considered bugs and fixed
> without warning. (However, note that the backwards compatibility policy you
> link to is only a draft, not officially accepted.)
>
> My guess is that these code paths have been rarely exercised, because
> floor division and divmod are most useful for integers.
>
>
>>
>>> *OTHER ISSUES?*
>>>
>>> Depending on the compiler, and if it implements annex F of the C
>>> standard, it may not support 1.0/0.0 operation and may crash. Also this is
>>> the case for true_divide also, so we wont be breaking more users than we
>>> currently are.
>>>
>>> Would like to hear your thoughts about this!
>>>
>>> Anirudh
>>>
>>> _______________________________________________
>>> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200508/1fdd4cce/attachment.html>

From josh.craig.wilson at gmail.com  Sat May  9 15:47:07 2020
From: josh.craig.wilson at gmail.com (Joshua Wilson)
Date: Sat, 9 May 2020 12:47:07 -0700
Subject: [Numpy-discussion] Feelings about type aliases in NumPy
In-Reply-To: <CAEBuzr9hSnLO84GbUVwRbS=FySKKCw6WFGscQC4my+=sgVcVVg@mail.gmail.com>
References: <CAKFGQGzYs4qrvM=-zfGY_TyLabXyXkP32OhapZm6c1kkZzBh_A@mail.gmail.com>
 <e1ab12dc-7f03-49f5-be63-38b848789835@www.fastmail.com>
 <1e1edc6b7e204fb152b0ab539793e665df635eac.camel@sipsolutions.net>
 <CAEQ_TvdZadPBM-03Ja+qscESnjck6j030+QBAKmuXJ=k7aSi7w@mail.gmail.com>
 <CAE8Ss2Hku5FJbHTXSRnuvDO=VbkELOjgYnZYmLioGug1-Agh2Q@mail.gmail.com>
 <CAEBuzr9Lmt8ayUjQDZNWWq7co7kqFJw1JnvMDOziydaAEpAfTg@mail.gmail.com>
 <CAKFGQGyPxggPzCVoz+aC1SEq9auby3OqmvtSD6Aj48iY8hc8jw@mail.gmail.com>
 <CAEBuzr9hSnLO84GbUVwRbS=FySKKCw6WFGscQC4my+=sgVcVVg@mail.gmail.com>
Message-ID: <CAKFGQGzpp1Hvv00CcK3LkMSiZcNm_QC7XPU+vZht2PK2+KwvxA@mail.gmail.com>

Following some additional discussion on the PR (see comments after
https://github.com/numpy/numpy-stubs/pull/66#issuecomment-620139434),
the proposed path forward is:

- Add the module `numpy.typing` to the type stubs only for now
- Initially it will contain types for ArrayLike and DtypeLike
- When the stubs are merged into NumPy, add the `numpy.typing` module
to NumPy itself.

Any further objections?

On Mon, Apr 27, 2020 at 10:50 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>
> > Interestingly this was proposed independently here:
>
> Wow apologies for missing the entire thread about it and the noise.
>
>
> On Sun, Apr 26, 2020 at 11:19 PM Joshua Wilson <josh.craig.wilson at gmail.com> wrote:
>>
>> To try and add some more data points to the conversation:
>>
>> > Maybe we can go for a bit more distant name like "numpy.annotations" or whatever.
>>
>> Interestingly this was proposed independently here:
>>
>> https://github.com/numpy/numpy-stubs/pull/66#issuecomment-619131274
>>
>> Related to that, Ralf was opposed to numpy.typing because it would
>> shadow a stdlib module name:
>>
>> https://github.com/numpy/numpy-stubs/pull/66#issuecomment-619123629
>>
>> But, types is _also_ a stdlib module name. Maybe the above points give
>> some extra weight to "numpy.annotations"?
>>
>> > Unless we anticipate adding a long list of type aliases (more than the three suggested so far)
>>
>> While working on some types in SciPy here:
>>
>> https://github.com/scipy/scipy/pull/11936#discussion_r415280894
>>
>> we ran into the issue of typing things that are "integer types" or
>> "floating types". For the time being we just inlined a definition like
>> Union[float, np.floating], but conceivably we would want to unify
>> those definitions somewhere instead of redefining them in every
>> project. (Note that existing types like SupportsInt etc. were not what
>> we wanted.) This perhaps suggests that the ultimate number of type
>> aliases might be larger than we initially thought.
>>
>> On Sun, Apr 26, 2020 at 6:25 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>> >
>> > I agree that parking all these in a secondary namespace sounds a better option, can't say that I feel for the word "typing" though. There are already too many type, dtype, ctypeslib etc. Maybe we can go for a bit more distant name like "numpy.annotations" or whatever.
>> >
>> > On Sat, Apr 25, 2020 at 8:51 AM Kevin Sheppard <kevin.k.sheppard at gmail.com> wrote:
>> >>
>> >> Typing is for library developers more than end users. I would also worry that putting it into the top level might discourage other typing classes since it is more difficult to add to the top level than to a lower level module. np.typing seems very clear to me.
>> >>
>> >> On Sat, Apr 25, 2020, 07:41 Stephan Hoyer <shoyer at gmail.com> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg <sebastian at sipsolutions.net> wrote:
>> >>>>
>> >>>> On Fri, 2020-04-24 at 11:10 -0700, Stefan van der Walt wrote:
>> >>>> > On Fri, Apr 24, 2020, at 08:45, Joshua Wilson wrote:
>> >>>> > > But, Stephan pointed out that it might be confusing to users for
>> >>>> > > objects to only exist at typing time, so we came around to the
>> >>>> > > question of whether people are open to the idea of including the
>> >>>> > > type
>> >>>> > > aliases in NumPy itself. Ralf's concrete proposal was to make a
>> >>>> > > module
>> >>>> > > numpy.types (or maybe numpy.typing) to hold the aliases so that
>> >>>> > > they
>> >>>> > > don't pollute the top-level namespace. The module would initially
>> >>>> > > contain the types
>> >>>> >
>> >>>> > That sounds very sensible.  Having types available with NumPy should
>> >>>> > also encourage their use, especially if we can add some documentation
>> >>>> > around it.
>> >>>>
>> >>>> I agree, I might have a small tendency for `numpy.types` if we ever
>> >>>> find any usage other than direct typing that may be the better name?
>> >>>
>> >>>
>> >>> Unless we anticipate adding a long list of type aliases (more than the three suggested so far), I would lean towards adding ArrayLike to the top level NumPy namespace as np.ArrayLike.
>> >>>
>> >>> Type annotations are becoming an increasingly core part of modern Python code. We should make it easy to appropriately type check functions that act on NumPy arrays, and a top level np.ArrayLike is definitely more convenient than np.types.ArrayLike.
>> >>>
>> >>>> Out of curiousity, I guess `ArrayLike` would be an ABC that a
>> >>>> downstream project can register with?
>> >>>
>> >>>
>> >>> ArrayLike will be a typing Protocol, automatically recognizing attributes like __array__ to indicate that something can be cast to an array.
>> >>>
>> >>>>
>> >>>>
>> >>>> - Sebastian
>> >>>>
>> >>>>
>> >>>> >
>> >>>> > St?fan
>> >>>> > _______________________________________________
>> >>>> > 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
>> >>
>> >> _______________________________________________
>> >> 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
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

From ralf.gommers at gmail.com  Sun May 10 16:06:39 2020
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 10 May 2020 22:06:39 +0200
Subject: [Numpy-discussion] Update the Code of Conduct Committee
 Membership (new members wanted)
In-Reply-To: <CAGzF1ueomYE7HAnfBme-qjnARFfK1nPFpYT6pDi4tejhGX=ZcA@mail.gmail.com>
References: <6ca65ab6bb3c75184a053ec0ec0831ed4ff77fa3.camel@sipsolutions.net>
 <CABL7CQgvyJLzq6gxuSN5mMj-hiocyKZUssvbPiQZMPXgrw71nQ@mail.gmail.com>
 <CAGzF1ueomYE7HAnfBme-qjnARFfK1nPFpYT6pDi4tejhGX=ZcA@mail.gmail.com>
Message-ID: <CABL7CQhpeKKExWbAw1Ni+7gQsw0PD9H=zZ=iJrBsKUkN7aaYBQ@mail.gmail.com>

On Sat, May 2, 2020 at 10:23 PM Warren Weckesser <warren.weckesser at gmail.com>
wrote:

> On 5/2/20, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> > On Thu, Apr 23, 2020 at 11:38 PM Sebastian Berg
> > <sebastian at sipsolutions.net>
> > wrote:
> >
> >> Hi all,
> >>
> >> it has come up in the last community call that many of our committee
> >> membership lists have not been updated in a while.
> >> This is not a big issue as such.  But, while these committees are not
> >> very active on a day-to-day basis, they are an important part of the
> >> community and it is better to update them regularly and thus also
> >> ensure they remain representative of the community.
> >>
> >
> > Thanks Sebastian!
> >
> >
> >> We would like to start by updating the members of the Code of Conduct
> >> (CoC) committee.  The CoC committee is in charge of responding and
> >> following up to any reports of CoC breaches, as stated in:
> >>
> >>
> >>
> https://docs.scipy.org/doc/numpy/dev/conduct/code_of_conduct.html#incident-reporting-resolution-code-of-conduct-enforcement
> >>
> >> If you are interested in or happy to serve on our CoC committee please
> >> let me or e.g. Ralf Gommers know, join the next community meeting
> >> (April 29th, 11:00PDT/18:00UTC), or reply on the list.
> >>
> >> I hope we will be able to discuss and reach a consensus between those
> >> interested and involved quickly (possibly already on the next community
> >> call).  In either case, before any changes they will be run by the
> >> mailing list to ensure community consensus.
> >>
> >
> > Following up on this: Melissa and Anirudh both volunteered for this
> (thank
> > you!), and in the last community call we discussed this (thumbs up from
> > everyone there), and gave me the assignment to follow up on this list.
> >
> > Both Melissa and Anirudh have experience with CoC's, Melissa for the
> SciPy
> > conference and Anirudh in the MXNet community. They're also two of the
> most
> > active current contributors. So it will be great to have them on the
> > committee.
> >
> > We also discussed that it would be good to have at least one current
> member
> > remain, to have one steering council member who knows the project history
> > well on the committee. Both Stefan and I have said that we're happy to
> stay
> > on. So I would suggest that Stefan and I get together and figure out who
> of
> > us that will be. And then we update the website and the CoC committee's
> > private email list.
>

Stefan and I talked about this last week. I'm already wearing a lot of hats
(e.g. web and docs teams, Tidelift and NumFOCUS liaison), and also Melissa
and I are colleagues, so we decided it's better for Stefan to remain on the
CoC committee.

I'll open a PR to update the website. Thanks everyone who is volunteering!

Cheers,
Ralf




> Sounds good.  Thanks Sebastian, Ralf, Anirudh and Melissa!
>
> Warren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200510/a1447a32/attachment.html>

From numpy_gsod at bigriver.xyz  Mon May 11 08:17:13 2020
From: numpy_gsod at bigriver.xyz (Ben Nathanson)
Date: Mon, 11 May 2020 08:17:13 -0400
Subject: [Numpy-discussion] GSoD 2020!
Message-ID: <CAA7-tfhob7EatPVoFDFhoSmUEOML9EbbzbhDfaONZ4Lft-SZdg@mail.gmail.com>

Congratulations on getting chosen once again for Season of Docs!

I'm very eager to talk about collaborating.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200511/378a6b24/attachment.html>

From prubhtejwadhwa at gmail.com  Tue May 12 12:54:54 2020
From: prubhtejwadhwa at gmail.com (PRUBHTEJ SINGH)
Date: Tue, 12 May 2020 22:24:54 +0530
Subject: [Numpy-discussion] Reg: GSoD 2020
Message-ID: <CAH1jWedoX_uteY-4GA9Eh5vp3mtZ5aMfaKrh7MuX051cTjoyVQ@mail.gmail.com>

Greetings
I would like to contribute to numpy's documentation under GSoD-2020
program. Requesting your guidance for the same.
Regards
Prubhtej Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200512/614ba41f/attachment.html>

From sebastian at sipsolutions.net  Tue May 12 13:55:21 2020
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Tue, 12 May 2020 12:55:21 -0500
Subject: [Numpy-discussion] NumPy Community Meeting Wednesday
Message-ID: <55c6b13953661fe4fa0017d5e39e72cc1c624aca.camel@sipsolutions.net>

Hi all,

There will be a NumPy Community meeting Wednesday May 13th 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:

https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both

Best wishes

Sebastian


From themistoklis.spanoudis at gmail.com  Tue May 12 19:02:23 2020
From: themistoklis.spanoudis at gmail.com (Themistoklis Spanoudis)
Date: Wed, 13 May 2020 02:02:23 +0300
Subject: [Numpy-discussion] Google Season of Docs 2020 - New NumPy Community
 Member
Message-ID: <CACy8-wh3W3odhHGXU8YN_cBHZEfcOZbd9WjaRTZUxaaPpzwwKg@mail.gmail.com>

Hello everyone!

I am very excited to introduce myself to the NumPy community!

I am Themistoklis Spanoudis, I come from Greece and I have recently
finished my 5-year (Integrated Masters) Degree in Mechanical Engineering at
Aristotle University of Thessaloniki.

I am very happy to see that NumPy has been selected for Google Season of
Docs 2020, because I love scientific computing and Python and I would
really like to contribute in one of your GSoD projects. Specifically, what
caught my attention is ?Creating high-level documentation, such as
Tutorials and How-Tos, covering topics that are missing from the official
documentation?. I have a pretty clear idea on where I would like to make
this project go, but first let me share a few things about my background.

My first introduction to scientific computing came during the first year of
my studies through a semester course on this topic, based on MATLAB. During
that semester I had a lot of course assignments that eventually got me
hooked with scientific computing. My journey in this area continued with me
getting to know NumPy and Python and choosing a plethora of courses during
the following years of my studies that included computational assignments.
During those years I built programs that range from Structural Finite
Element Analysis, Fatigue Analysis and Lagrangian Dynamics to Statistical
Quality Control, Operations Research and Supply Chain Optimization.

Moreover, last year I completed my Master Thesis during a 6-month full-time
position at Airbus Helicopters in Germany, during which I had the chance to
work on flight trajectory optimization and data-driven flight dynamics
modelling. This involved a lot of scientific programming building
state-space models and defining optimization problems as well as tasks
related to working with a large amount of data such as, cleaning,
filtering, transforming to extract training examples and utilizing them in
various models.

Additionally, last summer I participated in Google Summer of Code 2019 with
AerospaceResearch, which is an international space community helping
realise space exploration. My project involved the development of a
software module to be integrated within a research project tackling
electric propulsion system optimization for small satellites. The module is
responsible for the visualization of genetic algorithm data in order to
extract insights about the evolution process that can be used both to
improve the algorithm and as heuristics by human designers. This project
involved working with evolution data to automatically create static plots
as well as animations that are completely configurable through a
user-readable XML input file. My work along with other advancements in the
research project was published at the 36th International Electric
Propulsion Conference.

On a similar note, last fall I participated in Google Season of Docs 2019
with OpenSCAD, which is a scripting software for creating solid 3D CAD
models. My project involved the creation of a tutorial focused on new
OpenSCAD users. My mentors introduced me to the great presentation ?What
nobody tells you about documentation? by Daniele Procida at PyCon Australia
2017, which was a major influence for my work. Closely following the
guidelines of the presentation for the ?tutorial? type of documentation and
reviewing existing material and references, I developed a hands-on,
follow-along tutorial designed to get new users started with creating their
own models as soon as possible, while gradually introducing more advanced
features and building their confidence by following a steady progression
and a consistent style.

So that was about my background and experience, let me now say a few words
about my plans for this year.

For Google Season of Docs 2020 I would like to work with the NumPy
community to create a more advanced, application-based tutorial that will
serve as the next step to the previous year?s project ?NumPy: the absolute
basics for beginners?. Having gone through most of the currently available
documentation under https://numpy.org/devdocs/index.html as well the
external linked educational material, I believe this project would be a
great addition to the existing documents. It would help new users
understand how NumPy can be used in practice to solve real problems, get
them familiar with more advanced features not referenced in the basic
tutorial and get them ready to work on their own projects.

This tutorial would include step-by-step explanations providing a lot of
context to the users as well as follow-along exercises/challenges. The
topics presented on this tutorial can be focused around scientific
simulation, optimization and data science. In my opinion data science is a
stronger candidate for this purpose, since the same techniques and
methodologies are directly applicable to a wider audience across different
fields, compared to scientific simulation which is more coupled to domain
knowledge and could potentially repel users lacking the relevant
background. The exact presented cases of course is something to be
discussed and adapted to fit the educative flow and the covered material.

In order to avoid this introductory message getting too long and to give
you a practical idea of what I mean by step-by-step, follow-along
explanations as well as by providing context and explaining the thought
process behind doing things a certain way, I would like to link to my work
from Google Summer of Code 2019 and Google Season of Docs 2019.


Google Summer of Code 2019

-Official project listing on Google?s website:
https://summerofcode.withgoogle.com/archive/2019/projects/6650127358361600/

-Final report: https://aerospaceresearch.net/?p=1812

-Blog posts presenting the functionality of the developed module through
example use cases (highly recommended if you are into genetic algorithms):

---Blog post 1: https://aerospaceresearch.net/?p=1542

---Blog post 2: https://aerospaceresearch.net/?p=1571

---Blog post 3: https://aerospaceresearch.net/?p=1785


Google Season of Docs

-Official project listing on Google?s website:
https://developers.google.com/season-of-docs/docs/2019/participants/project-openscad#project_description

-Final report:
https://github.com/s-themis/Google-Season-of-Docs-2019-Project-Report

-Root page of developed tutorial:
https://en.m.wikibooks.org/wiki/OpenSCAD_Tutorial

-Alternative linking to the individual tutorial chapters through OpenSCAD?s
website: https://www.openscad.org/documentation.html


I would also like to add here my 100+ page Master Thesis as an additional
example of my technical writing work but unfortunately it is currently set
confidential by Airbus.


I think this is a good overall introduction to my background, my work and
my intentions regarding working with NumPy to get the discussion going
about the specific project that I would like to complete during this year?s
Google Season of Docs program. I would highly appreciate your input,
feedback, thoughts and comments.

I am looking forward to hearing from you!

Best regards,

Themistoklis Spanoudis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/41d967fe/attachment-0001.html>

From ddavies at bumpsays.com  Wed May 13 01:47:28 2020
From: ddavies at bumpsays.com (Daniel Davies)
Date: Tue, 12 May 2020 22:47:28 -0700
Subject: [Numpy-discussion] NEP 38 - Universal SIMD intrinsics
Message-ID: <CAEkHmAGE2cEim6dN1FMQJ6BCk1o1CXMXEuEh5qR1Fx3Jd1DVrg@mail.gmail.com>

Is clock-throttling of interest here?

It would be really annoying if the code that chooses a macro implementation
has to guess how much power will be consumed by each core.  Or has to
dynamically pick a macro implementation based on the current frequencies of
all the cores.

https://lemire.me/blog/2018/08/13/the-dangers-of-avx-512-throttling-myth-or-reality/

https://lemire.me/blog/2018/09/07/avx-512-when-and-how-to-use-these-new-instructions/

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200512/3815f2ed/attachment.html>

From hmrishavbandyopadhyay at gmail.com  Wed May 13 02:27:50 2020
From: hmrishavbandyopadhyay at gmail.com (Hmrishav Bandyopadhyay)
Date: Wed, 13 May 2020 11:57:50 +0530
Subject: [Numpy-discussion] Application Pre-requisites
Message-ID: <CABFYkW_vR7du=cmQGTutgCquXR_tmUiD4Fbwvr2d24U1Td8D1w@mail.gmail.com>

Hi,

I am Hmrishav Bandyopadhyay, an Undergrad at Jadavpur University, India.

One of the application pre-requisites for applying to GSOD under numpy
require me to have technical writing experience. Being a student, I have
not had any professional technical writing job or internship per-se but I
have been writing tutorials and such in Towards Data Science(Medium) for
some time now, most of which have been curated by the website. Does this
make me eligible for applying to numpy? Any help or pointers would be
highly appreciated.

Link to one such blog for reference --
https://towardsdatascience.com/adversarial-latent-autoencoders-4ce12c0abbdd

Regards,
Hmrishav Bandyopadhyay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/d5bab56d/attachment.html>

From qiyu8f at gmail.com  Wed May 13 08:11:39 2020
From: qiyu8f at gmail.com (ChunLin Fang)
Date: Wed, 13 May 2020 20:11:39 +0800
Subject: [Numpy-discussion] Should I introduce a new friendly and efficient
 way to running and debugging numpy test case?
Message-ID: <CALCcLCFpQR0sgR5VZ8igDr=s+OCy3G26dWcjP02DuGiJLiuqbg@mail.gmail.com>

Hi, everyone!



I'm Qiyu8 <https://github.com/Qiyu8>, Currently, Numpy recommend a command
line method to run test case as demonstrated in Testing Guidelines
<https://numpy.org/devdocs/reference/testing.html#testing-guidelines> ,Which
is heavy and inconvenient, It's also a little painful if test cases can not
debug in a visualize way, I happened to find an easier way to running and
debugging numpy test case as below:

*1.Download VS Code **here <https://code.visualstudio.com/Download>.*

*2.Open numpy source folder. File -> Open Folder.*
[image: image.png]

*3.Install the Python extension from your extensions:*
[image: image.png]

*4.Configuring Tests: Pytest*

The VS Code Python extension supports unit tests as well as *pytest*.
Here's how to enable the framework:

Open *Command Palette (*ctrl +shift +P) and start typing ?python: configure
tests.? It will display a list of available python linters. You can add any
of the settings to your user settings.json file (opened with the *File* >
*Preferences* > *Settings)*

[image: image.png]

Edit the settings.json file like this:

{

    "python.pythonPath": "C:\\Python36\\python.exe",

    "python.linting.pylintEnabled": true,

    "python.linting.enabled": true,

    "python.testing.unittestEnabled": false,

    "python.testing.nosetestsEnabled": false,

    "python.testing.pytestEnabled": true,

    "python.testing.pytestArgs": [

        "./numpy/tests/",

        "./numpy/core/tests/"

    ]

}

Click "Discover Tests"

[image: image.png]

Then you can running and debugging any test case that you want.

[image: image.png]
[image: image.png]

The fallback of this method is that you have to rebuild numpy before
execute testcase if you changed numpy's source code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/c8ff8fe2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 37393 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/c8ff8fe2/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 139766 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/c8ff8fe2/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 103333 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/c8ff8fe2/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 4144 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/c8ff8fe2/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32230 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/c8ff8fe2/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 65449 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/c8ff8fe2/attachment-0011.png>

From melissawm at gmail.com  Wed May 13 08:22:11 2020
From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=)
Date: Wed, 13 May 2020 09:22:11 -0300
Subject: [Numpy-discussion] Application Pre-requisites
In-Reply-To: <CABFYkW_vR7du=cmQGTutgCquXR_tmUiD4Fbwvr2d24U1Td8D1w@mail.gmail.com>
References: <CABFYkW_vR7du=cmQGTutgCquXR_tmUiD4Fbwvr2d24U1Td8D1w@mail.gmail.com>
Message-ID: <CAC7J6VZj8bzDch3=_S2OiX-he8snQP3FVpUoy3EP63e=ORCCDg@mail.gmail.com>

Hello Hmrishav,

Indeed our preference as an organization is to have someone with technical
writing experience, although it doesn't have to be on a professional level.
I'd recommend joining numpy-scipy-gsod at googlegroups.com for more
information on this year's program.

Best,

Melissa

On Wed, May 13, 2020 at 3:29 AM Hmrishav Bandyopadhyay <
hmrishavbandyopadhyay at gmail.com> wrote:

> Hi,
>
> I am Hmrishav Bandyopadhyay, an Undergrad at Jadavpur University, India.
>
> One of the application pre-requisites for applying to GSOD under numpy
> require me to have technical writing experience. Being a student, I have
> not had any professional technical writing job or internship per-se but I
> have been writing tutorials and such in Towards Data Science(Medium) for
> some time now, most of which have been curated by the website. Does this
> make me eligible for applying to numpy? Any help or pointers would be
> highly appreciated.
>
> Link to one such blog for reference --
> https://towardsdatascience.com/adversarial-latent-autoencoders-4ce12c0abbdd
>
> Regards,
> Hmrishav Bandyopadhyay
> _______________________________________________
> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/ea5a74a1/attachment.html>

From einstein.edison at gmail.com  Wed May 13 09:53:45 2020
From: einstein.edison at gmail.com (Hameer Abbasi)
Date: Wed, 13 May 2020 13:53:45 +0000
Subject: [Numpy-discussion] Announcing PyData/Sparse 0.10.0
Message-ID: <AM0PR04MB39869362F3B98F9FC3BC2C67F7BF0@AM0PR04MB3986.eurprd04.prod.outlook.com>

On behalf of the community and contributors, I?m pleased to announce PyData/Sparse v0.10.0.

PyData/Sparse is a package that provides sparse arrays mimicking NumPy API for the PyData ecosystem.

This was a mainly bug-fix focused release with a few features and performance improvements. Most notably, it fixes deprecation warnings that arise when pairing it with Numba v0.49, which will turn into errors with Numba v0.50. The full change-log can be found at https://sparse.pydata.org/en/latest/changelog.html

This version increases the minimum required Numba version to 0.49. We recommend users who can upgrade to Numba 0.49 or later to upgrade to this release. For users who cannot update to this version, we recommend staying with 0.9.x until you can.

Best regards,
Hameer Abbasi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/c16a15e0/attachment.html>

From hmrishavbandyopadhyay at gmail.com  Wed May 13 13:23:24 2020
From: hmrishavbandyopadhyay at gmail.com (Hmrishav Bandyopadhyay)
Date: Wed, 13 May 2020 22:53:24 +0530
Subject: [Numpy-discussion] Application Pre-requisites
In-Reply-To: <CAC7J6VZj8bzDch3=_S2OiX-he8snQP3FVpUoy3EP63e=ORCCDg@mail.gmail.com>
References: <CABFYkW_vR7du=cmQGTutgCquXR_tmUiD4Fbwvr2d24U1Td8D1w@mail.gmail.com>
 <CAC7J6VZj8bzDch3=_S2OiX-he8snQP3FVpUoy3EP63e=ORCCDg@mail.gmail.com>
Message-ID: <CABFYkW_hOUGo1L5kbKtte-JAtbNabnPk5xuoYMSo_Oa7jEBQSQ@mail.gmail.com>

Hi,
I'm sorry but i can't join the Google group--it says an invite is needed :(
Thanks,
Hmrishav Bandyopadhyay

On Wed, 13 May, 2020, 5:53 pm Melissa Mendon?a, <melissawm at gmail.com> wrote:

> Hello Hmrishav,
>
> Indeed our preference as an organization is to have someone with technical
> writing experience, although it doesn't have to be on a professional level.
> I'd recommend joining numpy-scipy-gsod at googlegroups.com for more
> information on this year's program.
>
> Best,
>
> Melissa
>
> On Wed, May 13, 2020 at 3:29 AM Hmrishav Bandyopadhyay <
> hmrishavbandyopadhyay at gmail.com> wrote:
>
>> Hi,
>>
>> I am Hmrishav Bandyopadhyay, an Undergrad at Jadavpur University, India.
>>
>> One of the application pre-requisites for applying to GSOD under numpy
>> require me to have technical writing experience. Being a student, I have
>> not had any professional technical writing job or internship per-se but I
>> have been writing tutorials and such in Towards Data Science(Medium) for
>> some time now, most of which have been curated by the website. Does this
>> make me eligible for applying to numpy? Any help or pointers would be
>> highly appreciated.
>>
>> Link to one such blog for reference --
>>
>> https://towardsdatascience.com/adversarial-latent-autoencoders-4ce12c0abbdd
>>
>> Regards,
>> Hmrishav Bandyopadhyay
>> _______________________________________________
>> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/2ebb3319/attachment.html>

From stefanv at berkeley.edu  Wed May 13 14:10:41 2020
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Wed, 13 May 2020 11:10:41 -0700
Subject: [Numpy-discussion] 
 =?utf-8?q?Google_Season_of_Docs_2020_-_New_Nu?=
 =?utf-8?q?mPy_Community_Member?=
In-Reply-To: <CACy8-wh3W3odhHGXU8YN_cBHZEfcOZbd9WjaRTZUxaaPpzwwKg@mail.gmail.com>
References: <CACy8-wh3W3odhHGXU8YN_cBHZEfcOZbd9WjaRTZUxaaPpzwwKg@mail.gmail.com>
Message-ID: <786f773b-72f4-466f-acba-1bed0eae4cd5@www.fastmail.com>

Hi Themistoklis,

Welcome to the NumPy mailing list! Thank you for the overview of your work. We look forward to the GSoD this year, and I'm excited to see all the enthusiasm for it.

Best regards,
St?fan

On Tue, May 12, 2020, at 16:02, Themistoklis Spanoudis wrote:
> Hello everyone!
> 
> I am very excited to introduce myself to the NumPy community!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/65f026f4/attachment.html>

From ralf.gommers at gmail.com  Wed May 13 14:15:49 2020
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 13 May 2020 20:15:49 +0200
Subject: [Numpy-discussion] Application Pre-requisites
In-Reply-To: <CABFYkW_hOUGo1L5kbKtte-JAtbNabnPk5xuoYMSo_Oa7jEBQSQ@mail.gmail.com>
References: <CABFYkW_vR7du=cmQGTutgCquXR_tmUiD4Fbwvr2d24U1Td8D1w@mail.gmail.com>
 <CAC7J6VZj8bzDch3=_S2OiX-he8snQP3FVpUoy3EP63e=ORCCDg@mail.gmail.com>
 <CABFYkW_hOUGo1L5kbKtte-JAtbNabnPk5xuoYMSo_Oa7jEBQSQ@mail.gmail.com>
Message-ID: <CABL7CQgQmO7DKznTmJRqfvB1v8WS6hHnJ+oj8cdaXtvKdDNiuQ@mail.gmail.com>

On Wed, May 13, 2020 at 7:24 PM Hmrishav Bandyopadhyay <
hmrishavbandyopadhyay at gmail.com> wrote:

> Hi,
> I'm sorry but i can't join the Google group--it says an invite is needed :(
>

Hi Hmrishav, Melissa, it's not a group you can join, it's just a mailing
list where you can interact directly with all the mentors for GSoD.

Cheers,
Ralf


Thanks,
> Hmrishav Bandyopadhyay
>
> On Wed, 13 May, 2020, 5:53 pm Melissa Mendon?a, <melissawm at gmail.com>
> wrote:
>
>> Hello Hmrishav,
>>
>> Indeed our preference as an organization is to have someone with
>> technical writing experience, although it doesn't have to be on a
>> professional level. I'd recommend joining
>> numpy-scipy-gsod at googlegroups.com for more information on this year's
>> program.
>>
>> Best,
>>
>> Melissa
>>
>> On Wed, May 13, 2020 at 3:29 AM Hmrishav Bandyopadhyay <
>> hmrishavbandyopadhyay at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I am Hmrishav Bandyopadhyay, an Undergrad at Jadavpur University, India.
>>>
>>> One of the application pre-requisites for applying to GSOD under numpy
>>> require me to have technical writing experience. Being a student, I have
>>> not had any professional technical writing job or internship per-se but I
>>> have been writing tutorials and such in Towards Data Science(Medium) for
>>> some time now, most of which have been curated by the website. Does this
>>> make me eligible for applying to numpy? Any help or pointers would be
>>> highly appreciated.
>>>
>>> Link to one such blog for reference --
>>>
>>> https://towardsdatascience.com/adversarial-latent-autoencoders-4ce12c0abbdd
>>>
>>> Regards,
>>> Hmrishav Bandyopadhyay
>>> _______________________________________________
>>> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/85d3f511/attachment-0001.html>

From prubhtejwadhwa at gmail.com  Wed May 13 14:24:57 2020
From: prubhtejwadhwa at gmail.com (PRUBHTEJ SINGH)
Date: Wed, 13 May 2020 23:54:57 +0530
Subject: [Numpy-discussion] Reg: GSoD-2020-Participation
Message-ID: <CAH1jWeetaeSavchCEDBVE_=c+HEP_FJ3iiKoTMHopT7COZXXUw@mail.gmail.com>

Greetings,
I am interested in contributing towards NumPy's documentation , but I'm
still a bit confused on where to start.
Request your guidance on the same .Hoping to hear from you soon.
Regards
Prubhtej Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/c049e7fc/attachment.html>

From hmrishavbandyopadhyay at gmail.com  Wed May 13 14:38:28 2020
From: hmrishavbandyopadhyay at gmail.com (Hmrishav Bandyopadhyay)
Date: Thu, 14 May 2020 00:08:28 +0530
Subject: [Numpy-discussion] Application Pre-requisites
In-Reply-To: <CABL7CQgQmO7DKznTmJRqfvB1v8WS6hHnJ+oj8cdaXtvKdDNiuQ@mail.gmail.com>
References: <CABFYkW_vR7du=cmQGTutgCquXR_tmUiD4Fbwvr2d24U1Td8D1w@mail.gmail.com>
 <CAC7J6VZj8bzDch3=_S2OiX-he8snQP3FVpUoy3EP63e=ORCCDg@mail.gmail.com>
 <CABFYkW_hOUGo1L5kbKtte-JAtbNabnPk5xuoYMSo_Oa7jEBQSQ@mail.gmail.com>
 <CABL7CQgQmO7DKznTmJRqfvB1v8WS6hHnJ+oj8cdaXtvKdDNiuQ@mail.gmail.com>
Message-ID: <CABFYkW9eTg8O637BRagZxxiLFB7QKGx+wuQi_8jh4k9KhpFBbw@mail.gmail.com>

Thank you so much for the help! I will introduce myself in the mailing list
and ask for areas in which I can contribute.

On Wed, 13 May, 2020, 11:47 pm Ralf Gommers, <ralf.gommers at gmail.com> wrote:

>
>
> On Wed, May 13, 2020 at 7:24 PM Hmrishav Bandyopadhyay <
> hmrishavbandyopadhyay at gmail.com> wrote:
>
>> Hi,
>> I'm sorry but i can't join the Google group--it says an invite is needed
>> :(
>>
>
> Hi Hmrishav, Melissa, it's not a group you can join, it's just a mailing
> list where you can interact directly with all the mentors for GSoD.
>
> Cheers,
> Ralf
>
>
> Thanks,
>> Hmrishav Bandyopadhyay
>>
>> On Wed, 13 May, 2020, 5:53 pm Melissa Mendon?a, <melissawm at gmail.com>
>> wrote:
>>
>>> Hello Hmrishav,
>>>
>>> Indeed our preference as an organization is to have someone with
>>> technical writing experience, although it doesn't have to be on a
>>> professional level. I'd recommend joining
>>> numpy-scipy-gsod at googlegroups.com for more information on this year's
>>> program.
>>>
>>> Best,
>>>
>>> Melissa
>>>
>>> On Wed, May 13, 2020 at 3:29 AM Hmrishav Bandyopadhyay <
>>> hmrishavbandyopadhyay at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am Hmrishav Bandyopadhyay, an Undergrad at Jadavpur University,
>>>> India.
>>>>
>>>> One of the application pre-requisites for applying to GSOD under numpy
>>>> require me to have technical writing experience. Being a student, I have
>>>> not had any professional technical writing job or internship per-se but I
>>>> have been writing tutorials and such in Towards Data Science(Medium) for
>>>> some time now, most of which have been curated by the website. Does this
>>>> make me eligible for applying to numpy? Any help or pointers would be
>>>> highly appreciated.
>>>>
>>>> Link to one such blog for reference --
>>>>
>>>> https://towardsdatascience.com/adversarial-latent-autoencoders-4ce12c0abbdd
>>>>
>>>> Regards,
>>>> Hmrishav Bandyopadhyay
>>>> _______________________________________________
>>>> 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
>>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200514/9c661c0e/attachment.html>

From melissawm at gmail.com  Wed May 13 15:07:41 2020
From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=)
Date: Wed, 13 May 2020 16:07:41 -0300
Subject: [Numpy-discussion] Application Pre-requisites
In-Reply-To: <CABFYkW9eTg8O637BRagZxxiLFB7QKGx+wuQi_8jh4k9KhpFBbw@mail.gmail.com>
References: <CABFYkW_vR7du=cmQGTutgCquXR_tmUiD4Fbwvr2d24U1Td8D1w@mail.gmail.com>
 <CAC7J6VZj8bzDch3=_S2OiX-he8snQP3FVpUoy3EP63e=ORCCDg@mail.gmail.com>
 <CABFYkW_hOUGo1L5kbKtte-JAtbNabnPk5xuoYMSo_Oa7jEBQSQ@mail.gmail.com>
 <CABL7CQgQmO7DKznTmJRqfvB1v8WS6hHnJ+oj8cdaXtvKdDNiuQ@mail.gmail.com>
 <CABFYkW9eTg8O637BRagZxxiLFB7QKGx+wuQi_8jh4k9KhpFBbw@mail.gmail.com>
Message-ID: <CAC7J6VY7Dbt_=ezUQrtYbpMUBKKRoVkKDC2KqBQ2BQJey8DGCQ@mail.gmail.com>

Sorry, yes, I meant writing to that list.

Thanks!


Em qua, 13 de mai de 2020 15:40, Hmrishav Bandyopadhyay <
hmrishavbandyopadhyay at gmail.com> escreveu:

> Thank you so much for the help! I will introduce myself in the mailing
> list and ask for areas in which I can contribute.
>
> On Wed, 13 May, 2020, 11:47 pm Ralf Gommers, <ralf.gommers at gmail.com>
> wrote:
>
>>
>>
>> On Wed, May 13, 2020 at 7:24 PM Hmrishav Bandyopadhyay <
>> hmrishavbandyopadhyay at gmail.com> wrote:
>>
>>> Hi,
>>> I'm sorry but i can't join the Google group--it says an invite is needed
>>> :(
>>>
>>
>> Hi Hmrishav, Melissa, it's not a group you can join, it's just a mailing
>> list where you can interact directly with all the mentors for GSoD.
>>
>> Cheers,
>> Ralf
>>
>>
>> Thanks,
>>> Hmrishav Bandyopadhyay
>>>
>>> On Wed, 13 May, 2020, 5:53 pm Melissa Mendon?a, <melissawm at gmail.com>
>>> wrote:
>>>
>>>> Hello Hmrishav,
>>>>
>>>> Indeed our preference as an organization is to have someone with
>>>> technical writing experience, although it doesn't have to be on a
>>>> professional level. I'd recommend joining
>>>> numpy-scipy-gsod at googlegroups.com for more information on this year's
>>>> program.
>>>>
>>>> Best,
>>>>
>>>> Melissa
>>>>
>>>> On Wed, May 13, 2020 at 3:29 AM Hmrishav Bandyopadhyay <
>>>> hmrishavbandyopadhyay at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am Hmrishav Bandyopadhyay, an Undergrad at Jadavpur University,
>>>>> India.
>>>>>
>>>>> One of the application pre-requisites for applying to GSOD under numpy
>>>>> require me to have technical writing experience. Being a student, I have
>>>>> not had any professional technical writing job or internship per-se but I
>>>>> have been writing tutorials and such in Towards Data Science(Medium) for
>>>>> some time now, most of which have been curated by the website. Does this
>>>>> make me eligible for applying to numpy? Any help or pointers would be
>>>>> highly appreciated.
>>>>>
>>>>> Link to one such blog for reference --
>>>>>
>>>>> https://towardsdatascience.com/adversarial-latent-autoencoders-4ce12c0abbdd
>>>>>
>>>>> Regards,
>>>>> Hmrishav Bandyopadhyay
>>>>> _______________________________________________
>>>>> 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
>>>
>> _______________________________________________
>> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200513/e26c4cc0/attachment-0001.html>

From aprockhill206 at gmail.com  Fri May 15 13:05:51 2020
From: aprockhill206 at gmail.com (Alex Rockhill)
Date: Fri, 15 May 2020 10:05:51 -0700
Subject: [Numpy-discussion] Histogram or other issues
Message-ID: <CAFOZG0aMys5UoSY3-9kpGUCTQO-UUdNU1+gK1jF-GPyKkqZoqw@mail.gmail.com>

Hey does anyone forsee any issues with histogram or anything else for this
PR: https://github.com/numpy/numpy/pull/16248?
<https://urldefense.com/v3/__https://github.com/numpy/numpy/pull/16248?__;!!C5qS4YX3!U9SpVEnHPkIvbHzEqICz90zZfFhQlzQRy-sb5M8JtKpnMHlD4PDP13hEObhKGh4LOQ$>

Thanks,

Alex Rockhill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200515/c1fe1035/attachment.html>

From siddharthakapoor2 at gmail.com  Fri May 15 14:22:46 2020
From: siddharthakapoor2 at gmail.com (Siddhartha Kapoor)
Date: Fri, 15 May 2020 23:52:46 +0530
Subject: [Numpy-discussion] GSoD Project External tutorial content curation
 and adaptation
Message-ID: <CABPkmU8X2XfjGvmf5DTtgDxwgPncm86FM0LJu_fMF-U=yr2euQ@mail.gmail.com>

I was going through the project titled "External tutorial content curation
and adaptation" with mentors as Melissa Mendonca Weber, Ralf Gommers. I
propose we can do the following -
1. Gather all the info about external tutorials in the form of videos,
blogs, etc. any content that can help a user understand numpy would be
taken.
2. Categorise all the content into different types, i.e. Video, 3rd party
documentation, blogs, etc.
3. Obtain the required permissions to source the content.

After this I am not sure as to how to present it to the larger community,
we can either go about it as, I was thinking of something like this
Add a separate section in the wiki and add all the links along with their
descriptions and what it's about

Any feedback would be appreciated on this.
I am pursuing electronics and communication. I have knowledge of python,
html, css, js and react.js, and I have just started contributing to open
source.

Regards
Siddharth Kapoor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200515/7beb6b4e/attachment.html>

From charlesr.harris at gmail.com  Fri May 15 14:24:55 2020
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Fri, 15 May 2020 12:24:55 -0600
Subject: [Numpy-discussion] NumPy wheels for pypy and aarch64.
Message-ID: <CAB6mnxKDgCv1EH_2q0i8qXD13=KTU7433zF54bumScLfCgNhjQ@mail.gmail.com>

Hi All,

Just a note that NumPy wheels for both pypy and aarch64 are now available
in the nightly builds.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200515/e8cd555b/attachment.html>

From melissawm at gmail.com  Fri May 15 21:22:07 2020
From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=)
Date: Fri, 15 May 2020 22:22:07 -0300
Subject: [Numpy-discussion] Google Season of Docs proposals and information
Message-ID: <CAC7J6Vbc_fwPrd4Fu_HU1tJ6cCz_htQ68QhKR5yKWgp12Ukwdw@mail.gmail.com>

Hello all, especially those who recently joined and are interested in our
Google Season of Docs projects.

It is great to hear from you!

For now, all the 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).


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

I would also recomment that you attend our Documentation Team meeting
taking place next Monday, May 18, at 3PM UTC (more details in a separate
message to follow shortly).

Welcome!

- Melissa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200515/7262e4e4/attachment.html>

From melissawm at gmail.com  Fri May 15 21:25:33 2020
From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=)
Date: Fri, 15 May 2020 22:25:33 -0300
Subject: [Numpy-discussion] Fwd: Documentation Team Meeting - Monday April 27
In-Reply-To: <CAC7J6VbBZDUmKwUDfps+Ueeybc1MsMXKhrju=qYSGGWnp42yVQ@mail.gmail.com>
References: <CAC7J6VapAGeK9a3j=ZARwaBqOh6NB5a1upep+qq6-=AiMN_6UQ@mail.gmail.com>
 <CAC7J6VbBZDUmKwUDfps+Ueeybc1MsMXKhrju=qYSGGWnp42yVQ@mail.gmail.com>
Message-ID: <CAC7J6Vb4-HO7kc+FFGc_yzffaDmvb0kd_pZV0ysVgh+Yxr=4qA@mail.gmail.com>

Hi all!

A reminder that on Monday, May 18, we have another documentation team
meeting at 3PM UTC**. If you wish to join on Zoom, you need to use this
link

https://zoom.us/j/420005230

Here's the permanent hackmd document with the meeting notes:

https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg
<https://www.google.com/url?q=https%3A%2F%2Fhackmd.io%2FoB_boakvRqKR-_2jRV-Qjg&sa=D&usd=2&usg=AFQjCNGIOzVwlfDFd6YAgBwVUjmjQKWRSw>

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=20200518T15&p1=1440&ah=1

- Melissa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200515/b9d3d337/attachment-0001.html>

From prubhtejwadhwa at gmail.com  Sun May 17 15:59:15 2020
From: prubhtejwadhwa at gmail.com (PRUBHTEJ SINGH)
Date: Mon, 18 May 2020 01:29:15 +0530
Subject: [Numpy-discussion] Reg: GSoD project discussion
Message-ID: <CAH1jWedbZGesVikLRkY10HnPMc0EQz7-V42XqRir-97oSv4J6w@mail.gmail.com>

Greetings
I have interest in contributing to the project titled:"High level
restructuring and end user focus".
Kindly request you to guide me for the same .
Hoping to hear from you soon
Regards
Prubhtej Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200518/53cb106f/attachment.html>

From sk.sayakkundu1997 at gmail.com  Mon May 18 09:36:18 2020
From: sk.sayakkundu1997 at gmail.com (Sayak Kundu)
Date: Mon, 18 May 2020 19:06:18 +0530
Subject: [Numpy-discussion] Participation in GSoD 2020
Message-ID: <CAHH=FHUSi_sxVyB-Sp1mbkNR2dQKie9v2NiDjMBWaV4kER5E6Q@mail.gmail.com>

Hi everyone,

I am Sayak Kundu. I am a student at IIIT Hyderabad. This email is regarding
the participation in Google Season of DOcs 2020 as a technical writer. I am
interested in *High-level restructuring and end-user focus*. I have
experience with Numpy and Scipy and have used them across many of my
projects for Multivariate Analysis, Data Science, Machine Learning, etc. I
have also worked with the Internet Archive for past 1 year on their Google
Action and Alexa Skill as a developer and this job also required me to
write technical reports.

I have learnt through the Numpy docs and I want to contribute back by
improving and adding new features to the docs. I would very much like to
know about the steps involved further for contributing to this project.

Sincerely,
Sayak Kundu
sk.sayakkundu1997 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200518/f0d892e4/attachment.html>

From charlesr.harris at gmail.com  Mon May 18 16:10:39 2020
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 18 May 2020 14:10:39 -0600
Subject: [Numpy-discussion] NumPy 1.19. 0rc1 Release
Message-ID: <CAB6mnx+M=wL1PN3-kY+mzFb2NRV0f6BjVs_NK9zpK2kgwu1zyg@mail.gmail.com>

Hi All,

On behalf of the NumPy team I am pleased to announce that NumPy 1.19.0rc1 has
been released. This NumPy release 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
<https://pypi.org/project/numpy/1.19.0rc1/>, source archives and release
notes are available from Github
<https://github.com/numpy/numpy/releases/tag/v1.19.0rc1>.

*Contributors*

A total of 118 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 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
   - Matti Picus
   - Max Balandat +
   - Maximilian Konrad +
   - Maxwell Aladago
   - Maxwell Bileschi +
   - Melissa Weber Mendon?a +
   - Michael Felt
   - 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 +
   - 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
   - Till Hoffmann +
   - Tim Hoffmann
   - Tina Oberoi +
   - Tirth Patel
   - Tyler Reddy
   - Warren Weckesser
   - 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200518/d29e8f89/attachment.html>

From william.ayd at icloud.com  Mon May 18 19:42:04 2020
From: william.ayd at icloud.com (William Ayd)
Date: Mon, 18 May 2020 16:42:04 -0700
Subject: [Numpy-discussion] Using nditer + external_loop to Always
 Iterate by Column
In-Reply-To: <0B618AC3-74AF-4381-ACEB-71C0AF9AD3CD@icloud.com>
References: <0B618AC3-74AF-4381-ACEB-71C0AF9AD3CD@icloud.com>
Message-ID: <43496B45-2172-42A2-82D5-897E6699FD3E@icloud.com>

I am trying to use the nditer to traverse each column of a 2D array, returning the column as a 1D array. Consulting the docs, I found this example which works perfectly fine:

In [65]: a = np.arange(6).reshape(2,3)                                                                                                                             

In [66]: for x in np.nditer(a, flags=['external_loop'], order='F'): 
    ...:     print(x, end=' ') 
    ...:                                                                                                                                                           
[0 3] [1 4] [2 5] 

When changing the shape of the input array to (1, 3) however, this doesn?t yield what I am hoping for any more (essentially [0], [1] [2]):

In [68]: for x in np.nditer(a, flags=['external_loop'], order='F'): 
    ...:     print(x, end=' ') 
    ...:                                                                                                                                                           
[0 1 2] 

I suspect this may have to do with the fact that the (1, 3) array is both C and F contiguous, and it is trying to return as large of a 1D F-contiguous array as it can. However, I didn?t see any way to really force it to go by columns. My best guess was the itershape argument though I couldn?t figure out how to get that to work and didn?t see much in the documentation.

Thanks in advance for the help!

- Will



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200518/14096935/attachment.html>

From albuscode at gmail.com  Tue May 19 02:07:23 2020
From: albuscode at gmail.com (Inessa Pawson)
Date: Tue, 19 May 2020 16:07:23 +1000
Subject: [Numpy-discussion] help translating into Spanish
In-Reply-To: <CAPBcLCEo1p2KG3L9_hZ3UbA7qP-831n4N95JGobDDP_QvRvr=Q@mail.gmail.com>
References: <CAPBcLCEo1p2KG3L9_hZ3UbA7qP-831n4N95JGobDDP_QvRvr=Q@mail.gmail.com>
Message-ID: <CAPBcLCHn5x-oNT+fyHwCM+rzzLQ3LYDWuQAPF9NHm4SOOQzZ4Q@mail.gmail.com>

The initial stage of the NumPy community survey project in partnership with
the students and faculty from the Master?s program in Survey Methodology at
the University of Michigan and the University of Maryland has been
successfully completed. Currently, we are looking for a volunteer to
translate the survey questionnaire into Spanish. If you are available, or
you know someone who would be interested to help, please leave a comment
here: https://github.com/numpy/numpy-surveys/issues/1.
-- 
Every good wish,
*Inessa Pawson *
Executive Director
Albus Code
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200519/ce0ec5a9/attachment-0001.html>

From einstein.edison at gmail.com  Tue May 19 12:01:46 2020
From: einstein.edison at gmail.com (Hameer Abbasi)
Date: Tue, 19 May 2020 16:01:46 +0000
Subject: [Numpy-discussion] Using nditer + external_loop to Always
 Iterate by Column
In-Reply-To: <43496B45-2172-42A2-82D5-897E6699FD3E@icloud.com>
References: <0B618AC3-74AF-4381-ACEB-71C0AF9AD3CD@icloud.com>
 <43496B45-2172-42A2-82D5-897E6699FD3E@icloud.com>
Message-ID: <AM0PR04MB39862CE13479AD3C2C3FFC6BF7B90@AM0PR04MB3986.eurprd04.prod.outlook.com>

Hi William,

You can simply use a for loop for that task:

Python 3.8.2 | packaged by conda-forge | (default, Apr 24 2020, 07:56:27)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.14.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import numpy as np

In [2]: a = np.arange(3).reshape((1, 3))

In [3]: for x in a.T:
   ...:     print(x)
   ...:
[0]
[1]
[2]

Best regards,
Hameer Abbasi

From: NumPy-Discussion <numpy-discussion-bounces+einstein.edison=gmail.com at python.org> on behalf of William Ayd <william.ayd at icloud.com>
Reply to: Discussion of Numerical Python <numpy-discussion at python.org>
Date: Tuesday, 19. May 2020 at 01:42
To: "numpy-discussion at python.org" <numpy-discussion at python.org>
Subject: Re: [Numpy-discussion] Using nditer + external_loop to Always Iterate by Column

I am trying to use the nditer to traverse each column of a 2D array, returning the column as a 1D array. Consulting the docs, I found this example which works perfectly fine:

In [65]: a = np.arange(6).reshape(2,3)

In [66]: for x in np.nditer(a, flags=['external_loop'], order='F'):
    ...:     print(x, end=' ')
    ...:
[0 3] [1 4] [2 5]

When changing the shape of the input array to (1, 3) however, this doesn?t yield what I am hoping for any more (essentially [0], [1] [2]):

In [68]: for x in np.nditer(a, flags=['external_loop'], order='F'):
    ...:     print(x, end=' ')
    ...:
[0 1 2]

I suspect this may have to do with the fact that the (1, 3) array is both C and F contiguous, and it is trying to return as large of a 1D F-contiguous array as it can. However, I didn?t see any way to really force it to go by columns. My best guess was the itershape argument though I couldn?t figure out how to get that to work and didn?t see much in the documentation.

Thanks in advance for the help!

- Will




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200519/98f22687/attachment.html>

From wieser.eric+numpy at gmail.com  Tue May 19 12:11:50 2020
From: wieser.eric+numpy at gmail.com (Eric Wieser)
Date: Tue, 19 May 2020 17:11:50 +0100
Subject: [Numpy-discussion] Using nditer + external_loop to Always
 Iterate by Column
In-Reply-To: <43496B45-2172-42A2-82D5-897E6699FD3E@icloud.com>
References: <0B618AC3-74AF-4381-ACEB-71C0AF9AD3CD@icloud.com>
 <43496B45-2172-42A2-82D5-897E6699FD3E@icloud.com>
Message-ID: <CAL1kJvBNTT5N-mmVE5ZViaL3JyHCp1CB0YkK_7963c5_q5FPgA@mail.gmail.com>

Hi Will,

To force an iteration to run along certain axes, I believe you should be
using `op_axes`. Your diagnosis is correct that `external_loop` is trying
to help you be more optimal, since it's purpose is exactly that:
optimization.

Unfortunately, if you use `op_axes` you'll run into
https://github.com/numpy/numpy/issues/9808.

Eric

On Tue, 19 May 2020 at 00:42, William Ayd <william.ayd at icloud.com> wrote:

> I am trying to use the nditer to traverse each column of a 2D array,
> returning the column as a 1D array. Consulting the docs, I found this
> example which works perfectly fine:
>
> In [*65*]: a = np.arange(6).reshape(2,3)
>
>
>
> In [*66*]: *for* x *in* np.nditer(a, flags=['external_loop'], order='F'):
>     ...:     print(x, end=' ')
>     ...:
>
>
> [0 3] [1 4] [2 5]
>
> When changing the shape of the input array to (1, 3) however, this doesn?t
> yield what I am hoping for any more (essentially [0], [1] [2]):
>
> In [*68*]: *for* x *in* np.nditer(a, flags=['external_loop'], order='F'):
>     ...:     print(x, end=' ')
>     ...:
>
>
> [0 1 2]
>
> I suspect this may have to do with the fact that the (1, 3) array is both
> C and F contiguous, and it is trying to return as large of a 1D
> F-contiguous array as it can. However, I didn?t see any way to really force
> it to go by columns. My best guess was the *itershape* argument though I
> couldn?t figure out how to get that to work and didn?t see much in the
> documentation.
>
> Thanks in advance for the help!
>
> - Will
>
>
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200519/c9ad9f97/attachment-0001.html>

From sebastian at sipsolutions.net  Tue May 19 13:17:11 2020
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Tue, 19 May 2020 12:17:11 -0500
Subject: [Numpy-discussion] Using nditer + external_loop to Always
 Iterate by Column
In-Reply-To: <CAL1kJvBNTT5N-mmVE5ZViaL3JyHCp1CB0YkK_7963c5_q5FPgA@mail.gmail.com>
References: <0B618AC3-74AF-4381-ACEB-71C0AF9AD3CD@icloud.com>
 <43496B45-2172-42A2-82D5-897E6699FD3E@icloud.com>
 <CAL1kJvBNTT5N-mmVE5ZViaL3JyHCp1CB0YkK_7963c5_q5FPgA@mail.gmail.com>
Message-ID: <8518903df29115108060d5a44b7029913f3d71af.camel@sipsolutions.net>

On Tue, 2020-05-19 at 17:11 +0100, Eric Wieser wrote:
> Hi Will,
> 
> To force an iteration to run along certain axes, I believe you should
> be
> using `op_axes`. Your diagnosis is correct that `external_loop` is
> trying
> to help you be more optimal, since it's purpose is exactly that:
> optimization.
> 
> Unfortunately, if you use `op_axes` you'll run into
> https://github.com/numpy/numpy/issues/9808.


Yeah, I do not think what you want is possible with nditer. `op_axes`
allows you to ignore certain axis, but as Eric points out, that
actually ignores that axis entirely. So it acts similar to slicing the
whole axis away.

I previously thought it could be nice to have a new
`arr.iteraxis(axis=None)` command. As a base, it would act like a flat
iter, otherwise iterate the axis listed. Maybe with an additional flag
whether its allowed to optimize iteration order (although from the
python side I expect we do not want to do that by default).

The reason is also that I am not sure I like `arr.flat` and `for subarr
in arr` too much, because the list-of-list like iteration seems only
semi-natural for an N-D array.

- Sebastian


> 
> Eric
> 
> On Tue, 19 May 2020 at 00:42, William Ayd <william.ayd at icloud.com>
> wrote:
> 
> > I am trying to use the nditer to traverse each column of a 2D
> > array,
> > returning the column as a 1D array. Consulting the docs, I found
> > this
> > example which works perfectly fine:
> > 
> > In [*65*]: a = np.arange(6).reshape(2,3)
> > 
> > 
> > 
> > In [*66*]: *for* x *in* np.nditer(a, flags=['external_loop'],
> > order='F'):
> >     ...:     print(x, end=' ')
> >     ...:
> > 
> > 
> > [0 3] [1 4] [2 5]
> > 
> > When changing the shape of the input array to (1, 3) however, this
> > doesn?t
> > yield what I am hoping for any more (essentially [0], [1] [2]):
> > 
> > In [*68*]: *for* x *in* np.nditer(a, flags=['external_loop'],
> > order='F'):
> >     ...:     print(x, end=' ')
> >     ...:
> > 
> > 
> > [0 1 2]
> > 
> > I suspect this may have to do with the fact that the (1, 3) array
> > is both
> > C and F contiguous, and it is trying to return as large of a 1D
> > F-contiguous array as it can. However, I didn?t see any way to
> > really force
> > it to go by columns. My best guess was the *itershape* argument
> > though I
> > couldn?t figure out how to get that to work and didn?t see much in
> > the
> > documentation.
> > 
> > Thanks in advance for the help!
> > 
> > - Will
> > 
> > 
> > 
> > _______________________________________________
> > 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 sebastian at sipsolutions.net  Tue May 19 13:20:57 2020
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Tue, 19 May 2020 12:20:57 -0500
Subject: [Numpy-discussion] NumPy Development Meeting Tomorrow - Triage Focus
Message-ID: <a1e948d26ad21775fb890824b7e6f556a00c60fb.camel@sipsolutions.net>

Hi all,

Our bi-weekly triage-focused NumPy development meeting is tomorrow
(Wednesday, May 20th) 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


From william.ayd at icloud.com  Tue May 19 17:59:39 2020
From: william.ayd at icloud.com (William Ayd)
Date: Tue, 19 May 2020 14:59:39 -0700
Subject: [Numpy-discussion] Using nditer + external_loop to Always
 Iterate by Column
In-Reply-To: <mailman.190.1589904726.27265.numpy-discussion@python.org>
References: <mailman.190.1589904726.27265.numpy-discussion@python.org>
Message-ID: <A562DCF3-689A-442E-96B7-D1C25ED256DF@icloud.com>

Thanks Hameer for the suggestion. I perhaps should have clarified that this is a small example for something larger, where I am iterating over a sequence of arrays, computing some reduction on the first and writing to the second. I am hoping to keep it all contained within one nditer.

Thanks Eric for the suggestion. Notwithstanding the bug that would seem to be promising. I?ll do a little more research and see what I can find.

From lcs2019018 at iiitl.ac.in  Wed May 20 05:46:49 2020
From: lcs2019018 at iiitl.ac.in (Apoorva)
Date: Wed, 20 May 2020 15:16:49 +0530
Subject: [Numpy-discussion] Some details related to project ideas for GSoD
 2020
Message-ID: <5ec4fc88.1c69fb81.74089.6981@mx.google.com>

Dear Sir/Ma?am,
I?m writing to seek information regarding the project ideas for GSoD. As it was mentioned in the ?Project Ideas? that the technical writer can also develop a ?How-to? tutorial, can it be for beginners as well or is NumPy targeting professionals or seasoned developers only? I would be grateful if I could get a reply for the same.
With warm regards,
Apoorva.


Sent from Mail for Windows 10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200520/8add6487/attachment.html>

From melissawm at gmail.com  Wed May 20 12:44:40 2020
From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=)
Date: Wed, 20 May 2020 13:44:40 -0300
Subject: [Numpy-discussion] Some details related to project ideas for
 GSoD 2020
In-Reply-To: <5ec4fc88.1c69fb81.74089.6981@mx.google.com>
References: <5ec4fc88.1c69fb81.74089.6981@mx.google.com>
Message-ID: <CAC7J6VbgnTPL4wazORFoC374cJWWVH+Yn_sZ0rOH=bmpQ4uZ+w@mail.gmail.com>

Hello, Apoorva!

While there are no specific restrictions from google on who can join the
program, NumPy is looking for people with some experience with technical
writing and/or previous experience with NumPy. Since we already have an
"Absolute Beginners" tutorial, we would appreciate if the projects
submitted could cover other content levels as well.

Best,

Melissa

On Wed, May 20, 2020 at 6:48 AM Apoorva <lcs2019018 at iiitl.ac.in> wrote:

> Dear Sir/Ma?am,
>
> I?m writing to seek information regarding the project ideas for GSoD. As
> it was mentioned in the ?Project Ideas? that the technical writer can also
> develop a ?How-to? tutorial, can it be for beginners as well or is NumPy
> targeting professionals or seasoned developers only? I would be grateful if
> I could get a reply for the same.
>
> With warm regards,
>
> Apoorva.
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200520/1a67ce28/attachment.html>

From anirudh2290 at gmail.com  Wed May 20 16:27:40 2020
From: anirudh2290 at gmail.com (Anirudh Subramanian)
Date: Wed, 20 May 2020 13:27:40 -0700
Subject: [Numpy-discussion] Call for Reviewers
Message-ID: <CAFVLAA8WW_HM=G4O1tV5g-hsY5rLrhxFioL0YPEAmFtqHTQb1g@mail.gmail.com>

Hi all,

This topic was brought up in the triage meeting today. Numpy is seeing a
huge surge in the number of PRs (current open PRs: 253) which could means
two things: 1. Increase in volume of incoming PRs 2. Not enough reviewers
to review the PRs.

One thing that was discussed in the meeting was to add a stale label : "61
- Stale" which has already been added by Sebastian.

The community needs some help here and I think you can help irrespective of
your level of experience with the numpy codebase:

1. Experienced numpy developers - To help review PRs for the areas they are
already familiar with.
2. New contributors - Can help tag a stale PR or summarizing a long running
discussing and next or reviewing PRs/triaging issues (for example DOC PRs
should be a good starting point).

Numpy community has been generous with Triage access and if you are
interested in Triaging PRs or Issues, please reply on this thread and a
committer should probably be able to help.

I welcome more inputs on what we should do to reduce the number of open
PRs, and what would help increase contributors or for contributors to do
more reviews.

Anirudh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200520/678592ee/attachment.html>

From mikofski at berkeley.edu  Thu May 21 17:23:55 2020
From: mikofski at berkeley.edu (Dr. Mark Alexander Mikofski PhD)
Date: Thu, 21 May 2020 14:23:55 -0700
Subject: [Numpy-discussion] Call for Reviewers
In-Reply-To: <CAFVLAA8WW_HM=G4O1tV5g-hsY5rLrhxFioL0YPEAmFtqHTQb1g@mail.gmail.com>
References: <CAFVLAA8WW_HM=G4O1tV5g-hsY5rLrhxFioL0YPEAmFtqHTQb1g@mail.gmail.com>
Message-ID: <CAEqRcW3rUxQf9A4De7=LSrsgmxOpsn7GuSEg3+PxTh3UBD4c3g@mail.gmail.com>

Hi all,

I've never reviewed a Numpy PR before, but I have reviewed a (very) few
SciPy PR's. I can help tag stale PR's. Just let me know where should I
start, or what would be most helpful.

Thanks,
Mark

On Wed, May 20, 2020, 1:29 PM Anirudh Subramanian <anirudh2290 at gmail.com>
wrote:

> Hi all,
>
> This topic was brought up in the triage meeting today. Numpy is seeing a
> huge surge in the number of PRs (current open PRs: 253) which could means
> two things: 1. Increase in volume of incoming PRs 2. Not enough reviewers
> to review the PRs.
>
> One thing that was discussed in the meeting was to add a stale label : "61
> - Stale" which has already been added by Sebastian.
>
> The community needs some help here and I think you can help irrespective
> of your level of experience with the numpy codebase:
>
> 1. Experienced numpy developers - To help review PRs for the areas they
> are already familiar with.
> 2. New contributors - Can help tag a stale PR or summarizing a long
> running discussing and next or reviewing PRs/triaging issues (for example
> DOC PRs should be a good starting point).
>
> Numpy community has been generous with Triage access and if you are
> interested in Triaging PRs or Issues, please reply on this thread and a
> committer should probably be able to help.
>
> I welcome more inputs on what we should do to reduce the number of open
> PRs, and what would help increase contributors or for contributors to do
> more reviews.
>
> Anirudh
>
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200521/4765d37e/attachment.html>

From melissawm at gmail.com  Thu May 21 17:57:49 2020
From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=)
Date: Thu, 21 May 2020 18:57:49 -0300
Subject: [Numpy-discussion] Participation in GSoD 2020
In-Reply-To: <CAHH=FHUSi_sxVyB-Sp1mbkNR2dQKie9v2NiDjMBWaV4kER5E6Q@mail.gmail.com>
References: <CAHH=FHUSi_sxVyB-Sp1mbkNR2dQKie9v2NiDjMBWaV4kER5E6Q@mail.gmail.com>
Message-ID: <CAC7J6VasmcGhRnJRc1CkdP2AB7CWXwyjj4XWpYGDoL3wv8C0vQ@mail.gmail.com>

Thanks for your interest in our Google Season of Docs projects. It is great
to hear from you!

For now, all the 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).


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

Please be aware that although the mentors can answer questions and give you
information, **you must write your own project**.

Welcome!

- Melissa

On Mon, May 18, 2020 at 10:37 AM Sayak Kundu <sk.sayakkundu1997 at gmail.com>
wrote:

> Hi everyone,
>
> I am Sayak Kundu. I am a student at IIIT Hyderabad. This email is
> regarding the participation in Google Season of DOcs 2020 as a technical
> writer. I am interested in *High-level restructuring and end-user focus*.
> I have experience with Numpy and Scipy and have used them across many of my
> projects for Multivariate Analysis, Data Science, Machine Learning, etc. I
> have also worked with the Internet Archive for past 1 year on their Google
> Action and Alexa Skill as a developer and this job also required me to
> write technical reports.
>
> I have learnt through the Numpy docs and I want to contribute back by
> improving and adding new features to the docs. I would very much like to
> know about the steps involved further for contributing to this project.
>
> Sincerely,
> Sayak Kundu
> sk.sayakkundu1997 at gmail.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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200521/80ccec5d/attachment.html>

From anirudh2290 at gmail.com  Thu May 21 19:15:12 2020
From: anirudh2290 at gmail.com (Anirudh Subramanian)
Date: Thu, 21 May 2020 16:15:12 -0700
Subject: [Numpy-discussion] Call for Reviewers
In-Reply-To: <CAEqRcW3rUxQf9A4De7=LSrsgmxOpsn7GuSEg3+PxTh3UBD4c3g@mail.gmail.com>
References: <CAFVLAA8WW_HM=G4O1tV5g-hsY5rLrhxFioL0YPEAmFtqHTQb1g@mail.gmail.com>
 <CAEqRcW3rUxQf9A4De7=LSrsgmxOpsn7GuSEg3+PxTh3UBD4c3g@mail.gmail.com>
Message-ID: <CAFVLAA8Jqt4Xj8ybts6YcxRL_XRtVZYEXN2Rsr8TO89P30uUaA@mail.gmail.com>

Thank you for your interest Mark. You can sort by date and go through the
PRs that have been lying around for a while and tag stale if there has been
no response for review comments, or if it needs more work. Also, ping the
author on the PR to see if they want to continue working on the PR if it
has been lying around for a while. There maybe PRs where there have been
not much reviews in which case you can tag it "Ready for Review". If you
have more time, you can also help review one or more of the many open PRs
or triage issues :).

Also, please provide your github id here so that a committer can provide
the triage permissions.

Anirudh

On Thu, May 21, 2020 at 2:24 PM Dr. Mark Alexander Mikofski PhD <
mikofski at berkeley.edu> wrote:

> Hi all,
>
> I've never reviewed a Numpy PR before, but I have reviewed a (very) few
> SciPy PR's. I can help tag stale PR's. Just let me know where should I
> start, or what would be most helpful.
>
> Thanks,
> Mark
>
> On Wed, May 20, 2020, 1:29 PM Anirudh Subramanian <anirudh2290 at gmail.com>
> wrote:
>
>> Hi all,
>>
>> This topic was brought up in the triage meeting today. Numpy is seeing a
>> huge surge in the number of PRs (current open PRs: 253) which could means
>> two things: 1. Increase in volume of incoming PRs 2. Not enough reviewers
>> to review the PRs.
>>
>> One thing that was discussed in the meeting was to add a stale label :
>> "61 - Stale" which has already been added by Sebastian.
>>
>> The community needs some help here and I think you can help irrespective
>> of your level of experience with the numpy codebase:
>>
>> 1. Experienced numpy developers - To help review PRs for the areas they
>> are already familiar with.
>> 2. New contributors - Can help tag a stale PR or summarizing a long
>> running discussing and next or reviewing PRs/triaging issues (for example
>> DOC PRs should be a good starting point).
>>
>> Numpy community has been generous with Triage access and if you are
>> interested in Triaging PRs or Issues, please reply on this thread and a
>> committer should probably be able to help.
>>
>> I welcome more inputs on what we should do to reduce the number of open
>> PRs, and what would help increase contributors or for contributors to do
>> more reviews.
>>
>> Anirudh
>>
>>
>> _______________________________________________
>> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200521/3f90b113/attachment-0001.html>

From mikofski at berkeley.edu  Thu May 21 19:40:38 2020
From: mikofski at berkeley.edu (Dr. Mark Alexander Mikofski PhD)
Date: Thu, 21 May 2020 16:40:38 -0700
Subject: [Numpy-discussion] Call for Reviewers
In-Reply-To: <CAFVLAA8Jqt4Xj8ybts6YcxRL_XRtVZYEXN2Rsr8TO89P30uUaA@mail.gmail.com>
References: <CAFVLAA8WW_HM=G4O1tV5g-hsY5rLrhxFioL0YPEAmFtqHTQb1g@mail.gmail.com>
 <CAEqRcW3rUxQf9A4De7=LSrsgmxOpsn7GuSEg3+PxTh3UBD4c3g@mail.gmail.com>
 <CAFVLAA8Jqt4Xj8ybts6YcxRL_XRtVZYEXN2Rsr8TO89P30uUaA@mail.gmail.com>
Message-ID: <CAEqRcW3duw8GyjjBFH=Em+yrS46MbpSQksJBsxbxN6K7hBat5Q@mail.gmail.com>

Thank you. My GitHub ID is "mikofski"

On Thu, May 21, 2020, 4:16 PM Anirudh Subramanian <anirudh2290 at gmail.com>
wrote:

> Thank you for your interest Mark. You can sort by date and go through the
> PRs that have been lying around for a while and tag stale if there has been
> no response for review comments, or if it needs more work. Also, ping the
> author on the PR to see if they want to continue working on the PR if it
> has been lying around for a while. There maybe PRs where there have been
> not much reviews in which case you can tag it "Ready for Review". If you
> have more time, you can also help review one or more of the many open PRs
> or triage issues :).
>
> Also, please provide your github id here so that a committer can provide
> the triage permissions.
>
> Anirudh
>
> On Thu, May 21, 2020 at 2:24 PM Dr. Mark Alexander Mikofski PhD <
> mikofski at berkeley.edu> wrote:
>
>> Hi all,
>>
>> I've never reviewed a Numpy PR before, but I have reviewed a (very) few
>> SciPy PR's. I can help tag stale PR's. Just let me know where should I
>> start, or what would be most helpful.
>>
>> Thanks,
>> Mark
>>
>> On Wed, May 20, 2020, 1:29 PM Anirudh Subramanian <anirudh2290 at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> This topic was brought up in the triage meeting today. Numpy is seeing a
>>> huge surge in the number of PRs (current open PRs: 253) which could means
>>> two things: 1. Increase in volume of incoming PRs 2. Not enough reviewers
>>> to review the PRs.
>>>
>>> One thing that was discussed in the meeting was to add a stale label :
>>> "61 - Stale" which has already been added by Sebastian.
>>>
>>> The community needs some help here and I think you can help irrespective
>>> of your level of experience with the numpy codebase:
>>>
>>> 1. Experienced numpy developers - To help review PRs for the areas they
>>> are already familiar with.
>>> 2. New contributors - Can help tag a stale PR or summarizing a long
>>> running discussing and next or reviewing PRs/triaging issues (for example
>>> DOC PRs should be a good starting point).
>>>
>>> Numpy community has been generous with Triage access and if you are
>>> interested in Triaging PRs or Issues, please reply on this thread and a
>>> committer should probably be able to help.
>>>
>>> I welcome more inputs on what we should do to reduce the number of open
>>> PRs, and what would help increase contributors or for contributors to do
>>> more reviews.
>>>
>>> Anirudh
>>>
>>>
>>> _______________________________________________
>>> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200521/dc508702/attachment.html>

From albuscode at gmail.com  Thu May 21 21:06:31 2020
From: albuscode at gmail.com (Inessa Pawson)
Date: Fri, 22 May 2020 11:06:31 +1000
Subject: [Numpy-discussion] help translating Hindi into English
Message-ID: <CAPBcLCFhrKZc34kixeXjYknjWSHQLXJf2n=qVfS9GDLb_e_YRA@mail.gmail.com>

The initial stage of the NumPy community survey project in partnership with
the students and faculty from the Master?s program in Survey Methodology at
the University of Michigan and the University of Maryland has been
successfully completed.

Currently, we are looking for a volunteer to help with the back translation
of the Hindi version of the survey questionnaire (Hindi into English). If
you are available, or you know someone who would be interested to help,
please leave a comment here: https://github.com/numpy/numpy-surveys/issues/1
.

-- 
Every good wish,
*Inessa Pawson*
Executive Director
Albus Code
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200522/cd09c2f6/attachment.html>

From qiyu8f at gmail.com  Thu May 21 21:40:43 2020
From: qiyu8f at gmail.com (ChunLin Fang)
Date: Fri, 22 May 2020 09:40:43 +0800
Subject: [Numpy-discussion] Call for Reviewers
Message-ID: <CALCcLCFxyfg0WfXTj0+ytuzayGDVXjM8KKvo0wyYDOuc+cQj9Q@mail.gmail.com>

Hi all,

I've reviewed and submitted several Numpy PRs before, Glad to have the
right to add tags.my github id is Qiyu8 <https://github.com/Qiyu8>.

Thanks,
ChunLin Fang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200522/50bcf095/attachment.html>

From siddharthakapoor2 at gmail.com  Fri May 22 00:48:18 2020
From: siddharthakapoor2 at gmail.com (Siddhartha Kapoor)
Date: Fri, 22 May 2020 10:18:18 +0530
Subject: [Numpy-discussion] help translating Hindi into English
In-Reply-To: <CAPBcLCFhrKZc34kixeXjYknjWSHQLXJf2n=qVfS9GDLb_e_YRA@mail.gmail.com>
References: <CAPBcLCFhrKZc34kixeXjYknjWSHQLXJf2n=qVfS9GDLb_e_YRA@mail.gmail.com>
Message-ID: <CABPkmU-a_7jmXmLWB_D847m30Wo8+4eyyFrf+64GA3JcXXk7jg@mail.gmail.com>

Hey Inessa

I am Siddharth Kapoor, and Hindi is my native language. I feel I can surely
help with this project. Please let me know for any further details since
I'm quite comfortable with Hindi and English.


Regards
Siddharth Kapoor
Senior Undergraduate
Dept of Electronics and Communication Engineering
National Institute of Technology
Karnataka, India


On Fri, May 22, 2020, 6:37 AM Inessa Pawson <albuscode at gmail.com> wrote:

> The initial stage of the NumPy community survey project in partnership
> with the students and faculty from the Master?s program in Survey
> Methodology at the University of Michigan and the University of Maryland
> has been successfully completed.
>
> Currently, we are looking for a volunteer to help with the back
> translation of the Hindi version of the survey questionnaire (Hindi into
> English). If you are available, or you know someone who would be interested
> to help, please leave a comment here:
> https://github.com/numpy/numpy-surveys/issues/1.
>
> --
> Every good wish,
> *Inessa Pawson*
> Executive Director
> Albus Code
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200522/48f33028/attachment-0001.html>

From ralf.gommers at gmail.com  Fri May 22 05:27:53 2020
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Fri, 22 May 2020 11:27:53 +0200
Subject: [Numpy-discussion] Call for Reviewers
In-Reply-To: <CALCcLCFxyfg0WfXTj0+ytuzayGDVXjM8KKvo0wyYDOuc+cQj9Q@mail.gmail.com>
References: <CALCcLCFxyfg0WfXTj0+ytuzayGDVXjM8KKvo0wyYDOuc+cQj9Q@mail.gmail.com>
Message-ID: <CABL7CQh3YD3HrFzwLhSox+0iFAhGNq7xWZZgJUA0HJfWGbah5w@mail.gmail.com>

On Fri, May 22, 2020 at 3:41 AM ChunLin Fang <qiyu8f at gmail.com> wrote:

> Hi all,
>
> I've reviewed and submitted several Numpy PRs before, Glad to have the
> right to add tags.my github id is Qiyu8 <https://github.com/Qiyu8>.
>

Hi ChunLin, thanks for your help! I've sent you an invite to the triage
team.

Best,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200522/b7c0b374/attachment.html>

From matti.picus at gmail.com  Fri May 22 08:13:32 2020
From: matti.picus at gmail.com (Matti Picus)
Date: Fri, 22 May 2020 15:13:32 +0300
Subject: [Numpy-discussion] Call for Reviewers
In-Reply-To: <CAFVLAA8WW_HM=G4O1tV5g-hsY5rLrhxFioL0YPEAmFtqHTQb1g@mail.gmail.com>
References: <CAFVLAA8WW_HM=G4O1tV5g-hsY5rLrhxFioL0YPEAmFtqHTQb1g@mail.gmail.com>
Message-ID: <fcff06b9-34cb-5f1d-de74-698349985bf3@gmail.com>

On 20/5/20 11:27 pm, Anirudh Subramanian wrote:
> Hi all,
>
> This topic was brought up in the triage meeting today. Numpy is seeing 
> a huge surge in the number of PRs (current open PRs: 253) which could 
> means two things: 1. Increase in volume of incoming PRs 2. Not enough 
> reviewers to review the PRs.
>
> One thing that was discussed in the meeting was to add a stale label : 
> "61 - Stale" which has already been added by Sebastian.
>
> The community needs some help here and I think you can help 
> irrespective of your level of experience with the numpy codebase:
>
> 1. Experienced numpy developers - To help review PRs for the areas 
> they are already familiar with.
> 2. New contributors - Can help tag a stale PR or summarizing?a long 
> running discussing and next or reviewing PRs/triaging issues (for 
> example DOC PRs should be a good starting point).
>
> Numpy community has been generous with Triage access and if you are 
> interested in Triaging PRs or Issues, please reply on this thread and 
> a committer should probably be able to help.
>
> I welcome more inputs on what we should do to reduce the number of 
> open PRs, and what would help increase contributors or for 
> contributors to do more reviews.
>
> Anirudh
>

Great initiative, it certainly would be nice to grow the community of 
contributors.


Just to be clear: typically new participants begin commenting on open 
PRs and issues, especially finding issues and PRs that have gone stale 
and can be closed. Anyone can comment on a github issue or PR, no extra 
rights needed. Once they learn their way around the community, the 
codebase, and the process, we can grant triage rights.


Matti


From anirudh2290 at gmail.com  Fri May 22 15:11:29 2020
From: anirudh2290 at gmail.com (Anirudh Subramanian)
Date: Fri, 22 May 2020 12:11:29 -0700
Subject: [Numpy-discussion] Call for Reviewers
In-Reply-To: <fcff06b9-34cb-5f1d-de74-698349985bf3@gmail.com>
References: <CAFVLAA8WW_HM=G4O1tV5g-hsY5rLrhxFioL0YPEAmFtqHTQb1g@mail.gmail.com>
 <fcff06b9-34cb-5f1d-de74-698349985bf3@gmail.com>
Message-ID: <CAFVLAA9NoKQ=0_3cw+Siqz_czbhzLPghtDOR-typ=erJWRZBVg@mail.gmail.com>

Apologies for the wrong message about triage rights earlier and thanks for
the clarification Matti!

On Fri, May 22, 2020 at 5:13 AM Matti Picus <matti.picus at gmail.com> wrote:

> On 20/5/20 11:27 pm, Anirudh Subramanian wrote:
> > Hi all,
> >
> > This topic was brought up in the triage meeting today. Numpy is seeing
> > a huge surge in the number of PRs (current open PRs: 253) which could
> > means two things: 1. Increase in volume of incoming PRs 2. Not enough
> > reviewers to review the PRs.
> >
> > One thing that was discussed in the meeting was to add a stale label :
> > "61 - Stale" which has already been added by Sebastian.
> >
> > The community needs some help here and I think you can help
> > irrespective of your level of experience with the numpy codebase:
> >
> > 1. Experienced numpy developers - To help review PRs for the areas
> > they are already familiar with.
> > 2. New contributors - Can help tag a stale PR or summarizing a long
> > running discussing and next or reviewing PRs/triaging issues (for
> > example DOC PRs should be a good starting point).
> >
> > Numpy community has been generous with Triage access and if you are
> > interested in Triaging PRs or Issues, please reply on this thread and
> > a committer should probably be able to help.
> >
> > I welcome more inputs on what we should do to reduce the number of
> > open PRs, and what would help increase contributors or for
> > contributors to do more reviews.
> >
> > Anirudh
> >
>
> Great initiative, it certainly would be nice to grow the community of
> contributors.
>
>
> Just to be clear: typically new participants begin commenting on open
> PRs and issues, especially finding issues and PRs that have gone stale
> and can be closed. Anyone can comment on a github issue or PR, no extra
> rights needed. Once they learn their way around the community, the
> codebase, and the process, we can grant triage rights.
>
>
> Matti
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200522/88044de4/attachment.html>

From sebastian at sipsolutions.net  Fri May 22 16:13:38 2020
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Fri, 22 May 2020 15:13:38 -0500
Subject: [Numpy-discussion] Is it OK to extend the ndarray structure?
Message-ID: <32e50cc9efcb1e57b9c04d74246eeff459629abc.camel@sipsolutions.net>

Hi all,

just curious, has anyone reservations about extending the ndarray
struct (and the void scalar one)?

The reason is that, I am starting to dislike the way we handle the
buffer interface.
Due to issues with backward compatibility, we cannot use the "right"
way to free the buffer information. Because of that, the way we solve
it is by storing lists of pointers in a dictionary...

To me this seems a bit complicating, and is annoying since it adds a
dictionary lookup overhead to every single array deletion (and
inserting for every buffer creation). Also, it looks a bit like a
memory leak in some cases (although that probably only annoys me and
only when running valgrind).

It seems that it would be much simpler to tag the buffer-info on to the
array object itself. Which, however, would require extending the array
object by a single pointer [1].

Extending is in theory an ABI break if anyone subclasses ndarray from C
(extending the struct) and does not very carefully anticipate the
possibility.  I am not even sure we support that, but its hard to be
sure...

Cheers,

Sebastian


[1] The size difference should not matter IMO, and with cythons
memoryviews buffers are not an uncommon feature in any case, for the
void scalar it is a bit bigger, but they are also very rare. 
(I thought of using weak references, but the CPython API seems not very
fleshed out, or at least not documented, so not sure about that).


From albuscode at gmail.com  Sun May 24 08:10:15 2020
From: albuscode at gmail.com (Inessa Pawson)
Date: Sun, 24 May 2020 22:10:15 +1000
Subject: [Numpy-discussion] new numpy.org is live
Message-ID: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>

The NumPy web team is excited to announce the launch of the newly
redesigned numpy.org. To transform the website into a comprehensive, yet
user-centric, resource of all things NumPy was a primary focus of this
months-long effort. We thank Joe LaChance, Ralf Gommers, Shaloo Shalini,
Shekhar Prasad Rajak, Ross Barnowski, and Mars Lee for their extensive
contributions to the project.

The new site features a curated collection of NumPy related educational
resources for every user level, an overview of the entire Python scientific
computing ecosystem, and several case studies highlighting the importance
of the library to the many advances in scientific research as well as the
industry in recent years. The ?Install? and ?Get Help? pages offer advice
on how to find answers to installation and usage questions, while those who
are looking to connect with others within our large and diverse community
will find the ?Community? page very helpful.

The new website will be updated on a regular basis with news about the
NumPy project development milestones, community initiatives and events.
Visitors are encouraged to explore the website and sign up for the
newsletter.

Next, the NumPy web team will focus on updating graphics and project
identity (a new logo is coming!), adding an installation widget and
translations, better integrating the project documentation via the new
Sphinx theme, and improving the interactive terminal experience. Also, we
are looking to expand our portfolio of case studies and would appreciate
any assistance in this matter.

Best regards,
Inessa Pawson
NumPy web team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200524/1ff9026e/attachment.html>

From deak.andris at gmail.com  Sun May 24 08:18:53 2020
From: deak.andris at gmail.com (Andras Deak)
Date: Sun, 24 May 2020 14:18:53 +0200
Subject: [Numpy-discussion] new numpy.org is live
In-Reply-To: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
References: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
Message-ID: <CAMEWA4OjAqhJjsySJgMoreCUxdzfJTVRTrBNFfbE5pgKM0ekiQ@mail.gmail.com>

Dear Inessa,

The new design looks great, thanks for all the hard work from everyone!
Is there a well-defined channel where we can file potential bug
reports and feature requests for the website? Or do those just go on
the main numpy repo as issues?
Regards,

Andr?s

On Sun, May 24, 2020 at 2:11 PM Inessa Pawson <albuscode at gmail.com> wrote:
>
> The NumPy web team is excited to announce the launch of the newly redesigned numpy.org. To transform the website into a comprehensive, yet user-centric, resource of all things NumPy was a primary focus of this months-long effort. We thank Joe LaChance, Ralf Gommers, Shaloo Shalini, Shekhar Prasad Rajak, Ross Barnowski, and Mars Lee for their extensive contributions to the project.
>
> The new site features a curated collection of NumPy related educational resources for every user level, an overview of the entire Python scientific computing ecosystem, and several case studies highlighting the importance of the library to the many advances in scientific research as well as the industry in recent years. The ?Install? and ?Get Help? pages offer advice on how to find answers to installation and usage questions, while those who are looking to connect with others within our large and diverse community will find the ?Community? page very helpful.
>
> The new website will be updated on a regular basis with news about the NumPy project development milestones, community initiatives and events. Visitors are encouraged to explore the website and sign up for the newsletter.
>
> Next, the NumPy web team will focus on updating graphics and project identity (a new logo is coming!), adding an installation widget and translations, better integrating the project documentation via the new Sphinx theme, and improving the interactive terminal experience. Also, we are looking to expand our portfolio of case studies and would appreciate any assistance in this matter.
>
> Best regards,
> Inessa Pawson
> NumPy web team
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

From ralf.gommers at gmail.com  Sun May 24 08:46:49 2020
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 24 May 2020 14:46:49 +0200
Subject: [Numpy-discussion] new numpy.org is live
In-Reply-To: <CAMEWA4OjAqhJjsySJgMoreCUxdzfJTVRTrBNFfbE5pgKM0ekiQ@mail.gmail.com>
References: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
 <CAMEWA4OjAqhJjsySJgMoreCUxdzfJTVRTrBNFfbE5pgKM0ekiQ@mail.gmail.com>
Message-ID: <CABL7CQggqEU-2Xjvy+-mZFSFrbaobm=P06G8brzeQursdSByvA@mail.gmail.com>

On Sun, May 24, 2020 at 2:19 PM Andras Deak <deak.andris at gmail.com> wrote:

> Dear Inessa,
>
> The new design looks great, thanks for all the hard work from everyone!
> Is there a well-defined channel where we can file potential bug
> reports and feature requests for the website? Or do those just go on
> the main numpy repo as issues?
>

Hi Andr?s, please use https://github.com/numpy/numpy.org/issues

Cheers,
Ralf


Regards,
>
> Andr?s
>
> On Sun, May 24, 2020 at 2:11 PM Inessa Pawson <albuscode at gmail.com> wrote:
> >
> > The NumPy web team is excited to announce the launch of the newly
> redesigned numpy.org. To transform the website into a comprehensive, yet
> user-centric, resource of all things NumPy was a primary focus of this
> months-long effort. We thank Joe LaChance, Ralf Gommers, Shaloo Shalini,
> Shekhar Prasad Rajak, Ross Barnowski, and Mars Lee for their extensive
> contributions to the project.
> >
> > The new site features a curated collection of NumPy related educational
> resources for every user level, an overview of the entire Python scientific
> computing ecosystem, and several case studies highlighting the importance
> of the library to the many advances in scientific research as well as the
> industry in recent years. The ?Install? and ?Get Help? pages offer advice
> on how to find answers to installation and usage questions, while those who
> are looking to connect with others within our large and diverse community
> will find the ?Community? page very helpful.
> >
> > The new website will be updated on a regular basis with news about the
> NumPy project development milestones, community initiatives and events.
> Visitors are encouraged to explore the website and sign up for the
> newsletter.
> >
> > Next, the NumPy web team will focus on updating graphics and project
> identity (a new logo is coming!), adding an installation widget and
> translations, better integrating the project documentation via the new
> Sphinx theme, and improving the interactive terminal experience. Also, we
> are looking to expand our portfolio of case studies and would appreciate
> any assistance in this matter.
> >
> > Best regards,
> > Inessa Pawson
> > NumPy web team
> > _______________________________________________
> > 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200524/0204953c/attachment.html>

From warren.weckesser at gmail.com  Sun May 24 12:59:25 2020
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Sun, 24 May 2020 12:59:25 -0400
Subject: [Numpy-discussion] new numpy.org is live
In-Reply-To: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
References: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
Message-ID: <CAGzF1ufH8GCzWwLvMHiNnBAdZGn_61uwxM5LebuQtPh4D5MP9A@mail.gmail.com>

On 5/24/20, Inessa Pawson <albuscode at gmail.com> wrote:
> The NumPy web team is excited to announce the launch of the newly
> redesigned numpy.org. To transform the website into a comprehensive, yet
> user-centric, resource of all things NumPy was a primary focus of this
> months-long effort. We thank Joe LaChance, Ralf Gommers, Shaloo Shalini,
> Shekhar Prasad Rajak, Ross Barnowski, and Mars Lee for their extensive
> contributions to the project.


Beautiful!  Thanks for all the hard work that went into this fantastic update.

Warren


>
> The new site features a curated collection of NumPy related educational
> resources for every user level, an overview of the entire Python scientific
> computing ecosystem, and several case studies highlighting the importance
> of the library to the many advances in scientific research as well as the
> industry in recent years. The ?Install? and ?Get Help? pages offer advice
> on how to find answers to installation and usage questions, while those who
> are looking to connect with others within our large and diverse community
> will find the ?Community? page very helpful.
>
> The new website will be updated on a regular basis with news about the
> NumPy project development milestones, community initiatives and events.
> Visitors are encouraged to explore the website and sign up for the
> newsletter.
>
> Next, the NumPy web team will focus on updating graphics and project
> identity (a new logo is coming!), adding an installation widget and
> translations, better integrating the project documentation via the new
> Sphinx theme, and improving the interactive terminal experience. Also, we
> are looking to expand our portfolio of case studies and would appreciate
> any assistance in this matter.
>
> Best regards,
> Inessa Pawson
> NumPy web team
>

From waterbug at pangalactic.us  Sun May 24 14:09:17 2020
From: waterbug at pangalactic.us (Stephen Waterbury)
Date: Sun, 24 May 2020 14:09:17 -0400
Subject: [Numpy-discussion] new numpy.org is live
In-Reply-To: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
References: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
Message-ID: <8f7c21bf-ad7e-721b-31aa-32523d9268ac@pangalactic.us>

This is an absolutely beautiful and very informative site!
It is clear all the work and thought that went into it.

So please take the following input as a constructive suggestion
from an outsider -- I am a long-time (30-year) Python user, and
I follow this list but do not regularly use NumPy ... so again,
an "outsider" perspective:

I would prefer to see the beautiful "ECOSYSTEM" section as the
top section of the page, since it is kind of a "gateway" to all
kinds of cool links, etc. -- and it is visually very interesting, as well.

The "features" boxes at the top of the page, while very good
information, are not nearly as "useful" and they are static,
so I would even suggest providing access to them via a
"Features" menu item among the very top items
(i.e., with "Installation", etc.).

Very humbly offered, with thanks for all the beautiful work.

Steve


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200524/337aded9/attachment.html>

From mark.harfouche at gmail.com  Sun May 24 17:07:14 2020
From: mark.harfouche at gmail.com (Mark Harfouche)
Date: Sun, 24 May 2020 17:07:14 -0400
Subject: [Numpy-discussion] new numpy.org is live
In-Reply-To: <8f7c21bf-ad7e-721b-31aa-32523d9268ac@pangalactic.us>
References: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
 <8f7c21bf-ad7e-721b-31aa-32523d9268ac@pangalactic.us>
Message-ID: <CAC=AwPwms-cGVHKNSTGWBz5B9EJzwr7s9svr+rrrbEu-WGZyiQ@mail.gmail.com>

This looks really great!

I love the Ecosystem section at the bottom!

Great job emphasising the importance, and the elegance of the library!

On Sun, May 24, 2020 at 2:20 PM Stephen Waterbury <waterbug at pangalactic.us>
wrote:

> This is an absolutely beautiful and very informative site!
> It is clear all the work and thought that went into it.
>
> So please take the following input as a constructive suggestion
> from an outsider -- I am a long-time (30-year) Python user, and
> I follow this list but do not regularly use NumPy ... so again,
> an "outsider" perspective:
>
> I would prefer to see the beautiful "ECOSYSTEM" section as the
> top section of the page, since it is kind of a "gateway" to all
> kinds of cool links, etc. -- and it is visually very interesting, as well.
>
> The "features" boxes at the top of the page, while very good
> information, are not nearly as "useful" and they are static,
> so I would even suggest providing access to them via a
> "Features" menu item among the very top items
> (i.e., with "Installation", etc.).
>
> Very humbly offered, with thanks for all the beautiful work.
>
> Steve
>
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200524/0408d5d7/attachment.html>

From arj.python at gmail.com  Mon May 25 01:46:36 2020
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Mon, 25 May 2020 09:46:36 +0400
Subject: [Numpy-discussion] new numpy.org is live
In-Reply-To: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
References: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
Message-ID: <CADrxXX=n1c1pjLWW6WzcsFFDEoJBbpivrkgufG91siS7O24EoA@mail.gmail.com>

More than awesome, now i feel that the logo
is a bit outdated.

Kind Regards,


Abdur-Rahmaan Janhangeer

https://www.github.com/Abdur-RahmaanJ

Mauritius

sent from gmail client on Android, that's why the signature is so ugly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200525/5d058255/attachment.html>

From kachine at protonmail.com  Mon May 25 02:14:04 2020
From: kachine at protonmail.com (kikocorreoso)
Date: Mon, 25 May 2020 06:14:04 +0000
Subject: [Numpy-discussion] new numpy.org is live
In-Reply-To: <CADrxXX=n1c1pjLWW6WzcsFFDEoJBbpivrkgufG91siS7O24EoA@mail.gmail.com>
References: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
 <CADrxXX=n1c1pjLWW6WzcsFFDEoJBbpivrkgufG91siS7O24EoA@mail.gmail.com>
Message-ID: <Ci-o1Z7Ihh5NGDhPOyKSIoLPcJa0mXKsTRWdzKy30Q2c-KF8PBfIj5_e1uMJV5tWeEasy1nxkW-d4WRePd6i_d8HwRwCCnK-IV1OEDNAR0A=@protonmail.com>

Hi all,

Great job!! Congratulations.

In the "Ecosystem" -> "Scientific Domains" section, I think the links for "bayesian inference" and "bio informatics" are wrong. The ones in "bayesian inference" should appear in "bio informatics" and vice versa. Also, in the "geographic processing" area appears Numpy.

Kind regards.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

??????? Original Message ???????
On Monday, 25 de May de 2020 7:46, Abdur-Rahmaan Janhangeer <arj.python at gmail.com> wrote:

> More than awesome, now i feel that the logo
> is a bit outdated.
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
>
> https://www.github.com/Abdur-RahmaanJ
>
> Mauritius
>
> sent from gmail client on Android, that's why the signature is so ugly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200525/dfd90c75/attachment-0001.html>

From raceybe at gmail.com  Mon May 25 09:32:28 2020
From: raceybe at gmail.com (Brian Racey)
Date: Mon, 25 May 2020 09:32:28 -0400
Subject: [Numpy-discussion] log of negative real numbers -> RuntimeWarning:
 invalid value encountered in log
Message-ID: <CALJMqhAM_fACX4EbVFY9X4S+SUU-3VvSFgrVNj_417fiyi_QTg@mail.gmail.com>

Why does numpy produce a runtime warning (invalid value encountered in log)
when taking the log of a negative number? I noticed that if you coerce the
argument to complex by adding 0j to the negative number, the expected
result is produced (i.e. ln(-1) = pi*i).

I was surprised I couldn't find a discussion on this, as I would have
expected others to have come across this before. Packages like Matlab
handle negative numbers automatically by doing the complex conversion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200525/08122d0e/attachment.html>

From wieser.eric+numpy at gmail.com  Mon May 25 09:47:45 2020
From: wieser.eric+numpy at gmail.com (Eric Wieser)
Date: Mon, 25 May 2020 14:47:45 +0100
Subject: [Numpy-discussion] log of negative real numbers ->
 RuntimeWarning: invalid value encountered in log
In-Reply-To: <CALJMqhAM_fACX4EbVFY9X4S+SUU-3VvSFgrVNj_417fiyi_QTg@mail.gmail.com>
References: <CALJMqhAM_fACX4EbVFY9X4S+SUU-3VvSFgrVNj_417fiyi_QTg@mail.gmail.com>
Message-ID: <CAL1kJvAfqmyUiAiuxUdmqz9gkwroBnqSjpV906MQB8=H0-a+1g@mail.gmail.com>

One explanation for this behavior is that doing otherwise would be slow.

Consider an array like

arr = np.array([1]*10**6 + [-1])
ret = np.log(arr)

Today, what happens is:

   - The output array is allocated as np.double
   - The input array is iterated over, and log evaluated on each element in
   turn

For what you describe to happen, the behavior would have to be either:

   - The output array is allocated as np.double
   -

   The input array is iterated over, and log evaluated on each element in
   turn
   -

   If any negative element is encountered, allocate a new array as
   np.cdouble, copy all the data over, then continue. This results in the
   whole array being promoted.

or:

   - The input array is iterated over, and checked to see if all the values
   are positive
   -

   The output array is allocated as np.double or np.cdouble based on this
   result
   -

   The input array is iterated over, and log evaluated on each element in
   turn

In either case, you?ve converted a 1-pass iteration to a 2-pass one.

There are static-typing-based explanations for this behavior too, but I?ll
let someone else present one of those.

Eric

On Mon, 25 May 2020 at 14:33, Brian Racey <raceybe at gmail.com> wrote:

> Why does numpy produce a runtime warning (invalid value encountered in
> log) when taking the log of a negative number? I noticed that if you coerce
> the argument to complex by adding 0j to the negative number, the expected
> result is produced (i.e. ln(-1) = pi*i).
>
> I was surprised I couldn't find a discussion on this, as I would have
> expected others to have come across this before. Packages like Matlab
> handle negative numbers automatically by doing the complex conversion.
> _______________________________________________
> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200525/6b27ce54/attachment.html>

From raceybe at gmail.com  Mon May 25 10:09:20 2020
From: raceybe at gmail.com (Brian Racey)
Date: Mon, 25 May 2020 10:09:20 -0400
Subject: [Numpy-discussion] log of negative real numbers ->
 RuntimeWarning: invalid value encountered in log
In-Reply-To: <CAL1kJvAfqmyUiAiuxUdmqz9gkwroBnqSjpV906MQB8=H0-a+1g@mail.gmail.com>
References: <CALJMqhAM_fACX4EbVFY9X4S+SUU-3VvSFgrVNj_417fiyi_QTg@mail.gmail.com>
 <CAL1kJvAfqmyUiAiuxUdmqz9gkwroBnqSjpV906MQB8=H0-a+1g@mail.gmail.com>
Message-ID: <CALJMqhC-+FOJaFdoyQbb1NR9MDvcCOcTi68mGcjSY6EYof6syQ@mail.gmail.com>

Thanks. That is for performance and memory which of course is valid for
most use cases. Would it really be much different than doing type/size
checking of all the np.array arguments to a function to ensure the
appropriate final np.array sizes are allocated? I'm not trying to question
current practice, just trying to understand as performance will eventually
be important to me.

Would a "complex default" mode ever make it into numpy, to behave more like
Matlab and other packages with respect to complex number handling? Sure it
would make it marginally slower if enabled, but it might open the door to
better compatibility when porting code to Python.

On Mon, May 25, 2020 at 9:49 AM Eric Wieser <wieser.eric+numpy at gmail.com>
wrote:

> One explanation for this behavior is that doing otherwise would be slow.
>
> Consider an array like
>
> arr = np.array([1]*10**6 + [-1])
> ret = np.log(arr)
>
> Today, what happens is:
>
>    - The output array is allocated as np.double
>    - The input array is iterated over, and log evaluated on each element
>    in turn
>
> For what you describe to happen, the behavior would have to be either:
>
>    - The output array is allocated as np.double
>    -
>
>    The input array is iterated over, and log evaluated on each element in
>    turn
>    -
>
>    If any negative element is encountered, allocate a new array as
>    np.cdouble, copy all the data over, then continue. This results in the
>    whole array being promoted.
>
> or:
>
>    - The input array is iterated over, and checked to see if all the
>    values are positive
>    -
>
>    The output array is allocated as np.double or np.cdouble based on this
>    result
>    -
>
>    The input array is iterated over, and log evaluated on each element in
>    turn
>
> In either case, you?ve converted a 1-pass iteration to a 2-pass one.
>
> There are static-typing-based explanations for this behavior too, but I?ll
> let someone else present one of those.
>
> Eric
>
> On Mon, 25 May 2020 at 14:33, Brian Racey <raceybe at gmail.com> wrote:
>
>> Why does numpy produce a runtime warning (invalid value encountered in
>> log) when taking the log of a negative number? I noticed that if you coerce
>> the argument to complex by adding 0j to the negative number, the expected
>> result is produced (i.e. ln(-1) = pi*i).
>>
>> I was surprised I couldn't find a discussion on this, as I would have
>> expected others to have come across this before. Packages like Matlab
>> handle negative numbers automatically by doing the complex conversion.
>> _______________________________________________
>> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200525/fd2825e3/attachment-0001.html>

From raceybe at gmail.com  Mon May 25 10:22:28 2020
From: raceybe at gmail.com (Brian Racey)
Date: Mon, 25 May 2020 10:22:28 -0400
Subject: [Numpy-discussion] log of negative real numbers ->
 RuntimeWarning: invalid value encountered in log
In-Reply-To: <CALJMqhC-+FOJaFdoyQbb1NR9MDvcCOcTi68mGcjSY6EYof6syQ@mail.gmail.com>
References: <CALJMqhAM_fACX4EbVFY9X4S+SUU-3VvSFgrVNj_417fiyi_QTg@mail.gmail.com>
 <CAL1kJvAfqmyUiAiuxUdmqz9gkwroBnqSjpV906MQB8=H0-a+1g@mail.gmail.com>
 <CALJMqhC-+FOJaFdoyQbb1NR9MDvcCOcTi68mGcjSY6EYof6syQ@mail.gmail.com>
Message-ID: <CALJMqhDnaOs9u3i89YJks2oxQkm+AiT9fgGYts7iZGrx9QEeDg@mail.gmail.com>

Being relatively new to numpy, I'm learning as I go. Your typing suggestion
helped me come to the conclusion that I need to type and coerce my input
arguments as I'm doing complex math. My test arguments were real, and thus
numpy was producing real results. Doing .astype(np.complex128) to my input
values that are generally complex resolved my issue.

On Mon, May 25, 2020 at 10:09 AM Brian Racey <raceybe at gmail.com> wrote:

> Thanks. That is for performance and memory which of course is valid for
> most use cases. Would it really be much different than doing type/size
> checking of all the np.array arguments to a function to ensure the
> appropriate final np.array sizes are allocated? I'm not trying to question
> current practice, just trying to understand as performance will eventually
> be important to me.
>
> Would a "complex default" mode ever make it into numpy, to behave more
> like Matlab and other packages with respect to complex number handling?
> Sure it would make it marginally slower if enabled, but it might open the
> door to better compatibility when porting code to Python.
>
> On Mon, May 25, 2020 at 9:49 AM Eric Wieser <wieser.eric+numpy at gmail.com>
> wrote:
>
>> One explanation for this behavior is that doing otherwise would be slow.
>>
>> Consider an array like
>>
>> arr = np.array([1]*10**6 + [-1])
>> ret = np.log(arr)
>>
>> Today, what happens is:
>>
>>    - The output array is allocated as np.double
>>    - The input array is iterated over, and log evaluated on each element
>>    in turn
>>
>> For what you describe to happen, the behavior would have to be either:
>>
>>    - The output array is allocated as np.double
>>    -
>>
>>    The input array is iterated over, and log evaluated on each element
>>    in turn
>>    -
>>
>>    If any negative element is encountered, allocate a new array as
>>    np.cdouble, copy all the data over, then continue. This results in
>>    the whole array being promoted.
>>
>> or:
>>
>>    - The input array is iterated over, and checked to see if all the
>>    values are positive
>>    -
>>
>>    The output array is allocated as np.double or np.cdouble based on
>>    this result
>>    -
>>
>>    The input array is iterated over, and log evaluated on each element
>>    in turn
>>
>> In either case, you?ve converted a 1-pass iteration to a 2-pass one.
>>
>> There are static-typing-based explanations for this behavior too, but
>> I?ll let someone else present one of those.
>>
>> Eric
>>
>> On Mon, 25 May 2020 at 14:33, Brian Racey <raceybe at gmail.com> wrote:
>>
>>> Why does numpy produce a runtime warning (invalid value encountered in
>>> log) when taking the log of a negative number? I noticed that if you coerce
>>> the argument to complex by adding 0j to the negative number, the expected
>>> result is produced (i.e. ln(-1) = pi*i).
>>>
>>> I was surprised I couldn't find a discussion on this, as I would have
>>> expected others to have come across this before. Packages like Matlab
>>> handle negative numbers automatically by doing the complex conversion.
>>> _______________________________________________
>>> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200525/d5b09231/attachment.html>

From sebastian at sipsolutions.net  Mon May 25 10:29:52 2020
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Mon, 25 May 2020 09:29:52 -0500
Subject: [Numpy-discussion] log of negative real numbers ->
 RuntimeWarning: invalid value encountered in log
In-Reply-To: <CALJMqhC-+FOJaFdoyQbb1NR9MDvcCOcTi68mGcjSY6EYof6syQ@mail.gmail.com>
References: <CALJMqhAM_fACX4EbVFY9X4S+SUU-3VvSFgrVNj_417fiyi_QTg@mail.gmail.com>
 <CAL1kJvAfqmyUiAiuxUdmqz9gkwroBnqSjpV906MQB8=H0-a+1g@mail.gmail.com>
 <CALJMqhC-+FOJaFdoyQbb1NR9MDvcCOcTi68mGcjSY6EYof6syQ@mail.gmail.com>
Message-ID: <8a860a05c8063e0a6073eb6fab76a00e41a17208.camel@sipsolutions.net>

On Mon, 2020-05-25 at 10:09 -0400, Brian Racey wrote:
> Thanks. That is for performance and memory which of course is valid
> for
> most use cases. Would it really be much different than doing
> type/size
> checking of all the np.array arguments to a function to ensure the
> appropriate final np.array sizes are allocated? I'm not trying to
> question
> current practice, just trying to understand as performance will
> eventually
> be important to me.
> 
> Would a "complex default" mode ever make it into numpy, to behave
> more like
> Matlab and other packages with respect to complex number handling?
> Sure it
> would make it marginally slower if enabled, but it might open the
> door to
> better compatibility when porting code to Python.
> 

I think the SciPy versions may have such a default, or there is such a
functionality hidden somewhere (maybe even the switching behaviour).
I am not sure anyone actually uses those, so it may not be a good idea
to use them to be honest.

The type safety aspects are that you do can get float or complex
results randomly, which of course is fine for much code...

>From my side main argument in favor of the current behaviour is that
you, as someone working with complex numbers, likely immediately knows
that what you want is to use `np.log(..., dtype=...)` or cast the input
to complex.  But someone not used to complex numbers may be very
surprised if they suddenly have a complex result after a long
calculation.

That said, there is a problem here, since it is a bit clumsy to force a
complex result. `np.log(..., dtype=np.complex128)` works, but hard-
codes double precision. `np.log(arr + 0j)` works, but may look strange
(I will assume that `log` is so slow that the overhead is not very
relevant).  I am not sure that if the use case is actually big enough
to worry about it, i.e. if you work with complex numbers, you may be
fine with just converting to complex once early on...

- Sebastian



> On Mon, May 25, 2020 at 9:49 AM Eric Wieser <
> wieser.eric+numpy at gmail.com>
> wrote:
> 
> > One explanation for this behavior is that doing otherwise would be
> > slow.
> > 
> > Consider an array like
> > 
> > arr = np.array([1]*10**6 + [-1])
> > ret = np.log(arr)
> > 
> > Today, what happens is:
> > 
> >    - The output array is allocated as np.double
> >    - The input array is iterated over, and log evaluated on each
> > element
> >    in turn
> > 
> > For what you describe to happen, the behavior would have to be
> > either:
> > 
> >    - The output array is allocated as np.double
> >    -
> > 
> >    The input array is iterated over, and log evaluated on each
> > element in
> >    turn
> >    -
> > 
> >    If any negative element is encountered, allocate a new array as
> >    np.cdouble, copy all the data over, then continue. This results
> > in the
> >    whole array being promoted.
> > 
> > or:
> > 
> >    - The input array is iterated over, and checked to see if all
> > the
> >    values are positive
> >    -
> > 
> >    The output array is allocated as np.double or np.cdouble based
> > on this
> >    result
> >    -
> > 
> >    The input array is iterated over, and log evaluated on each
> > element in
> >    turn
> > 
> > In either case, you?ve converted a 1-pass iteration to a 2-pass
> > one.
> > 
> > There are static-typing-based explanations for this behavior too,
> > but I?ll
> > let someone else present one of those.
> > 
> > Eric
> > 
> > On Mon, 25 May 2020 at 14:33, Brian Racey <raceybe at gmail.com>
> > wrote:
> > 
> > > Why does numpy produce a runtime warning (invalid value
> > > encountered in
> > > log) when taking the log of a negative number? I noticed that if
> > > you coerce
> > > the argument to complex by adding 0j to the negative number, the
> > > expected
> > > result is produced (i.e. ln(-1) = pi*i).
> > > 
> > > I was surprised I couldn't find a discussion on this, as I would
> > > have
> > > expected others to have come across this before. Packages like
> > > Matlab
> > > handle negative numbers automatically by doing the complex
> > > conversion.
> > > _______________________________________________
> > > 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 ralf.gommers at gmail.com  Mon May 25 11:02:58 2020
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 25 May 2020 17:02:58 +0200
Subject: [Numpy-discussion] new numpy.org is live
In-Reply-To: <8f7c21bf-ad7e-721b-31aa-32523d9268ac@pangalactic.us>
References: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
 <8f7c21bf-ad7e-721b-31aa-32523d9268ac@pangalactic.us>
Message-ID: <CABL7CQgryH9=7Zdcsb88f-KKFS2qZv-DXaDFEAO_=4-m+TDMSQ@mail.gmail.com>

On Sun, May 24, 2020 at 8:19 PM Stephen Waterbury <waterbug at pangalactic.us>
wrote:

> This is an absolutely beautiful and very informative site!
> It is clear all the work and thought that went into it.
>
> So please take the following input as a constructive suggestion
> from an outsider -- I am a long-time (30-year) Python user, and
> I follow this list but do not regularly use NumPy ... so again,
> an "outsider" perspective:
>
> I would prefer to see the beautiful "ECOSYSTEM" section as the
> top section of the page, since it is kind of a "gateway" to all
> kinds of cool links, etc. -- and it is visually very interesting, as well.
>
> The "features" boxes at the top of the page, while very good
> information, are not nearly as "useful" and they are static,
> so I would even suggest providing access to them via a
> "Features" menu item among the very top items
> (i.e., with "Installation", etc.).
>
> Very humbly offered, with thanks for all the beautiful work.
>

Thanks for the feedback Steve. I have added your suggestion to
https://github.com/numpy/numpy.org/issues/238.

Our strategy for the next while will be:
1. fix any bugs and correctness issues in content (done for everything
already reported in this thread so far and on Twitter).
2. review remaining open PRs
3. prioritize from the large set of new ideas and already planned
improvements. Tracking issue at
https://github.com/numpy/numpy.org/issues/266

Cheers,
Ralf


Steve
>
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200525/d0292047/attachment-0001.html>

From opossumnano at gmail.com  Mon May 25 11:08:14 2020
From: opossumnano at gmail.com (Tiziano Zito)
Date: Mon, 25 May 2020 17:08:14 +0200
Subject: [Numpy-discussion] log of negative real numbers ->
 RuntimeWarning: invalid value encountered in log
In-Reply-To: <CALJMqhC-+FOJaFdoyQbb1NR9MDvcCOcTi68mGcjSY6EYof6syQ@mail.gmail.com>
References: <CALJMqhAM_fACX4EbVFY9X4S+SUU-3VvSFgrVNj_417fiyi_QTg@mail.gmail.com>
 <CAL1kJvAfqmyUiAiuxUdmqz9gkwroBnqSjpV906MQB8=H0-a+1g@mail.gmail.com>
 <CALJMqhC-+FOJaFdoyQbb1NR9MDvcCOcTi68mGcjSY6EYof6syQ@mail.gmail.com>
Message-ID: <20200525150814.ihezdnd73dudydff@multivac>

>Would a "complex default" mode ever make it into numpy, to behave more like Matlab and other packages with respect to complex number handling? Sure it would make it marginally slower if enabled, but it might open the door to better compatibility when porting code to Python.

numpy already has the "complex default" log function: numpy.lib.scimath.log . There are other useful gems in that module, for example a "complex default" sqrt function

Ciao,
Tiziano

From robert.kern at gmail.com  Mon May 25 11:10:03 2020
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 25 May 2020 11:10:03 -0400
Subject: [Numpy-discussion] log of negative real numbers ->
 RuntimeWarning: invalid value encountered in log
In-Reply-To: <8a860a05c8063e0a6073eb6fab76a00e41a17208.camel@sipsolutions.net>
References: <CALJMqhAM_fACX4EbVFY9X4S+SUU-3VvSFgrVNj_417fiyi_QTg@mail.gmail.com>
 <CAL1kJvAfqmyUiAiuxUdmqz9gkwroBnqSjpV906MQB8=H0-a+1g@mail.gmail.com>
 <CALJMqhC-+FOJaFdoyQbb1NR9MDvcCOcTi68mGcjSY6EYof6syQ@mail.gmail.com>
 <8a860a05c8063e0a6073eb6fab76a00e41a17208.camel@sipsolutions.net>
Message-ID: <CAF6FJisAU9cSc=MpOmeDtOnQE052XSCXbhJySj4zwwRS0b+EQw@mail.gmail.com>

On Mon, May 25, 2020 at 10:36 AM Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> On Mon, 2020-05-25 at 10:09 -0400, Brian Racey wrote:
> > Would a "complex default" mode ever make it into numpy, to behave
> > more like
> > Matlab and other packages with respect to complex number handling?
> > Sure it
> > would make it marginally slower if enabled, but it might open the
> > door to
> > better compatibility when porting code to Python.
> >
>
> I think the SciPy versions may have such a default, or there is such a
> functionality hidden somewhere (maybe even the switching behaviour).
> I am not sure anyone actually uses those, so it may not be a good idea
> to use them to be honest.
>

The versions in `np.lib.scimath` behave like this. Of course, people do use
them when they want to deal with real numbers as subsets of the complex
numbers.

-- 
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200525/137c0acd/attachment.html>

From sebastian at sipsolutions.net  Mon May 25 11:16:30 2020
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Mon, 25 May 2020 10:16:30 -0500
Subject: [Numpy-discussion] log of negative real numbers ->
 RuntimeWarning: invalid value encountered in log
In-Reply-To: <CAF6FJisAU9cSc=MpOmeDtOnQE052XSCXbhJySj4zwwRS0b+EQw@mail.gmail.com>
References: <CALJMqhAM_fACX4EbVFY9X4S+SUU-3VvSFgrVNj_417fiyi_QTg@mail.gmail.com>
 <CAL1kJvAfqmyUiAiuxUdmqz9gkwroBnqSjpV906MQB8=H0-a+1g@mail.gmail.com>
 <CALJMqhC-+FOJaFdoyQbb1NR9MDvcCOcTi68mGcjSY6EYof6syQ@mail.gmail.com>
 <8a860a05c8063e0a6073eb6fab76a00e41a17208.camel@sipsolutions.net>
 <CAF6FJisAU9cSc=MpOmeDtOnQE052XSCXbhJySj4zwwRS0b+EQw@mail.gmail.com>
Message-ID: <eb46eea4d5f29118e25b4af497d2682d896b581c.camel@sipsolutions.net>

On Mon, 2020-05-25 at 11:10 -0400, Robert Kern wrote:
> On Mon, May 25, 2020 at 10:36 AM Sebastian Berg <
> sebastian at sipsolutions.net>
> wrote:
> 
> > On Mon, 2020-05-25 at 10:09 -0400, Brian Racey wrote:
> > > Would a "complex default" mode ever make it into numpy, to behave
> > > more like
> > > Matlab and other packages with respect to complex number
> > > handling?
> > > Sure it
> > > would make it marginally slower if enabled, but it might open the
> > > door to
> > > better compatibility when porting code to Python.
> > > 
> > 
> > I think the SciPy versions may have such a default, or there is
> > such a
> > functionality hidden somewhere (maybe even the switching
> > behaviour).
> > I am not sure anyone actually uses those, so it may not be a good
> > idea
> > to use them to be honest.
> > 
> 
> The versions in `np.lib.scimath` behave like this. Of course, people
> do use
> them when they want to deal with real numbers as subsets of the
> complex
> numbers.
> 

True, I guess I just used complex numbers too rarely in programs (i.e.
never central to any programming project).

It seems this is actually also exposed as `np.emath`, which is maybe a
better entry point? And I guess the scipy namespace uses them.

- Sebastian

> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion



From raceybe at gmail.com  Mon May 25 11:21:27 2020
From: raceybe at gmail.com (Brian Racey)
Date: Mon, 25 May 2020 11:21:27 -0400
Subject: [Numpy-discussion] log of negative real numbers ->
 RuntimeWarning: invalid value encountered in log
In-Reply-To: <eb46eea4d5f29118e25b4af497d2682d896b581c.camel@sipsolutions.net>
References: <CALJMqhAM_fACX4EbVFY9X4S+SUU-3VvSFgrVNj_417fiyi_QTg@mail.gmail.com>
 <CAL1kJvAfqmyUiAiuxUdmqz9gkwroBnqSjpV906MQB8=H0-a+1g@mail.gmail.com>
 <CALJMqhC-+FOJaFdoyQbb1NR9MDvcCOcTi68mGcjSY6EYof6syQ@mail.gmail.com>
 <8a860a05c8063e0a6073eb6fab76a00e41a17208.camel@sipsolutions.net>
 <CAF6FJisAU9cSc=MpOmeDtOnQE052XSCXbhJySj4zwwRS0b+EQw@mail.gmail.com>
 <eb46eea4d5f29118e25b4af497d2682d896b581c.camel@sipsolutions.net>
Message-ID: <CALJMqhAvV1E+grMLFUZASKWrD8TWxC89Nv0_BJ_awLoy-5MPeQ@mail.gmail.com>

My Googling revealed none of this. I don't have anyone to talk to about
using numpy, so Google (and this group) is all I have. This was extremely
useful: https://numpy.org/devdocs/user/numpy-for-matlab-users.html so
perhaps it could be extended to point out those modules and entry points if
it isn't documented elsewhere.

On Mon, May 25, 2020 at 11:17 AM Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> On Mon, 2020-05-25 at 11:10 -0400, Robert Kern wrote:
> > On Mon, May 25, 2020 at 10:36 AM Sebastian Berg <
> > sebastian at sipsolutions.net>
> > wrote:
> >
> > > On Mon, 2020-05-25 at 10:09 -0400, Brian Racey wrote:
> > > > Would a "complex default" mode ever make it into numpy, to behave
> > > > more like
> > > > Matlab and other packages with respect to complex number
> > > > handling?
> > > > Sure it
> > > > would make it marginally slower if enabled, but it might open the
> > > > door to
> > > > better compatibility when porting code to Python.
> > > >
> > >
> > > I think the SciPy versions may have such a default, or there is
> > > such a
> > > functionality hidden somewhere (maybe even the switching
> > > behaviour).
> > > I am not sure anyone actually uses those, so it may not be a good
> > > idea
> > > to use them to be honest.
> > >
> >
> > The versions in `np.lib.scimath` behave like this. Of course, people
> > do use
> > them when they want to deal with real numbers as subsets of the
> > complex
> > numbers.
> >
>
> True, I guess I just used complex numbers too rarely in programs (i.e.
> never central to any programming project).
>
> It seems this is actually also exposed as `np.emath`, which is maybe a
> better entry point? And I guess the scipy namespace uses them.
>
> - Sebastian
>
> > _______________________________________________
> > 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200525/d2423f96/attachment.html>

From ilhanpolat at gmail.com  Mon May 25 11:23:32 2020
From: ilhanpolat at gmail.com (Ilhan Polat)
Date: Mon, 25 May 2020 17:23:32 +0200
Subject: [Numpy-discussion] log of negative real numbers ->
 RuntimeWarning: invalid value encountered in log
In-Reply-To: <eb46eea4d5f29118e25b4af497d2682d896b581c.camel@sipsolutions.net>
References: <CALJMqhAM_fACX4EbVFY9X4S+SUU-3VvSFgrVNj_417fiyi_QTg@mail.gmail.com>
 <CAL1kJvAfqmyUiAiuxUdmqz9gkwroBnqSjpV906MQB8=H0-a+1g@mail.gmail.com>
 <CALJMqhC-+FOJaFdoyQbb1NR9MDvcCOcTi68mGcjSY6EYof6syQ@mail.gmail.com>
 <8a860a05c8063e0a6073eb6fab76a00e41a17208.camel@sipsolutions.net>
 <CAF6FJisAU9cSc=MpOmeDtOnQE052XSCXbhJySj4zwwRS0b+EQw@mail.gmail.com>
 <eb46eea4d5f29118e25b4af497d2682d896b581c.camel@sipsolutions.net>
Message-ID: <CAEBuzr_OA8C_yhGaPHxE9a6T_BWVs3COrWJaf37Pv0hrZSbOsw@mail.gmail.com>

I wasted a good 2 weeks because of that behavior of Matlab back in the day
and I think that is one of the cardinal sins that matlab commits. If need
be there are alternatives as mentioned before but I definitely do not
prefer this coercion at all.

On Mon, May 25, 2020 at 5:18 PM Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> On Mon, 2020-05-25 at 11:10 -0400, Robert Kern wrote:
> > On Mon, May 25, 2020 at 10:36 AM Sebastian Berg <
> > sebastian at sipsolutions.net>
> > wrote:
> >
> > > On Mon, 2020-05-25 at 10:09 -0400, Brian Racey wrote:
> > > > Would a "complex default" mode ever make it into numpy, to behave
> > > > more like
> > > > Matlab and other packages with respect to complex number
> > > > handling?
> > > > Sure it
> > > > would make it marginally slower if enabled, but it might open the
> > > > door to
> > > > better compatibility when porting code to Python.
> > > >
> > >
> > > I think the SciPy versions may have such a default, or there is
> > > such a
> > > functionality hidden somewhere (maybe even the switching
> > > behaviour).
> > > I am not sure anyone actually uses those, so it may not be a good
> > > idea
> > > to use them to be honest.
> > >
> >
> > The versions in `np.lib.scimath` behave like this. Of course, people
> > do use
> > them when they want to deal with real numbers as subsets of the
> > complex
> > numbers.
> >
>
> True, I guess I just used complex numbers too rarely in programs (i.e.
> never central to any programming project).
>
> It seems this is actually also exposed as `np.emath`, which is maybe a
> better entry point? And I guess the scipy namespace uses them.
>
> - Sebastian
>
> > _______________________________________________
> > 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200525/346523a1/attachment-0001.html>

From robert.kern at gmail.com  Mon May 25 11:34:33 2020
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 25 May 2020 11:34:33 -0400
Subject: [Numpy-discussion] log of negative real numbers ->
 RuntimeWarning: invalid value encountered in log
In-Reply-To: <eb46eea4d5f29118e25b4af497d2682d896b581c.camel@sipsolutions.net>
References: <CALJMqhAM_fACX4EbVFY9X4S+SUU-3VvSFgrVNj_417fiyi_QTg@mail.gmail.com>
 <CAL1kJvAfqmyUiAiuxUdmqz9gkwroBnqSjpV906MQB8=H0-a+1g@mail.gmail.com>
 <CALJMqhC-+FOJaFdoyQbb1NR9MDvcCOcTi68mGcjSY6EYof6syQ@mail.gmail.com>
 <8a860a05c8063e0a6073eb6fab76a00e41a17208.camel@sipsolutions.net>
 <CAF6FJisAU9cSc=MpOmeDtOnQE052XSCXbhJySj4zwwRS0b+EQw@mail.gmail.com>
 <eb46eea4d5f29118e25b4af497d2682d896b581c.camel@sipsolutions.net>
Message-ID: <CAF6FJita6A-JFKUk55C9F10RAB_Osr3nV7st7rrvgJjn0N=mOw@mail.gmail.com>

On Mon, May 25, 2020 at 11:17 AM Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> On Mon, 2020-05-25 at 11:10 -0400, Robert Kern wrote:
> > On Mon, May 25, 2020 at 10:36 AM Sebastian Berg <
> > sebastian at sipsolutions.net>
> > wrote:
> >
> > > On Mon, 2020-05-25 at 10:09 -0400, Brian Racey wrote:
> > > > Would a "complex default" mode ever make it into numpy, to behave
> > > > more like
> > > > Matlab and other packages with respect to complex number
> > > > handling?
> > > > Sure it
> > > > would make it marginally slower if enabled, but it might open the
> > > > door to
> > > > better compatibility when porting code to Python.
> > > >
> > >
> > > I think the SciPy versions may have such a default, or there is
> > > such a
> > > functionality hidden somewhere (maybe even the switching
> > > behaviour).
> > > I am not sure anyone actually uses those, so it may not be a good
> > > idea
> > > to use them to be honest.
> > >
> >
> > The versions in `np.lib.scimath` behave like this. Of course, people
> > do use
> > them when they want to deal with real numbers as subsets of the
> > complex
> > numbers.
> >
>
> True, I guess I just used complex numbers too rarely in programs (i.e.
> never central to any programming project).
>
> It seems this is actually also exposed as `np.emath`, which is maybe a
> better entry point? And I guess the scipy namespace uses them.
>

Ah, yes, that's the preferred alias, though the documentation page for it
seems to be a little buggy (using `np.lib.scimath` instead `np.emath`;
telling you to look at the docstrings for the individual functions, but
they don't exist in the documentation).

-- 
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200525/939e6798/attachment.html>

From teoliphant at gmail.com  Mon May 25 16:45:31 2020
From: teoliphant at gmail.com (Travis Oliphant)
Date: Mon, 25 May 2020 15:45:31 -0500
Subject: [Numpy-discussion] new numpy.org is live
In-Reply-To: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
References: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
Message-ID: <CAFMmPGNeYqWMWvE3skYK2NDq5dJ2Gan7N4okubQzGS6PvvXfZw@mail.gmail.com>

This is so excellent!  What a wonderful upgrade to the web-page.

Thank you for all the hard work and effort!

-Travis


On Sun, May 24, 2020 at 7:12 AM Inessa Pawson <albuscode at gmail.com> wrote:

> The NumPy web team is excited to announce the launch of the newly
> redesigned numpy.org. To transform the website into a comprehensive, yet
> user-centric, resource of all things NumPy was a primary focus of this
> months-long effort. We thank Joe LaChance, Ralf Gommers, Shaloo Shalini,
> Shekhar Prasad Rajak, Ross Barnowski, and Mars Lee for their extensive
> contributions to the project.
>
> The new site features a curated collection of NumPy related educational
> resources for every user level, an overview of the entire Python scientific
> computing ecosystem, and several case studies highlighting the importance
> of the library to the many advances in scientific research as well as the
> industry in recent years. The ?Install? and ?Get Help? pages offer advice
> on how to find answers to installation and usage questions, while those who
> are looking to connect with others within our large and diverse community
> will find the ?Community? page very helpful.
>
> The new website will be updated on a regular basis with news about the
> NumPy project development milestones, community initiatives and events.
> Visitors are encouraged to explore the website and sign up for the
> newsletter.
>
> Next, the NumPy web team will focus on updating graphics and project
> identity (a new logo is coming!), adding an installation widget and
> translations, better integrating the project documentation via the new
> Sphinx theme, and improving the interactive terminal experience. Also, we
> are looking to expand our portfolio of case studies and would appreciate
> any assistance in this matter.
>
> Best regards,
> Inessa Pawson
> NumPy web team
> _______________________________________________
> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200525/01a20401/attachment.html>

From sebastian at sipsolutions.net  Tue May 26 12:58:48 2020
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Tue, 26 May 2020 11:58:48 -0500
Subject: [Numpy-discussion] NumPy Community Meeting Wednesday
Message-ID: <f17964492f437adfd0399313aad1d8a25a98b29d.camel@sipsolutions.net>

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:

https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both

Best wishes

Sebastian


From pwang at anaconda.com  Tue May 26 15:55:12 2020
From: pwang at anaconda.com (Peter Wang)
Date: Tue, 26 May 2020 14:55:12 -0500
Subject: [Numpy-discussion] new numpy.org is live
In-Reply-To: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
References: <CAPBcLCFC_5EF+QYpBLZTDe5GXEF9t=+KKBdyOQXHungWBr6Tzg@mail.gmail.com>
Message-ID: <CABGrp+_xwmCnTYfiC9rRnAmJmMT7oeP+5tanfBWYX3HM7y5=KQ@mail.gmail.com>

The new site looks really, really nice.  Thank you all for your hard work
on this.  I think this will serve the community well for a long time to
come!

-Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200526/b8907b11/attachment.html>

From ralf.gommers at gmail.com  Wed May 27 12:36:58 2020
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 27 May 2020 18:36:58 +0200
Subject: [Numpy-discussion] Is it OK to extend the ndarray structure?
In-Reply-To: <32e50cc9efcb1e57b9c04d74246eeff459629abc.camel@sipsolutions.net>
References: <32e50cc9efcb1e57b9c04d74246eeff459629abc.camel@sipsolutions.net>
Message-ID: <CABL7CQi8C-0RYVGzxFR5DspyRKOprcH9qi_8vnu=eTSuBq7Qrg@mail.gmail.com>

On Fri, May 22, 2020 at 10:14 PM Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> Hi all,
>
> just curious, has anyone reservations about extending the ndarray
> struct (and the void scalar one)?
>
> The reason is that, I am starting to dislike the way we handle the
> buffer interface.
> Due to issues with backward compatibility, we cannot use the "right"
> way to free the buffer information. Because of that, the way we solve
> it is by storing lists of pointers in a dictionary...
>
> To me this seems a bit complicating, and is annoying since it adds a
> dictionary lookup overhead to every single array deletion (and
> inserting for every buffer creation). Also, it looks a bit like a
> memory leak in some cases (although that probably only annoys me and
> only when running valgrind).
>
> It seems that it would be much simpler to tag the buffer-info on to the
> array object itself. Which, however, would require extending the array
> object by a single pointer [1].
>
> Extending is in theory an ABI break if anyone subclasses ndarray from C
> (extending the struct) and does not very carefully anticipate the
> possibility.  I am not even sure we support that, but its hard to be
> sure...
>

I had no idea if we support that, so I crowdsourced some inputs.

Feedback from Travis: "I would be quite sure there are extensions out there
that do this.  Please just break the ABI and change the version number to
do that."

Feedback from Pearu: "ndarray itself (PyArrayObject) is a kind-of subclass
of PyObject. See https://www.python.org/dev/peps/pep-0253.  Something like
the following might work:

typedef struct {
  PyArrayObject super;
  /* insert extensions here */
} MyPyArrayObject;

"

Cheers,
Ralf



> Cheers,
>
> Sebastian
>
>
> [1] The size difference should not matter IMO, and with cythons
> memoryviews buffers are not an uncommon feature in any case, for the
> void scalar it is a bit bigger, but they are also very rare.
> (I thought of using weak references, but the CPython API seems not very
> fleshed out, or at least not documented, so not sure about that).
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200527/685f4250/attachment.html>

From sebastian at sipsolutions.net  Wed May 27 15:10:01 2020
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Wed, 27 May 2020 14:10:01 -0500
Subject: [Numpy-discussion] Is it OK to extend the ndarray structure?
In-Reply-To: <CABL7CQi8C-0RYVGzxFR5DspyRKOprcH9qi_8vnu=eTSuBq7Qrg@mail.gmail.com>
References: <32e50cc9efcb1e57b9c04d74246eeff459629abc.camel@sipsolutions.net>
 <CABL7CQi8C-0RYVGzxFR5DspyRKOprcH9qi_8vnu=eTSuBq7Qrg@mail.gmail.com>
Message-ID: <e11029cde074a49bab3454da66a46f28f91c992b.camel@sipsolutions.net>

On Wed, 2020-05-27 at 18:36 +0200, Ralf Gommers wrote:
> On Fri, May 22, 2020 at 10:14 PM Sebastian Berg <
> sebastian at sipsolutions.net>
> wrote:
<snip>
> 
> I had no idea if we support that, so I crowdsourced some inputs.
> 
> Feedback from Travis: "I would be quite sure there are extensions out
> there
> that do this.  Please just break the ABI and change the version
> number to
> do that."
> 
> Feedback from Pearu: "ndarray itself (PyArrayObject) is a kind-of
> subclass
> of PyObject. See https://www.python.org/dev/peps/pep-0253.  Something
> like
> the following might work:
> 
> typedef struct {
>   PyArrayObject super;
>   /* insert extensions here */
> } MyPyArrayObject;
> 
> "

Yes, it is a break if someone subclasses from C (or probably Cython)
without being very careful (and we do not help with it well right now).

But, the ABI break is very mild in the sense that it is very easy to
recompile such a library to be compatible with *both* old and new
versions [1]. And I still think that it will be super rare (which I
would love to check [2]).

In either case, though, I am pretty convinced for a long time now, that
a major version is becoming more and more something we should simply
do.
And making 1.20 a 2.0 release will have many good reasons aside from
such a ABI break (and if it is just that we are expecting a lot of code
churn both due to SIMD and changes in the core).

To be clear, I personally do *not* like to aim for a serious ABI break.
The vast majority of libraries should not require recompilation, and
IMO it must be easy to create a single binary compatible with both old
and new versions.
If someone wants to aim for a real ABI break, I would be interested to
see the thoughts on feasibility, but to me that simply feels like
aiming high. And I am not sure there is much gain?
But a small wave of C-API deprecation and small, technically
incompatible, changes that most uses will never notice, does seem
plausible to me.

Cheers,

Sebastian


[1]  You simply have to manually include the larger struct (or we
update our headers). The only annoyance is that the crashes/errors that
happen if you run a non-recompiled/old version against a new NumPy
version may be pretty random.

[2] I would also like to do an anaconda or PIP search to sieve through
actual code and see that while it may technically be an ABI break, it
will affect practically no largish libraries... (i.e. large enough to
land in Anaconda)
If anyone knows how to do that best, I would be interested.


> 
> Cheers,
> Ralf
> 
> 
> 
> > Cheers,
> > 
> > Sebastian
> > 
> > 
> > [1] The size difference should not matter IMO, and with cythons
> > memoryviews buffers are not an uncommon feature in any case, for
> > the
> > void scalar it is a bit bigger, but they are also very rare.
> > (I thought of using weak references, but the CPython API seems not
> > very
> > fleshed out, or at least not documented, so not sure about that).
> > 
> > _______________________________________________
> > 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 madicken.munk at gmail.com  Thu May 28 01:18:05 2020
From: madicken.munk at gmail.com (Madicken Munk)
Date: Thu, 28 May 2020 00:18:05 -0500
Subject: [Numpy-discussion] Reminder: June 01 Deadline for the 2020 John
 Hunter Excellence in Plotting contest!
Message-ID: <CACZp+DEOgTkRbW+-xngGW7gUy+c2+eC-mwuO-y4h7zzjjsKLgQ@mail.gmail.com>

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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200528/2af053ba/attachment-0001.html>

From ryan.c.cooper at uconn.edu  Fri May 29 17:07:58 2020
From: ryan.c.cooper at uconn.edu (Cooper, Ryan)
Date: Fri, 29 May 2020 21:07:58 +0000
Subject: [Numpy-discussion] Numpy Documentation: How-to content
Message-ID: <BL0PR05MB528269459BA7886D3839C434BA8F0@BL0PR05MB5282.namprd05.prod.outlook.com>

Greetings,
This is Ryan Cooper (ME professor at University of Connecticut). I've been using Numpy in my mechanical engineering courses for years now, and I'd like to build resources for newcomers to Numpy.

Here is my proposed contribution:
Advise engineering students here at UConn to build How-to notebooks for Numpy applications. This would give the students some great experience communicating concepts and procedures to a broader community and it would help future users see how to use Numpy in different applications.

Some How-to's that I had in mind would be:

  *   Saving and loading Numpy arrays
  *   Doing fast fourier transform (FFT) on time-series data to find natural frequencies
  *   Solving linear sets of equations for circuits or another linear system with linear algebra
  *   using eigenvalues for natural frequency calculations

I'm open to other suggestions. These are some of the applications that I have current students doing in engineering work.

My question is: Would these How-to's be appopriate for the "Numpy Tutorials" (https://github.com/numpy/numpy-tutorials) repo?

My personal opinion is that How-to's are easier to organize and curate (for Numpy) and easier to write (for students).

Best Regards,
Ryan


Ryan C. Cooper, Ph. D.
Assistant Professor-in-Residence
University of Connecticut
Mechanical Engineering Department
Engineering II, room 314
191 Auditorium rd
Storrs, CT 06269
email: ryan.c.cooper at uconn.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200529/df5d9105/attachment.html>

From tyler.je.reddy at gmail.com  Sat May 30 17:36:05 2020
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Sat, 30 May 2020 15:36:05 -0600
Subject: [Numpy-discussion] ANN: SciPy 1.5.0rc1 -- please test
Message-ID: <CAHPuU_Y0rDeXrdgv6phob1wd1f7GvuKkS+B6gpkzzGR41Z-5pA@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

On behalf of the SciPy development team I'm pleased to announce
the release candidate SciPy 1.5.0rc1. 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.0rc1
<https://github.com/scipy/scipy/releases/tag/v1.4.0rc1>

One of a few ways to install the release candidate with pip:

pip install scipy==1.5.0rc1

==========================
SciPy 1.5.0 Release Notes
==========================

Note: Scipy 1.5.0 is not released yet!

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
``?<sy/he>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 ``<sy/he>{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
* 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 <https://github.com/scipy/scipy/issues/1455>`__: ellipord does
returns bogus values if gstop or gpass are negative...
* `#1968 <https://github.com/scipy/scipy/issues/1968>`__: correlate2d's
output does not agree with correlate's output in...
* `#2744 <https://github.com/scipy/scipy/issues/2744>`__: BUG: optimize:
'\*\*kw' argument of 'newton_krylov' is not documented
* `#4755 <https://github.com/scipy/scipy/issues/4755>`__: TypeError: data
type "<i0" not understood
* `#4921 <https://github.com/scipy/scipy/issues/4921>`__: scipy.optimize
maxiter option not working as expected
* `#5144 <https://github.com/scipy/scipy/issues/5144>`__: RuntimeWarning on
csgraph.shortest_path when edge lengths are...
* `#5309 <https://github.com/scipy/scipy/issues/5309>`__: Documentation of
'hybr' and 'lm' inconsistent in optimize.root
* `#6026 <https://github.com/scipy/scipy/issues/6026>`__: Replace
approx_grad with _numdiff.approx_derivative in scipy.optimize
* `#6502 <https://github.com/scipy/scipy/issues/6502>`__: Computing
Eigenvalues in an Interval with LAPACK
* `#7058 <https://github.com/scipy/scipy/issues/7058>`__: Errors in
special.bdtri and special.bdtr for non-integer k values
* `#7700 <https://github.com/scipy/scipy/issues/7700>`__: SuperLU does not
respect perm_c="NATURAL"
* `#7895 <https://github.com/scipy/scipy/issues/7895>`__: Improvements to
io.loadmat
* `#8205 <https://github.com/scipy/scipy/issues/8205>`__: ValueError in
scipy.linalg.eigvalsh for large matrix
* `#8278 <https://github.com/scipy/scipy/issues/8278>`__: Memory limit for
scipy.sparse.linalg.spsolve with scikit-umfpack
* `#8327 <https://github.com/scipy/scipy/issues/8327>`__:
scipy.stats.mstats.winsorize NaN handling
* `#8341 <https://github.com/scipy/scipy/issues/8341>`__:
scipy.stats.ks_2samp for masked and unmasked data give different...
* `#8748 <https://github.com/scipy/scipy/issues/8748>`__:
scipy.stats.kstest for same distribution: p-values nonuniform
* `#9042 <https://github.com/scipy/scipy/issues/9042>`__: optimize:
Incorrect statement about \`jac\` in the \`minimize\`...
* `#9197 <https://github.com/scipy/scipy/issues/9197>`__: problem with
scipy.signal.butter with 1000+ points array
* `#9212 <https://github.com/scipy/scipy/issues/9212>`__: EIGH very very
slow --> suggesting an easy fix
* `#9553 <https://github.com/scipy/scipy/issues/9553>`__: ndimage routines
behave badly when output has memory overlap...
* `#9632 <https://github.com/scipy/scipy/issues/9632>`__:
ndimage.maximum_filter undocumented behaviour using footprint...
* `#9710 <https://github.com/scipy/scipy/issues/9710>`__:
stats.weightedtau([1], [1.0]) SEGFAULTs
* `#9797 <https://github.com/scipy/scipy/issues/9797>`__: Master Tracker
for some Kolmogorov-Smirnov test Issues
* `#9844 <https://github.com/scipy/scipy/issues/9844>`__:
scipy.signal.upfirdn gives different length matrix versus MATLAB...
* `#9872 <https://github.com/scipy/scipy/issues/9872>`__:
scipy.signal.convolve is slower when vectorized
* `#9913 <https://github.com/scipy/scipy/issues/9913>`__: BUG: No dt in
StateSpace operations
* `#10014 <https://github.com/scipy/scipy/issues/10014>`__: Distribution
names \`weibull_min\`and \`weibull_max\` should...
* `#10159 <https://github.com/scipy/scipy/issues/10159>`__: BUG: stats:
chisquare returns incorrect results for arrays of...
* `#10302 <https://github.com/scipy/scipy/issues/10302>`__: scipy.fft: Add
a \`plan\` argument
* `#10332 <https://github.com/scipy/scipy/issues/10332>`__: 'Incomplete wav
chunk' inconsistent/reason unknown
* `#10441 <https://github.com/scipy/scipy/issues/10441>`__: Remove uses of
\`numpy.dual\`?
* `#10558 <https://github.com/scipy/scipy/issues/10558>`__: Document
implicit sum in csr_matrix() constructor
* `#10788 <https://github.com/scipy/scipy/issues/10788>`__: LU with full
pivoting
* `#10841 <https://github.com/scipy/scipy/issues/10841>`__: Unexpected
behavior in linalg.blas.dtrmm wrapper
* `#10919 <https://github.com/scipy/scipy/issues/10919>`__:
optimize._lbfgsb setulb() function violates parameter bounds
* `#10963 <https://github.com/scipy/scipy/issues/10963>`__: kstest,
ks_2samp: confusing \`mode\` argument descriptions
* `#11022 <https://github.com/scipy/scipy/issues/11022>`__: Unexpected
Result in factorial function with NaN input
* `#11028 <https://github.com/scipy/scipy/issues/11028>`__: Documentation
error in optimize.minimize
* `#11058 <https://github.com/scipy/scipy/issues/11058>`__: Adding
logsoftmax function
* `#11076 <https://github.com/scipy/scipy/issues/11076>`__: ValueError:
Unknown wave file format
* `#11090 <https://github.com/scipy/scipy/issues/11090>`__: Misconception
of the median absolute deviation in stats?
* `#11095 <https://github.com/scipy/scipy/issues/11095>`__: BUG:
find_peaks_cwt test failures in 32-bit Linux wheels
* `#11107 <https://github.com/scipy/scipy/issues/11107>`__: scipy.io.mmread
generated an error "TypeError: startswith first...
* `#11123 <https://github.com/scipy/scipy/issues/11123>`__: Add wrapper for
?gttrf/?gttrs
* `#11128 <https://github.com/scipy/scipy/issues/11128>`__: OverflowError
in resample_poly (upfirdn)
* `#11132 <https://github.com/scipy/scipy/issues/11132>`__: Possible bug:
rv_discret.ppf for percentiles 0 and 100 and loc...
* `#11163 <https://github.com/scipy/scipy/issues/11163>`__: Comparisons
between scipy spmatrix and can sparse.SparseArray...
* `#11168 <https://github.com/scipy/scipy/issues/11168>`__: Generalized
Pareto variance inaccurate for concentrations near...
* `#11169 <https://github.com/scipy/scipy/issues/11169>`__: Add wrapper for
?geqrfp
* `#11184 <https://github.com/scipy/scipy/issues/11184>`__: 2-sided
Kolmogorov Smirnov returns p-value of 1
* `#11185 <https://github.com/scipy/scipy/issues/11185>`__: The .roots() or
solve() function of scipy.interpolate.CubicHermiteSpline...
* `#11190 <https://github.com/scipy/scipy/issues/11190>`__: Add wrapper for
?tbtrs
* `#11200 <https://github.com/scipy/scipy/issues/11200>`__: Can no longer
slice csr_matrix in 1.3.0
* `#11207 <https://github.com/scipy/scipy/issues/11207>`__:
_minimize_scalar_bounded: reference before assignment
* `#11216 <https://github.com/scipy/scipy/issues/11216>`__: linprog:
interior-point: Cholmod reordering can be reused
* `#11223 <https://github.com/scipy/scipy/issues/11223>`__: Add wrappers
for ?pttrf, ?pttrs
* `#11224 <https://github.com/scipy/scipy/issues/11224>`__: Add wrapperfor
?pteqr
* `#11235 <https://github.com/scipy/scipy/issues/11235>`__: MAINT:
Missleading Error Message for IIR Filter
* `#11244 <https://github.com/scipy/scipy/issues/11244>`__: Missing
reference in \`scipy.optimize.line_search\`
* `#11262 <https://github.com/scipy/scipy/issues/11262>`__: Hermitian
Eigenvalue Problem eigh() API and wrapper change proposal
* `#11266 <https://github.com/scipy/scipy/issues/11266>`__: Sparse matrix
constructor data type detection changes on Numpy...
* `#11270 <https://github.com/scipy/scipy/issues/11270>`__: CI failing:
Travis CI Py36 refguide and Linux_Python_36_32bit_full...
* `#11279 <https://github.com/scipy/scipy/issues/11279>`__: linalg.eigh
checks whole array for finite values
* `#11295 <https://github.com/scipy/scipy/issues/11295>`__: CI: azure does
not auto-cancel old jobs on pushes
* `#11299 <https://github.com/scipy/scipy/issues/11299>`__:
stats.truncnorm.rvs 100x slower in v1.4.x than v1.3.3
* `#11315 <https://github.com/scipy/scipy/issues/11315>`__: BUG: special:
rgamma on negative integers smaller -34
* `#11319 <https://github.com/scipy/scipy/issues/11319>`__: Missing
\`int64_t\` declaration in rectangular_lsap.cpp
* `#11323 <https://github.com/scipy/scipy/issues/11323>`__: Compilation
failure due to missing symbol pthread_atfork
* `#11332 <https://github.com/scipy/scipy/issues/11332>`__: BUG:
directed_hausdorff distance on sets u and v when u is a...
* `#11350 <https://github.com/scipy/scipy/issues/11350>`__: Khatri-Rao
product
* `#11354 <https://github.com/scipy/scipy/issues/11354>`__: ENH: Add
wrapper for ?gejsv
* `#11361 <https://github.com/scipy/scipy/issues/11361>`__: Dropped NaN in
eval_genlaguerre function
* `#11363 <https://github.com/scipy/scipy/issues/11363>`__: Dropped NaN in
hyperu function
* `#11365 <https://github.com/scipy/scipy/issues/11365>`__:
scipy.stats.binned_statistic regressed in v1.4.0
* `#11369 <https://github.com/scipy/scipy/issues/11369>`__: Dropped NaN in
eval_hermite
* `#11370 <https://github.com/scipy/scipy/issues/11370>`__: Dropped NaN in
eval_gegenbauer
* `#11373 <https://github.com/scipy/scipy/issues/11373>`__: Add wrapper for
?gtsvx
* `#11374 <https://github.com/scipy/scipy/issues/11374>`__: Add wrapper for
?ptsvx
* `#11391 <https://github.com/scipy/scipy/issues/11391>`__:
csgraph.minimum_spanning_tree loses precision
* `#11398 <https://github.com/scipy/scipy/issues/11398>`__: Update stats to
cope with \`np.random.Generator\` machinery
* `#11412 <https://github.com/scipy/scipy/issues/11412>`__: Array copying
causes unwanted type casting from complex to float...
* `#11415 <https://github.com/scipy/scipy/issues/11415>`__: Where is the
Wiener Filter derived from?
* `#11416 <https://github.com/scipy/scipy/issues/11416>`__:
_lib._util.getargspec_no_self is missing KEYWORD_ONLY support
* `#11428 <https://github.com/scipy/scipy/issues/11428>`__: Documentation
on SHGO inequality constraints appears contradictory
* `#11429 <https://github.com/scipy/scipy/issues/11429>`__: Add LAPACK's
ZUNCSD cosine sine decomposition
* `#11438 <https://github.com/scipy/scipy/issues/11438>`__:
run_dualannealing passes bounds incorrectly in benchmarks/optimize.py
* `#11441 <https://github.com/scipy/scipy/issues/11441>`__: Can't run
optimize benchmarks
* `#11442 <https://github.com/scipy/scipy/issues/11442>`__: Chebyshev
weights
* `#11448 <https://github.com/scipy/scipy/issues/11448>`__: Wrongly typed
comparison in integrate.quad
* `#11458 <https://github.com/scipy/scipy/issues/11458>`__: BUG:
maximum_bipartite_matching produces infeasible solution
* `#11460 <https://github.com/scipy/scipy/issues/11460>`__: CI failing: 2
Travis CI tests fail with numpy build or version...
* `#11462 <https://github.com/scipy/scipy/issues/11462>`__: Bug on "++"
initialization on "kmeans2"
* `#11464 <https://github.com/scipy/scipy/issues/11464>`__: Shouldn't data
type of KDE evaluation should be like in the input...
* `#11468 <https://github.com/scipy/scipy/issues/11468>`__: performance of
binned_statistics_2d 100x slowdown from 1.3.2...
* `#11484 <https://github.com/scipy/scipy/issues/11484>`__: Callback
function doesn't give the same value as the one being...
* `#11492 <https://github.com/scipy/scipy/issues/11492>`__: Confusing
dendrogram labelling
* `#11493 <https://github.com/scipy/scipy/issues/11493>`__:
scipy.optimize.least_squares fails if the return array of the...
* `#11494 <https://github.com/scipy/scipy/issues/11494>`__: Error
performing kronecker product between large sparse vectors
* `#11503 <https://github.com/scipy/scipy/issues/11503>`__: medfilt
produces 0 on input of length 1
* `#11529 <https://github.com/scipy/scipy/issues/11529>`__: Pyflakes
generates almost 700 warnings.
* `#11566 <https://github.com/scipy/scipy/issues/11566>`__:
irfft/irfft2/irfftn docs are slightly confusing re: input type.
* `#11572 <https://github.com/scipy/scipy/issues/11572>`__: least_squares:
too small tolerances not catched with method='lm'
* `#11581 <https://github.com/scipy/scipy/issues/11581>`__: DOC:
scipy.interpolate.RectSphereBivariateSpline
* `#11586 <https://github.com/scipy/scipy/issues/11586>`__: Differential
evolution breaks with LinearConstraints with sparse...
* `#11595 <https://github.com/scipy/scipy/issues/11595>`__:
scipy.spatial.cKDTree construction slow for some datasets
* `#11598 <https://github.com/scipy/scipy/issues/11598>`__: output of
special.voigt_profile when sigma=0
* `#11601 <https://github.com/scipy/scipy/issues/11601>`__: linalg tests
failing in runtests.py
* `#11602 <https://github.com/scipy/scipy/issues/11602>`__:
scipy.optimize.linear_sum_assignment returns reverse diagonal...
* `#11610 <https://github.com/scipy/scipy/issues/11610>`__: Analytic
formula for normal moments
* `#11611 <https://github.com/scipy/scipy/issues/11611>`__: Build failure
with gfortran 10
* `#11613 <https://github.com/scipy/scipy/issues/11613>`__: TST, MAINT:
test_quadpack TestCtypesQuad wasn't fully migrated...
* `#11630 <https://github.com/scipy/scipy/issues/11630>`__:
SmoothBivariateSpline bbox parameter
* `#11635 <https://github.com/scipy/scipy/issues/11635>`__: typo in
docstring of scipy.stats.norminvgauss
* `#11637 <https://github.com/scipy/scipy/issues/11637>`__: BUG: core dumps
when calling scipy.interpolate.interp1d with...
* `#11638 <https://github.com/scipy/scipy/issues/11638>`__: better
documentation for 'return_all' option in minimize(Nelder...
* `#11652 <https://github.com/scipy/scipy/issues/11652>`__: TST, MAINT: CI
failures for pre-release NumPy wheels
* `#11659 <https://github.com/scipy/scipy/issues/11659>`__:
optimize.fmin_l_bfgs_b needs bound check and appropiate error...
* `#11660 <https://github.com/scipy/scipy/issues/11660>`__: BUG/ENH:
distribution.ncf with nc=0 returns nan
* `#11661 <https://github.com/scipy/scipy/issues/11661>`__:
scipy.ndimage.convolve1d and correlate1d don't behave properly...
* `#11669 <https://github.com/scipy/scipy/issues/11669>`__: p-value varies
with the order of the data
* `#11676 <https://github.com/scipy/scipy/issues/11676>`__: documentation
of scipy.spatial.HalfspaceIntersection: wrong method...
* `#11685 <https://github.com/scipy/scipy/issues/11685>`__: Rotation cannot
be expressed as matrix
* `#11686 <https://github.com/scipy/scipy/issues/11686>`__: MAINT: mypy
imports of Cython "modules"
* `#11693 <https://github.com/scipy/scipy/issues/11693>`__:
TestDifferentialEvolutionSolver::test_L4 failing in CI
* `#11696 <https://github.com/scipy/scipy/issues/11696>`__: DOC: incorrect
compiler information for macOS in docs
* `#11709 <https://github.com/scipy/scipy/issues/11709>`__: eigh() tests
fail to pass, crash Python with seemingly ramdom...
* `#11763 <https://github.com/scipy/scipy/issues/11763>`__: Small error in
gamma continuous rv fit comments
* `#11769 <https://github.com/scipy/scipy/issues/11769>`__: truncnorm.rvs
Weird Behaviors
* `#11770 <https://github.com/scipy/scipy/issues/11770>`__: crash in
TestEigh::test_value_subsets
* `#11795 <https://github.com/scipy/scipy/issues/11795>`__: trapz
distribution mean computed using single precision
* `#11800 <https://github.com/scipy/scipy/issues/11800>`__: Segmentation
fault in scipy.odr for multidimensional independent...
* `#11811 <https://github.com/scipy/scipy/issues/11811>`__: pyflakes
silently failing on travis-ci
* `#11826 <https://github.com/scipy/scipy/issues/11826>`__: Error with
_fblas
* `#11827 <https://github.com/scipy/scipy/issues/11827>`__:
\`fft.tests.test_numpy.test_multiprocess\` hangs on Python3.8...
* `#11835 <https://github.com/scipy/scipy/issues/11835>`__: tests with
\`multiprocessing\` hang on Python 3.8 on macOS
* `#11839 <https://github.com/scipy/scipy/issues/11839>`__: linalg.expm
returns nans with RuntimeWarning: overflow encountered...
* `#11856 <https://github.com/scipy/scipy/issues/11856>`__: Documentation
of fit methods for \`weibull_min\` and \`exponweib\`...
* `#11868 <https://github.com/scipy/scipy/issues/11868>`__: Function always
evaluated twice when using HessianUpdateStrategy...
* `#11875 <https://github.com/scipy/scipy/issues/11875>`__: Typo in the
docstring of simps()
* `#11877 <https://github.com/scipy/scipy/issues/11877>`__: kmeans2 '++'
method is orders of magnitude slower than sklearn.cluster.KMeans()
* `#11884 <https://github.com/scipy/scipy/issues/11884>`__: The upper code
lines are dead code
* `#11886 <https://github.com/scipy/scipy/issues/11886>`__: Array shape
mismatch in scipy.optimize
* `#11892 <https://github.com/scipy/scipy/issues/11892>`__: BUG: stats:
Incorrect handling of edges cases by ttest_rel and...
* `#11908 <https://github.com/scipy/scipy/issues/11908>`__: LinearOperator
should have ndim attribute
* `#11910 <https://github.com/scipy/scipy/issues/11910>`__: Documentation
missing for what M is in init argument
* `#11922 <https://github.com/scipy/scipy/issues/11922>`__: macOS actions
CI has started failing in last couple of days.
* `#11928 <https://github.com/scipy/scipy/issues/11928>`__: DOC: signal:
Wrong description for sepfir2d, cspline2d, qspline2d
* `#11944 <https://github.com/scipy/scipy/issues/11944>`__: curve_fit
documentation unclear on default value of absolute_sigma
* `#11945 <https://github.com/scipy/scipy/issues/11945>`__: Add a
(potentially temporary) py.typed file?
* `#11949 <https://github.com/scipy/scipy/issues/11949>`__: ValueError 'k
exceeds matrix dimensions' for sparse.diagonal()...
* `#11951 <https://github.com/scipy/scipy/issues/11951>`__: BUG: asv
benchmark failed because of cython version
* `#11967 <https://github.com/scipy/scipy/issues/11967>`__: BLD: Azure
windows runs complain about drives
* `#11973 <https://github.com/scipy/scipy/issues/11973>`__:
oaconvolve(a,b,'same') differs in shape from convolve(a,b,'same')...
* `#12002 <https://github.com/scipy/scipy/issues/12002>`__: pybind11 license
* `#12003 <https://github.com/scipy/scipy/issues/12003>`__: MAINT: circular
SphericalVoronoi input
* `#12015 <https://github.com/scipy/scipy/issues/12015>`__: Reordering of
CSC matrix breaks when you go above int32 limits
* `#12031 <https://github.com/scipy/scipy/issues/12031>`__: Documentation
Rendering Issues Visible in CircleCI Artifacts
* `#12037 <https://github.com/scipy/scipy/issues/12037>`__: MAINT, CI: new
Cython 3.0a4 issue
* `#12087 <https://github.com/scipy/scipy/issues/12087>`__: DOC: some odr
models are missing docs
* `#12119 <https://github.com/scipy/scipy/issues/12119>`__:
signal.fftconvolve no longer convolves types f8 and numpy.float64
* `#12149 <https://github.com/scipy/scipy/issues/12149>`__: Documentation
of Rosenbrock function
* `#12173 <https://github.com/scipy/scipy/issues/12173>`__: Large memory
usage when indexing sparse matrices with \`np.ix_\`
* `#12178 <https://github.com/scipy/scipy/issues/12178>`__: BUG: stats:
Some discrete distributions don't accept lists of...
* `#12220 <https://github.com/scipy/scipy/issues/12220>`__: BUG, REL:
gh_lists.py compromised scraping
* `#12239 <https://github.com/scipy/scipy/issues/12239>`__: BUG: median
absolute deviation handling of nan

Pull requests for 1.5.0
------------------------------

* `#6510 <https://github.com/scipy/scipy/pull/6510>`__: Add Eigenvalue
Range Functionality for Symmetric Eigenvalue Problems
* `#9525 <https://github.com/scipy/scipy/pull/9525>`__: BUG: SuperLU
'NATURAL' order applies a column permutation
* `#9634 <https://github.com/scipy/scipy/pull/9634>`__: Add the number of
Jacobian evaluations to the output of L-BFGS-B.
* `#9719 <https://github.com/scipy/scipy/pull/9719>`__: ENH: Added kstwo
probability distribution for two-sided one-sample...
* `#9783 <https://github.com/scipy/scipy/pull/9783>`__: WIP: optimize:
added (dense) interpolative decomposition redundancy...
* `#10053 <https://github.com/scipy/scipy/pull/10053>`__: Adding docstring
to weibull_min and weibull_max based on issue...
* `#10136 <https://github.com/scipy/scipy/pull/10136>`__: DEP: Add warning
to linprog_verbose_callback
* `#10380 <https://github.com/scipy/scipy/pull/10380>`__: ENH: add
geometric_slerp
* `#10602 <https://github.com/scipy/scipy/pull/10602>`__: MAINT: optimize:
refactor common linprog arguments into namedtuple
* `#10648 <https://github.com/scipy/scipy/pull/10648>`__: Bounds for the
Powell minimization method
* `#10673 <https://github.com/scipy/scipy/pull/10673>`__: ENH:
approx_fprime --> approx_derivative
* `#10759 <https://github.com/scipy/scipy/pull/10759>`__: ENH: calculation
of region areas in spatial.SphericalVoronoi
* `#10762 <https://github.com/scipy/scipy/pull/10762>`__: BENCH: optimize:
more comprehensive linprog benchmarking
* `#10796 <https://github.com/scipy/scipy/pull/10796>`__: ENH exact
p-values of wilcoxon test in scipy.stats
* `#10797 <https://github.com/scipy/scipy/pull/10797>`__: ENH: linalg: LU
with full pivoting (wrappers for ?getc2/?gesc2)
* `#10824 <https://github.com/scipy/scipy/pull/10824>`__: ENH: Fast
gaussian kernel estimator
* `#10942 <https://github.com/scipy/scipy/pull/10942>`__: BUG: prevent
bound violation in L-BFGS-B optimize method
* `#11003 <https://github.com/scipy/scipy/pull/11003>`__: ENH: add
scipy.linalg.convolution_matrix
* `#11023 <https://github.com/scipy/scipy/pull/11023>`__: improving error
message for cubic-interpolate with duplicates
* `#11045 <https://github.com/scipy/scipy/pull/11045>`__: MAINT: make
bdt{r,rc,ri}() functions accept double n,k args +...
* `#11063 <https://github.com/scipy/scipy/pull/11063>`__: Fix documentation
error in optimize.minimize
* `#11069 <https://github.com/scipy/scipy/pull/11069>`__: ENH:
stats.dlaplace.rvs improvements
* `#11071 <https://github.com/scipy/scipy/pull/11071>`__: DOC: Added
examples to maximum_position in ndimage
* `#11075 <https://github.com/scipy/scipy/pull/11075>`__: DOC: Update
stylistic consistency in multiple files
* `#11097 <https://github.com/scipy/scipy/pull/11097>`__: BUG: stats:
fixing chisquare to return correct results for arrays...
* `#11110 <https://github.com/scipy/scipy/pull/11110>`__: ENH: special:
Cythonise erfinv, erfcinv
* `#11112 <https://github.com/scipy/scipy/pull/11112>`__: BUG: special:
Return NaN outside the domain of \`eval_hermite\`
* `#11114 <https://github.com/scipy/scipy/pull/11114>`__: BUG: special: fix
\`hyp1f1\` for nonnegative integral \`a\` and...
* `#11115 <https://github.com/scipy/scipy/pull/11115>`__: DOC: special: add
docstrings for \`kei\`, \`ker\`, \`keip\`,...
* `#11130 <https://github.com/scipy/scipy/pull/11130>`__: ENH: support for
circular input
* `#11136 <https://github.com/scipy/scipy/pull/11136>`__: BUG: expm
handling of empty input
* `#11138 <https://github.com/scipy/scipy/pull/11138>`__: DOC: stylistic
consistency, punctuation, etc.
* `#11139 <https://github.com/scipy/scipy/pull/11139>`__: MAINT: cluster:
use cython_blas, remove handwritten BLAS wrappers
* `#11146 <https://github.com/scipy/scipy/pull/11146>`__: DOC: update docs
on bp parameter for detrend
* `#11151 <https://github.com/scipy/scipy/pull/11151>`__: DOC: special: add
docstrings for \`bei\`, \`ber\`, \`beip\`,...
* `#11156 <https://github.com/scipy/scipy/pull/11156>`__: ENH: add input
validation for ellipord.
* `#11157 <https://github.com/scipy/scipy/pull/11157>`__: DOC: stylistic
revision, punctuation, consistency
* `#11160 <https://github.com/scipy/scipy/pull/11160>`__: ignore warning on
0 \* inf in basin hopping
* `#11162 <https://github.com/scipy/scipy/pull/11162>`__: DOC: minor
stylistic revision, undo changes
* `#11164 <https://github.com/scipy/scipy/pull/11164>`__: ENH/ BUG: Pydata
sparse equality
* `#11171 <https://github.com/scipy/scipy/pull/11171>`__: Fix dtype
validation of "seuclidean" metric V parameter
* `#11177 <https://github.com/scipy/scipy/pull/11177>`__: BUG: stats:
Improve genpareto stats calculations.
* `#11180 <https://github.com/scipy/scipy/pull/11180>`__: MAINT: stats:
Some clean up in test_distributions.py.
* `#11187 <https://github.com/scipy/scipy/pull/11187>`__: ENH: add
functionality log_softmax to SciPy.special.
* `#11188 <https://github.com/scipy/scipy/pull/11188>`__: MAINT: add rvs
method to argus in scipy.stats
* `#11196 <https://github.com/scipy/scipy/pull/11196>`__: DOC: special: add
to docstrings of Kelvin zeros functions
* `#11202 <https://github.com/scipy/scipy/pull/11202>`__: BUG: fix edge
counting in shortest_path
* `#11218 <https://github.com/scipy/scipy/pull/11218>`__: BUG:
scipy/interpolate: fix PPoly/Cubic\*Spline roots() extrapolation...
* `#11225 <https://github.com/scipy/scipy/pull/11225>`__: Add a warning to
constant input for spearmanr() function
* `#11226 <https://github.com/scipy/scipy/pull/11226>`__: Speed up of
interior-point method for cholesky solver
* `#11229 <https://github.com/scipy/scipy/pull/11229>`__: BUG: Explicit
dtype specification in _upfirdn.py
* `#11230 <https://github.com/scipy/scipy/pull/11230>`__: Additional
citation for optimize tutorial
* `#11231 <https://github.com/scipy/scipy/pull/11231>`__: Adds SLSQP test
for duplicate f-evals (#10738)
* `#11236 <https://github.com/scipy/scipy/pull/11236>`__: MAINT: Improved
error message for Wn range in iirfilter.
* `#11245 <https://github.com/scipy/scipy/pull/11245>`__: ENH: optimize:
dense redundancy removal routine optimizations
* `#11247 <https://github.com/scipy/scipy/pull/11247>`__: MAINT: Remove
_lib/_numpy_compat.py
* `#11248 <https://github.com/scipy/scipy/pull/11248>`__: BUG:
rv_discrete.ppf() to handle loc
* `#11251 <https://github.com/scipy/scipy/pull/11251>`__: DOC: add
reference for linesearch zoom algorithm
* `#11253 <https://github.com/scipy/scipy/pull/11253>`__: BUG: fix
kendalltau issue where p-value becomes >1
* `#11254 <https://github.com/scipy/scipy/pull/11254>`__: MAINT: make
special.factorial handle nan correctly
* `#11256 <https://github.com/scipy/scipy/pull/11256>`__: DOC: Updated
documentation for scipy.linalg.qr
* `#11265 <https://github.com/scipy/scipy/pull/11265>`__: Fix: Can no
longer slice csr_matrix in 1.3.0
* `#11267 <https://github.com/scipy/scipy/pull/11267>`__: BUG: Rework the
scaling in the ks_2samp two-sided exact test.
* `#11268 <https://github.com/scipy/scipy/pull/11268>`__: DOC: example of
NonLinearConstraint
* `#11269 <https://github.com/scipy/scipy/pull/11269>`__: Fix: Sparse
matrix constructor data type detection changes on...
* `#11276 <https://github.com/scipy/scipy/pull/11276>`__: BLD: update
minimum Python, NumPy, Cython, Pybind11 versions
* `#11277 <https://github.com/scipy/scipy/pull/11277>`__: MAINT: Cleanup
conditionals for unsupported numpy verisons
* `#11278 <https://github.com/scipy/scipy/pull/11278>`__: MAINT: Cleanup
stats.iqr workarounds for unsupported NumPy versions
* `#11282 <https://github.com/scipy/scipy/pull/11282>`__: TST/CI: improve
traceback formatting for test failures
* `#11284 <https://github.com/scipy/scipy/pull/11284>`__: fix docs &
behavior for mode sequences in ndimage filters
* `#11285 <https://github.com/scipy/scipy/pull/11285>`__: DOC: special:
complete the docstrings of Chi-square functions
* `#11286 <https://github.com/scipy/scipy/pull/11286>`__: BUG: make
loadmat/savemat file opening close resources correctly
* `#11287 <https://github.com/scipy/scipy/pull/11287>`__: CI: skip Azure
and TravisCI builds on merges and direct pushes...
* `#11288 <https://github.com/scipy/scipy/pull/11288>`__: DOC: Fix import
in scipy.io.wavfile.read sample code
* `#11289 <https://github.com/scipy/scipy/pull/11289>`__: BUG: Use context
manager for open
* `#11290 <https://github.com/scipy/scipy/pull/11290>`__: MAINT: Remove
_lib._version in favour of _lib._pep440
* `#11292 <https://github.com/scipy/scipy/pull/11292>`__: DOC: special: add
docstrings for various convenience functions
* `#11293 <https://github.com/scipy/scipy/pull/11293>`__: DOC: special: fix
typo in \`chdtri\` docstring
* `#11296 <https://github.com/scipy/scipy/pull/11296>`__: DOC: special: add
to docstrings of Bessel zeros and derivatives
* `#11297 <https://github.com/scipy/scipy/pull/11297>`__: DOC: special: add
parameters/returns sections for Bessel integrals
* `#11300 <https://github.com/scipy/scipy/pull/11300>`__: MAINT: Update
vendored uarray version
* `#11301 <https://github.com/scipy/scipy/pull/11301>`__: CI: azure
conditions should require succeeded()
* `#11302 <https://github.com/scipy/scipy/pull/11302>`__: ENH: build
infrastructure for ILP64 BLAS + ARPACK conversion
* `#11303 <https://github.com/scipy/scipy/pull/11303>`__: DOC: special: fix
typo in \`besselpoly\` docstring
* `#11304 <https://github.com/scipy/scipy/pull/11304>`__: ENH: MAINT:
Rewrite of eigh() and relevant wrappers
* `#11306 <https://github.com/scipy/scipy/pull/11306>`__: TST: skip
test_aligned_mem linalg test that is crashing on ppcle64
* `#11307 <https://github.com/scipy/scipy/pull/11307>`__: MAINT: Fix typo
'solutuion' -> 'solution'
* `#11308 <https://github.com/scipy/scipy/pull/11308>`__: ENH: do not
create 1d array out of a scalar
* `#11310 <https://github.com/scipy/scipy/pull/11310>`__: MAINT: clean up
object array creation, scalar/1d confusion
* `#11311 <https://github.com/scipy/scipy/pull/11311>`__: DOC: Specify
custom callable option for metric in cluster.hierarchy.fclusterdata
* `#11316 <https://github.com/scipy/scipy/pull/11316>`__: BUG: special: fix
behavior for \`rgamma\` zeros
* `#11317 <https://github.com/scipy/scipy/pull/11317>`__: BUG: fix
floating-point literal comparisons under C99
* `#11318 <https://github.com/scipy/scipy/pull/11318>`__: TST: optimize:
mark two linprog tests for skipping
* `#11320 <https://github.com/scipy/scipy/pull/11320>`__: BUG: Include
\`int64_t\` declaration to \`rectangular_lsap.cpp\`
* `#11330 <https://github.com/scipy/scipy/pull/11330>`__: MAINT: Update
vendored pypocketfft version
* `#11333 <https://github.com/scipy/scipy/pull/11333>`__: BUG:
directed_hausdorff subset fix
* `#11335 <https://github.com/scipy/scipy/pull/11335>`__: [ENH] sparse:
Loosen check for sparse outer indexing fast path
* `#11337 <https://github.com/scipy/scipy/pull/11337>`__: Undefined name
'e' in pavement.py
* `#11338 <https://github.com/scipy/scipy/pull/11338>`__: scipyoptdoc.py:
Remove unused variable 'sixu'
* `#11340 <https://github.com/scipy/scipy/pull/11340>`__: xrange() was
removed in Python 3 in favor of range()
* `#11342 <https://github.com/scipy/scipy/pull/11342>`__: range() was
removed in Py3 in _binned_statistic.py
* `#11343 <https://github.com/scipy/scipy/pull/11343>`__: BUG: constants:
fix 'exact' values table
* `#11347 <https://github.com/scipy/scipy/pull/11347>`__: ENH: add input
validation function and apply it to needed functions
* `#11348 <https://github.com/scipy/scipy/pull/11348>`__: MAINT: remove
six.string_types usages
* `#11349 <https://github.com/scipy/scipy/pull/11349>`__: MAINT: minor doc
fix _minimize_trustregion_constr
* `#11353 <https://github.com/scipy/scipy/pull/11353>`__: MAINT: py3 remove
various six usages
* `#11358 <https://github.com/scipy/scipy/pull/11358>`__: ENH: optimize:
Use CSR format instead of LIL for speed
* `#11362 <https://github.com/scipy/scipy/pull/11362>`__: MAINT:
sys.version_info >= 3.5
* `#11364 <https://github.com/scipy/scipy/pull/11364>`__: ENH: cache square
of sums for f_oneway
* `#11368 <https://github.com/scipy/scipy/pull/11368>`__: ENH: add optional
argument, "include_nyquist", for freqz()
* `#11372 <https://github.com/scipy/scipy/pull/11372>`__: BENCH: optimize:
added linprog presolve benchmarks
* `#11376 <https://github.com/scipy/scipy/pull/11376>`__: ENH: Add wrapper
for ?gttrf/?gttrs
* `#11377 <https://github.com/scipy/scipy/pull/11377>`__: MAINT: Remove
Python 2 code from tools/authors.py
* `#11378 <https://github.com/scipy/scipy/pull/11378>`__: ENH (WIP): Python
wrapper for ?tbtrs
* `#11379 <https://github.com/scipy/scipy/pull/11379>`__: MAINT: Remove
six.with_metaclass from benchmarks/cython_special.py
* `#11380 <https://github.com/scipy/scipy/pull/11380>`__: BUG:
sparse/isolve: bicg and qmr don't treat x0 correctly
* `#11382 <https://github.com/scipy/scipy/pull/11382>`__: MAINT: remove
error throw in binned_statistic_dd() on non-finite...
* `#11383 <https://github.com/scipy/scipy/pull/11383>`__: MAINT: _lib:
remove py2 compat shims in getargspec
* `#11384 <https://github.com/scipy/scipy/pull/11384>`__: MAINT: Use numpy
scalar types directly
* `#11385 <https://github.com/scipy/scipy/pull/11385>`__: ENH: special: add
spherical Bessel functions to \`cython_special\`
* `#11389 <https://github.com/scipy/scipy/pull/11389>`__: MAINT:
line.startswith shouldn't be bytes
* `#11393 <https://github.com/scipy/scipy/pull/11393>`__: ENH: Speed up
truncnorm's ppf()and rvs() methods
* `#11394 <https://github.com/scipy/scipy/pull/11394>`__: MAINT: Remove
self._size (and self._random_state) from stats...
* `#11395 <https://github.com/scipy/scipy/pull/11395>`__: correction in
error message (%d->%g format)
* `#11396 <https://github.com/scipy/scipy/pull/11396>`__: DOC: revert
gh10540, removing mtrand
* `#11397 <https://github.com/scipy/scipy/pull/11397>`__: MAINT:
differential_evolution accepts np.random.Generator
* `#11402 <https://github.com/scipy/scipy/pull/11402>`__: ENH: stats can
use np.random.Generator
* `#11404 <https://github.com/scipy/scipy/pull/11404>`__: ENH: add
docstring of butter() for transfer function syntax problem
* `#11405 <https://github.com/scipy/scipy/pull/11405>`__: DOC: Fix "see
also" for SmoothBivariateSpline
* `#11408 <https://github.com/scipy/scipy/pull/11408>`__: ENH: Add a
\`plan\` argument to FFT functions in \`scipy.fft\`
* `#11411 <https://github.com/scipy/scipy/pull/11411>`__: MAINT: check
minimize duplicate evaluations
* `#11418 <https://github.com/scipy/scipy/pull/11418>`__: ENH: Linalg:
Python wrapper for ?geqrfp
* `#11419 <https://github.com/scipy/scipy/pull/11419>`__: TST: Python 3.7
mac OS gcc multibuild fix
* `#11423 <https://github.com/scipy/scipy/pull/11423>`__: ENH: Add tool to
lint diffs
* `#11425 <https://github.com/scipy/scipy/pull/11425>`__: FIX:
_array_newton should preserve complex inputs
* `#11426 <https://github.com/scipy/scipy/pull/11426>`__: MAINT: licence
for global optimization benchmarks
* `#11431 <https://github.com/scipy/scipy/pull/11431>`__: Make
median_absolute_deviation scale argument aligned w/iqr
* `#11432 <https://github.com/scipy/scipy/pull/11432>`__: Fix error message
typo
* `#11433 <https://github.com/scipy/scipy/pull/11433>`__: DOC: Remove L
from longs
* `#11434 <https://github.com/scipy/scipy/pull/11434>`__: MAINT: Python3
improvements to refguide_check.py
* `#11435 <https://github.com/scipy/scipy/pull/11435>`__: DOC: Update
runtest --parallel help
* `#11436 <https://github.com/scipy/scipy/pull/11436>`__: MAINT: Remove
checks for sys.version < 3.5
* `#11437 <https://github.com/scipy/scipy/pull/11437>`__: DOC: Fix
documentation issue
* `#11439 <https://github.com/scipy/scipy/pull/11439>`__: Support path
objects (PEP 519) in mmio functions
* `#11440 <https://github.com/scipy/scipy/pull/11440>`__: correct bounds
pass in run_dualannealing for benchmarks/optimize.py
* `#11443 <https://github.com/scipy/scipy/pull/11443>`__: BENCH:
optimize_linprog remove ImportError exception
* `#11453 <https://github.com/scipy/scipy/pull/11453>`__: BUG: sparse:
convert csc/csr indices to int64 as needed
* `#11454 <https://github.com/scipy/scipy/pull/11454>`__: DOC: Remove
caveat on \`maximum_bipartite_matching\`
* `#11455 <https://github.com/scipy/scipy/pull/11455>`__: BUG: Fix
_lib._util.getargspec_no_self lack of KEYWORD_ONLY support.
* `#11456 <https://github.com/scipy/scipy/pull/11456>`__: Implementation of
khatri_rao product
* `#11459 <https://github.com/scipy/scipy/pull/11459>`__: BUG: fix
augmentation being broken in maximum_bipartite_matching
* `#11461 <https://github.com/scipy/scipy/pull/11461>`__: MAINT: minor
spelling corrections in comments in SciPy.sparse.linalg.arpack
* `#11467 <https://github.com/scipy/scipy/pull/11467>`__: [MRG] Make result
data type of KDE evaluation like in the input...
* `#11469 <https://github.com/scipy/scipy/pull/11469>`__: Update
integrate.quad documentation
* `#11472 <https://github.com/scipy/scipy/pull/11472>`__: Fixed result typo
* `#11476 <https://github.com/scipy/scipy/pull/11476>`__: DOC: stats:
Copy-edit the anderson docstring.
* `#11478 <https://github.com/scipy/scipy/pull/11478>`__: ENH: avoid
unnecessary array copies in matrix product
* `#11481 <https://github.com/scipy/scipy/pull/11481>`__: BUG: Make
special.hyperu return nan if any argument is nan
* `#11483 <https://github.com/scipy/scipy/pull/11483>`__: BUG: Fixed
\`_kpp\` initialization on \`scipy.cluster.vq\`, closing...
* `#11485 <https://github.com/scipy/scipy/pull/11485>`__: ENH: Update
docstring of class KrylovJacobian to fix #2744
* `#11486 <https://github.com/scipy/scipy/pull/11486>`__: BUG: make
special.eval_hermite return nan if second argument...
* `#11487 <https://github.com/scipy/scipy/pull/11487>`__: ENH: improve
docstring of correlate and correlate2d to fix #1968
* `#11488 <https://github.com/scipy/scipy/pull/11488>`__: FIX: change "func
-> fun" of scipy.optimize _root.py to solve...
* `#11489 <https://github.com/scipy/scipy/pull/11489>`__: BUG: fixes typo
introduced in PR #11253 in stats.mstats.kendalltau()
* `#11490 <https://github.com/scipy/scipy/pull/11490>`__: DOC: fix typo in
scipy/io/matlab/mio4.py
* `#11495 <https://github.com/scipy/scipy/pull/11495>`__: MAINT: refactor
slsqp to fix issue in callback function
* `#11498 <https://github.com/scipy/scipy/pull/11498>`__: [DOC] mention
graph cuts in maximum flow docstring
* `#11499 <https://github.com/scipy/scipy/pull/11499>`__: DOC: Improve
documentation of scipy.signal.signaltools.wiener
* `#11506 <https://github.com/scipy/scipy/pull/11506>`__: DOC: Fix typo in
documentation of scipy.stats.morestats
* `#11508 <https://github.com/scipy/scipy/pull/11508>`__: ENH: avoid copy
on sparse __init__ when dtype is given
* `#11509 <https://github.com/scipy/scipy/pull/11509>`__: ENH: avoid
unnecessary array copies in matrix product (again)
* `#11510 <https://github.com/scipy/scipy/pull/11510>`__: [DOC] An ex. for
creating arbitrary size tri-diagonal
* `#11511 <https://github.com/scipy/scipy/pull/11511>`__: TST: pin numba
for Travis/sparse
* `#11513 <https://github.com/scipy/scipy/pull/11513>`__: TST: disable
NumPy cache dir ppc64le
* `#11514 <https://github.com/scipy/scipy/pull/11514>`__: BUG: make
special.eval_genlaguerre return nan if passed nan
* `#11517 <https://github.com/scipy/scipy/pull/11517>`__: ENH: improve
sparse.lil.tocsr performance
* `#11519 <https://github.com/scipy/scipy/pull/11519>`__: Fix fresnel
documentation
* `#11520 <https://github.com/scipy/scipy/pull/11520>`__: BUG: make
special.eval_gegenbauer return nan if passed nan
* `#11524 <https://github.com/scipy/scipy/pull/11524>`__: ENH: Cosine Sine
Decomposition
* `#11526 <https://github.com/scipy/scipy/pull/11526>`__: BUG: fix SLSQP
max iteration setting to fix #4921
* `#11527 <https://github.com/scipy/scipy/pull/11527>`__: ENH: improve
docstring of weibull_min_gen and weibull_max_gen...
* `#11530 <https://github.com/scipy/scipy/pull/11530>`__: MAINT: Removed 3
unused imports, 3 unused assignments from ndimage.
* `#11531 <https://github.com/scipy/scipy/pull/11531>`__: DOC: fix typos in
bdtr and bdtrc from gh PR 11045
* `#11532 <https://github.com/scipy/scipy/pull/11532>`__: MAINT: Fixed
several unused imports and unused assignments from...
* `#11533 <https://github.com/scipy/scipy/pull/11533>`__: MAINT: Fixed
about 100 unused imports, unused assignment warnings...
* `#11534 <https://github.com/scipy/scipy/pull/11534>`__: FIX: Allow
non-native byte order inputs to scipy.fft
* `#11535 <https://github.com/scipy/scipy/pull/11535>`__: MAINT: Fixed
several unused imports in _lib.
* `#11536 <https://github.com/scipy/scipy/pull/11536>`__: MAINT: Fixed
several unused imports and unused assignments in...
* `#11537 <https://github.com/scipy/scipy/pull/11537>`__: MAINT: Removed an
unused import in scipy/constants.
* `#11538 <https://github.com/scipy/scipy/pull/11538>`__: MAINT: Fixed
several unused imports in scipy/fft.
* `#11539 <https://github.com/scipy/scipy/pull/11539>`__: MAINT: Fixed
several unused imports and unused assignments in...
* `#11540 <https://github.com/scipy/scipy/pull/11540>`__: MAINT: Fixed two
unused imports in scipy/misc.
* `#11541 <https://github.com/scipy/scipy/pull/11541>`__: MAINT: Fixed
several unused imports and unused assignments in...
* `#11542 <https://github.com/scipy/scipy/pull/11542>`__: MAINT: Fixed an
unused import in scipy/odr.
* `#11543 <https://github.com/scipy/scipy/pull/11543>`__: MAINT: Fixed
several unused imports and unused assignments in...
* `#11544 <https://github.com/scipy/scipy/pull/11544>`__: MAINT: Fixed
unused imports and unused assignments in scipy/integrate.
* `#11545 <https://github.com/scipy/scipy/pull/11545>`__: MAINT: Removed
unused imports and fixed unused assignments in...
* `#11546 <https://github.com/scipy/scipy/pull/11546>`__: MAINT: Removed
unused imports; fixed unused assignments in scipy/signal.
* `#11547 <https://github.com/scipy/scipy/pull/11547>`__: MAINT: Removed
unused imports; fixed unused assignments in scipy/spatial
* `#11548 <https://github.com/scipy/scipy/pull/11548>`__: MAINT: Removed
unused imports; fixed unused assignments in scipy.sparse.
* `#11549 <https://github.com/scipy/scipy/pull/11549>`__: MAINT: Replace
xrange with range
* `#11560 <https://github.com/scipy/scipy/pull/11560>`__: MAINT: stats:
remove an _argcheck call
* `#11573 <https://github.com/scipy/scipy/pull/11573>`__: MAINT: Removed
unused imports; fixed unused assignments in scipy/stats.
* `#11574 <https://github.com/scipy/scipy/pull/11574>`__: MAINT: Small
change to \`optimize.nnls\` error messages.
* `#11575 <https://github.com/scipy/scipy/pull/11575>`__: MAINT: Update
sytrd/hetrd tests
* `#11582 <https://github.com/scipy/scipy/pull/11582>`__: MAINT: fix typo
in quadpack.py closes #11448
* `#11585 <https://github.com/scipy/scipy/pull/11585>`__: TST: add
openblas_support.py
* `#11587 <https://github.com/scipy/scipy/pull/11587>`__: BUG: Differential
evolution with LinearConstraint with sparse...
* `#11588 <https://github.com/scipy/scipy/pull/11588>`__: MAINT: Fully
display problem size in lsmr/lsqr.
* `#11589 <https://github.com/scipy/scipy/pull/11589>`__: MAINT: Remove
Python 2 workarounds
* `#11590 <https://github.com/scipy/scipy/pull/11590>`__: MAINT: Remove
Python2 module init
* `#11605 <https://github.com/scipy/scipy/pull/11605>`__: Standardization
of bounds in _linprog_util.py
* `#11608 <https://github.com/scipy/scipy/pull/11608>`__: BUG: fix use of
is in DE callback
* `#11614 <https://github.com/scipy/scipy/pull/11614>`__: TST, MAINT:
TestCtypesQuad skip with pytest
* `#11619 <https://github.com/scipy/scipy/pull/11619>`__: ENH: add
nan_policy argument and functionality to stats.mstats.winsorize
* `#11621 <https://github.com/scipy/scipy/pull/11621>`__: MAINT: Cleanup
uses of PY_VERSION_HEX, NPY_PY3K in ndimage
* `#11622 <https://github.com/scipy/scipy/pull/11622>`__: MAINT: Cleanup
uses of PY_VERSION_HEX, NPY_PY3K in sparse
* `#11623 <https://github.com/scipy/scipy/pull/11623>`__: MAINT: Remove
unnecessary 'from __future__ import ...' statements
* `#11626 <https://github.com/scipy/scipy/pull/11626>`__: MAINT: Cleanup
uses of PY_VERSION_HEX
* `#11627 <https://github.com/scipy/scipy/pull/11627>`__: ENH: add analytic
formula for normal moments
* `#11628 <https://github.com/scipy/scipy/pull/11628>`__: MAINT, TST:
adjust azure for matplotlib release
* `#11631 <https://github.com/scipy/scipy/pull/11631>`__: Revert to old
behaviour for constant cost matrices in \`linear_sum_assignment\`
* `#11632 <https://github.com/scipy/scipy/pull/11632>`__: MAINT: Define
ARRAY_ANYORDER with DEF instead of cdef
* `#11639 <https://github.com/scipy/scipy/pull/11639>`__: BUG:
interpolate/interp1d: fail gracefully on all-nan inputs
* `#11640 <https://github.com/scipy/scipy/pull/11640>`__: MAINT: Fix BLAS3
trmm wrapper for "side" arg
* `#11642 <https://github.com/scipy/scipy/pull/11642>`__: TST, MAINT:
remove dead code in Travis CI
* `#11643 <https://github.com/scipy/scipy/pull/11643>`__: MAINT: fix
conversion in binom_test
* `#11645 <https://github.com/scipy/scipy/pull/11645>`__: MAINT: Assorted
clean up.
* `#11646 <https://github.com/scipy/scipy/pull/11646>`__: MAINT: Remove
unnecessary 'from __future__ import ...' statements
* `#11647 <https://github.com/scipy/scipy/pull/11647>`__: DOC: document
return_all arguments
* `#11648 <https://github.com/scipy/scipy/pull/11648>`__: Perform geometric
slerp in quaternion space
* `#11651 <https://github.com/scipy/scipy/pull/11651>`__: DOC: Update paper
URL in lambertw documentation
* `#11653 <https://github.com/scipy/scipy/pull/11653>`__: PERF: Switch to
C++ STL std::nth_element
* `#11655 <https://github.com/scipy/scipy/pull/11655>`__: MAINT: Remove
Python2 cStringStream
* `#11657 <https://github.com/scipy/scipy/pull/11657>`__: ENH: Add wrapper
for ?pttrf/?pttrs
* `#11664 <https://github.com/scipy/scipy/pull/11664>`__: ENH: Add wrapper
for ?gejsv
* `#11665 <https://github.com/scipy/scipy/pull/11665>`__: ENH: Add wrapper
for ?pteqr
* `#11667 <https://github.com/scipy/scipy/pull/11667>`__: BUG: Non-central
Fisher distribution (fix nan-values when nc=0)
* `#11668 <https://github.com/scipy/scipy/pull/11668>`__: ENH: Add wrapper
for ?gtsvx
* `#11671 <https://github.com/scipy/scipy/pull/11671>`__: TST, CI: restore
Azure temporarily
* `#11672 <https://github.com/scipy/scipy/pull/11672>`__: Add warning to
medfilt when array size < kernel_size
* `#11674 <https://github.com/scipy/scipy/pull/11674>`__: TST: bump test
precision for two np.dot related linalg tests.
* `#11675 <https://github.com/scipy/scipy/pull/11675>`__: MAINT:
pycodestyle clean-up
* `#11677 <https://github.com/scipy/scipy/pull/11677>`__: ENH: Add wrapper
for ?ptsvx
* `#11679 <https://github.com/scipy/scipy/pull/11679>`__: BENCH: cKDTree
benchmarks added: balanced/unbalanced tree (related...
* `#11680 <https://github.com/scipy/scipy/pull/11680>`__: MAINT:
rng_integers allows RandomState.randint or Generator.integers
* `#11683 <https://github.com/scipy/scipy/pull/11683>`__: BUG: fix
mode='mirror' on length 1 axes
* `#11684 <https://github.com/scipy/scipy/pull/11684>`__: BUG: fix
scipy.special.voigt_profile
* `#11687 <https://github.com/scipy/scipy/pull/11687>`__: MAINT:
sparse.linalg: avoid importing from \`np.core\`
* `#11688 <https://github.com/scipy/scipy/pull/11688>`__: ENH: mypy: get
specific about ignoring missing imports
* `#11690 <https://github.com/scipy/scipy/pull/11690>`__: MAINT: mypy: fix
errors about incompatible types in lists
* `#11692 <https://github.com/scipy/scipy/pull/11692>`__: MAINT: mypy: fix
remaining type errors
* `#11694 <https://github.com/scipy/scipy/pull/11694>`__: TST, MAINT: bump
to OpenBLAS 0.3.9 stable, raise tol for Win...
* `#11697 <https://github.com/scipy/scipy/pull/11697>`__: DOC: fix pdf of
norminvgauss in scipy.stats
* `#11701 <https://github.com/scipy/scipy/pull/11701>`__: MAINT: special:
add rudimentary types for \`_ufuncs\` extension...
* `#11702 <https://github.com/scipy/scipy/pull/11702>`__: BUG: Fixed a
post-merge bug for eigh()
* `#11703 <https://github.com/scipy/scipy/pull/11703>`__: Improves
docstring with consistent L2-norm
* `#11705 <https://github.com/scipy/scipy/pull/11705>`__: DOC: Slerp the
SphericalVoronoi docstring
* `#11706 <https://github.com/scipy/scipy/pull/11706>`__: ENH: mypy: add
\`--mypy\` option to \`runtests.py\`
* `#11710 <https://github.com/scipy/scipy/pull/11710>`__: ENH: Modified
stats.kstest() to use the exact stats.kstwo.sf()...
* `#11715 <https://github.com/scipy/scipy/pull/11715>`__: DOC: add ..
versionadded:: to as_matrix/from_matrix in spatial/transf???
* `#11716 <https://github.com/scipy/scipy/pull/11716>`__: BENCH: fix
benchmark imports for \`\`optimize_linprog.py\`\`
* `#11721 <https://github.com/scipy/scipy/pull/11721>`__: MAINT: io: Remove
now-unnecessary \`# type: ignore\`
* `#11722 <https://github.com/scipy/scipy/pull/11722>`__: MAINT: mypy:
remove mpmath from the ratchet
* `#11726 <https://github.com/scipy/scipy/pull/11726>`__: Handle constant
input for scipy.stats.f_oneway
* `#11729 <https://github.com/scipy/scipy/pull/11729>`__: BENCH: optimize:
added infeasible benchmarks for linprog
* `#11731 <https://github.com/scipy/scipy/pull/11731>`__: fix inaccurate
information about Mac OS compiler (#11696)
* `#11733 <https://github.com/scipy/scipy/pull/11733>`__: Fix inaccurate
docstring example of HalfspaceIntersection
* `#11734 <https://github.com/scipy/scipy/pull/11734>`__: Doc: fix
inaccurate docstring of SmoothBivariateSpline.
* `#11735 <https://github.com/scipy/scipy/pull/11735>`__: Bug: stats: fix
wrong shape from median_absolute_deviation for...
* `#11736 <https://github.com/scipy/scipy/pull/11736>`__: ENH: add input
validations and its tests for FITPACK in fitpack2.py
* `#11737 <https://github.com/scipy/scipy/pull/11737>`__: BUG: Prevent
crashes due to MKL bug in ?heevr
* `#11739 <https://github.com/scipy/scipy/pull/11739>`__: MAINT: special:
add type stubs for \`_test_round.pyx\`
* `#11740 <https://github.com/scipy/scipy/pull/11740>`__: MAINT: special:
remove unused specfun f2py wrappers
* `#11741 <https://github.com/scipy/scipy/pull/11741>`__: BUG: fix small
tolerances handling for minpack and add a test.
* `#11743 <https://github.com/scipy/scipy/pull/11743>`__: Doc: fix
docstring of rfft, rfft2, rfftn, irfft, irfft2, irfftn...
* `#11744 <https://github.com/scipy/scipy/pull/11744>`__: MAINT: Remove
unused py3k.h code
* `#11745 <https://github.com/scipy/scipy/pull/11745>`__: DOC: stats: Clean
up ncf documentation.
* `#11748 <https://github.com/scipy/scipy/pull/11748>`__: MAINT: special:
type \`cython_special\` as \`Any\`
* `#11750 <https://github.com/scipy/scipy/pull/11750>`__: MAINT: type hints
for \`_spherical_voronoi\`
* `#11752 <https://github.com/scipy/scipy/pull/11752>`__: DOC: fix
docstring of scipy.optimize.least_squares
* `#11753 <https://github.com/scipy/scipy/pull/11753>`__: ENH: add input
validation for dendrogram and a test.
* `#11755 <https://github.com/scipy/scipy/pull/11755>`__: MAINT: Replace
uses of tostring with tobytes
* `#11757 <https://github.com/scipy/scipy/pull/11757>`__: ENH: improve
binned_statistics_2d performance.
* `#11759 <https://github.com/scipy/scipy/pull/11759>`__: ENH: optimize:
add HiGHS methods to linprog
* `#11760 <https://github.com/scipy/scipy/pull/11760>`__: MAINT: Remove
FileStream replaced by GenericStream
* `#11761 <https://github.com/scipy/scipy/pull/11761>`__: MAINT: Replace
npy_3kcompat.h shims
* `#11765 <https://github.com/scipy/scipy/pull/11765>`__: TST: Speedup
test_pascal which is VERY slow on Azure
* `#11766 <https://github.com/scipy/scipy/pull/11766>`__: TST: speed up
differential_evolution L8 test
* `#11767 <https://github.com/scipy/scipy/pull/11767>`__: Change comment in
continuous rv gamma fit function
* `#11776 <https://github.com/scipy/scipy/pull/11776>`__: Add domain option
for resample.
* `#11784 <https://github.com/scipy/scipy/pull/11784>`__: BUG: Fixed
calculation of nonzero elements in scipy.sparse.random
* `#11786 <https://github.com/scipy/scipy/pull/11786>`__: ENH: stats: add
axis keyword argument to scipy.stats.rankdata
* `#11789 <https://github.com/scipy/scipy/pull/11789>`__: Doc: fix
docstring of scipy.spatial.chebyshev
* `#11792 <https://github.com/scipy/scipy/pull/11792>`__: DOC: dev: add
guidelines for developing public Cython APIs
* `#11794 <https://github.com/scipy/scipy/pull/11794>`__: MAINT: add
comments explaining a problem in cython_optimize organization
* `#11796 <https://github.com/scipy/scipy/pull/11796>`__: DOC: add a note
about precision losing in csgraph.minimum_spanning_tree...
* `#11797 <https://github.com/scipy/scipy/pull/11797>`__: ENH: Allow
negative \`axis\` in \`interpolate.BSpline\`. Also...
* `#11798 <https://github.com/scipy/scipy/pull/11798>`__: Add
simplify_cells parameter to scipy.io.loadmat
* `#11801 <https://github.com/scipy/scipy/pull/11801>`__: MAINT, DOC: minor
changes of ratio-of-uniforms in scipy.stats
* `#11802 <https://github.com/scipy/scipy/pull/11802>`__: BUG: fix
scipy.odr to handle multidimensional independent and...
* `#11803 <https://github.com/scipy/scipy/pull/11803>`__:
scipy.stats.trapz: Use analytic formulas for stats and entropy.
* `#11808 <https://github.com/scipy/scipy/pull/11808>`__: DOC: add Examples
in the scipy.interpolate.interpn docstring.
* `#11809 <https://github.com/scipy/scipy/pull/11809>`__: Duplicate entries
are added together in csr_matrix constructor
* `#11813 <https://github.com/scipy/scipy/pull/11813>`__: MAINT: bump
pyflakes to version 2.1.1
* `#11814 <https://github.com/scipy/scipy/pull/11814>`__: BUG:
scipy.sparse.csr doctest failing with incorrect output value
* `#11817 <https://github.com/scipy/scipy/pull/11817>`__: DOC: add Examples
in the scipy.optimize.leastsq docstring
* `#11820 <https://github.com/scipy/scipy/pull/11820>`__: ENH: Raise an
error on incorrect bounds format in optimize.fmin_l_bfgs_b
* `#11822 <https://github.com/scipy/scipy/pull/11822>`__: CI: add github
actions for macOS
* `#11824 <https://github.com/scipy/scipy/pull/11824>`__: DOC: add Examples
in scipy.optimize.line_search docstring (line_search_wolfe2)
* `#11830 <https://github.com/scipy/scipy/pull/11830>`__: TST: Always use
fork for multiprocessing in fft tests
* `#11831 <https://github.com/scipy/scipy/pull/11831>`__: DOC: add Examples
and Returns in scipy.misc.central_diff_weights...
* `#11832 <https://github.com/scipy/scipy/pull/11832>`__: DOC: stats: Some
small corrections to a couple docstrings.
* `#11833 <https://github.com/scipy/scipy/pull/11833>`__: BUG: Fix
compiler_name when there are paths used in flags
* `#11836 <https://github.com/scipy/scipy/pull/11836>`__: MAINT:
re-introduce multiprocessing tests on Python3.8
* `#11837 <https://github.com/scipy/scipy/pull/11837>`__: Doc: add Examples
in scipy.optimize.fsolve docstring
* `#11838 <https://github.com/scipy/scipy/pull/11838>`__: Doc: add Examples
in scipy.sparse.linalg.minres docstring
* `#11840 <https://github.com/scipy/scipy/pull/11840>`__: BUG:
sparse.linalg: fix overflow in expm intermediate computation
* `#11842 <https://github.com/scipy/scipy/pull/11842>`__: BLD: fix build
with gfortran 10
* `#11843 <https://github.com/scipy/scipy/pull/11843>`__: MAINT: Simplify
floats in constants.py
* `#11847 <https://github.com/scipy/scipy/pull/11847>`__: DOC: add a
tutorial of scipy.optimize.linprog
* `#11849 <https://github.com/scipy/scipy/pull/11849>`__: ENH: speed up
geninvgauss by using cython
* `#11852 <https://github.com/scipy/scipy/pull/11852>`__: CI: remove osx
from travisCI
* `#11857 <https://github.com/scipy/scipy/pull/11857>`__: BUG: Change
parameter fc of gausspulse to float.
* `#11861 <https://github.com/scipy/scipy/pull/11861>`__: order = degree +
1 for splines
* `#11863 <https://github.com/scipy/scipy/pull/11863>`__: Make g77 ABI
wrapper work with gfortran ABI lapack
* `#11866 <https://github.com/scipy/scipy/pull/11866>`__: MAINT: add type
ignores to sympy and matplotlib imports
* `#11867 <https://github.com/scipy/scipy/pull/11867>`__: CI: Add arm64 in
travis-ci
* `#11869 <https://github.com/scipy/scipy/pull/11869>`__: DOC: signal: Add
an example to the lsim2 docstring.
* `#11870 <https://github.com/scipy/scipy/pull/11870>`__: DOC: signal: Use
impulse instead of impulse2 in the impulse example...
* `#11871 <https://github.com/scipy/scipy/pull/11871>`__: ENH: type ufuncs
in special as ufuncs instead of Any
* `#11872 <https://github.com/scipy/scipy/pull/11872>`__: BUG: avoid
recomputing in scipy.optimize.optimize.MemoizeJac
* `#11873 <https://github.com/scipy/scipy/pull/11873>`__: DOC: signal: Fix
ODE in impulse and impulse2 docstrings.
* `#11874 <https://github.com/scipy/scipy/pull/11874>`__: DOC: add Examples
of docstring for scipy.interpolate.approximate_taylor_polynomial
* `#11878 <https://github.com/scipy/scipy/pull/11878>`__: DOC: fixed a typo
under scipy/integrate/quadrature.py
* `#11879 <https://github.com/scipy/scipy/pull/11879>`__: BUG: Fix index
arrays overflow in sparse.kron
* `#11880 <https://github.com/scipy/scipy/pull/11880>`__: DOC: stats: Add
Examples for bartlett, fligner, levene.
* `#11881 <https://github.com/scipy/scipy/pull/11881>`__: MAINT: normalise
numpy-->np in optimize.py
* `#11882 <https://github.com/scipy/scipy/pull/11882>`__: DOC: add Examples
for scipy.io.readsav docstring.
* `#11883 <https://github.com/scipy/scipy/pull/11883>`__: DOC: add Returns
and Examples for scipy.ndimage.correlate() docstring
* `#11885 <https://github.com/scipy/scipy/pull/11885>`__: BUG: stats:
Handle multidimensional arrays in f_oneway, and more.
* `#11889 <https://github.com/scipy/scipy/pull/11889>`__: DOC: signal:
Unify lsim and lsim2 examples.
* `#11896 <https://github.com/scipy/scipy/pull/11896>`__: BUG: stats: Fix
handling of size 0 inputs for ttest_rel and ttest_ind.
* `#11897 <https://github.com/scipy/scipy/pull/11897>`__: DOC: Remove
misleading default values from fit method
* `#11898 <https://github.com/scipy/scipy/pull/11898>`__: MAINT:
LinearVectorFunction.J is ndarray closes #11886
* `#11902 <https://github.com/scipy/scipy/pull/11902>`__: BUG: linalg:
test_heequb failure
* `#11904 <https://github.com/scipy/scipy/pull/11904>`__: fix real-to-real
transforms for complex inputs and overwrite_x=True
* `#11906 <https://github.com/scipy/scipy/pull/11906>`__: DOC: stats: fix
error caused by trapz docstring
* `#11907 <https://github.com/scipy/scipy/pull/11907>`__: BUG: stats: fixed
SEGFAULT from Issue #9710
* `#11912 <https://github.com/scipy/scipy/pull/11912>`__: ENH: Respect
matplotlib color palette with hierarchy/dendrogram.
* `#11914 <https://github.com/scipy/scipy/pull/11914>`__: DOC: refine doc
for spatial.distance.squareform
* `#11915 <https://github.com/scipy/scipy/pull/11915>`__: ENH: Ndim linear
operator
* `#11919 <https://github.com/scipy/scipy/pull/11919>`__: ENH: expose
"window_size" parameter in find_peaks_cwt()
* `#11920 <https://github.com/scipy/scipy/pull/11920>`__: DOC: explain M,
diffev
* `#11923 <https://github.com/scipy/scipy/pull/11923>`__: CI: macOS install
swig closes #11922
* `#11924 <https://github.com/scipy/scipy/pull/11924>`__: DOC: add Examples
for scipy.optimize.bracket() docstring
* `#11930 <https://github.com/scipy/scipy/pull/11930>`__: DOC: add Examples
and clean up for signal.qspline1d and signal.qspline_eval...
* `#11931 <https://github.com/scipy/scipy/pull/11931>`__: DOC: add Examples
for sparse.linalg.bicg docstring.
* `#11933 <https://github.com/scipy/scipy/pull/11933>`__: DOC: Add original
reference for Yao-Liu objective functions
* `#11934 <https://github.com/scipy/scipy/pull/11934>`__: DOC, MAINT:
mailmap update
* `#11935 <https://github.com/scipy/scipy/pull/11935>`__: DOC: make
scipy.stats.mode documentation reflect that the function...
* `#11936 <https://github.com/scipy/scipy/pull/11936>`__: ENH: special: add
type stubs for \`orthogonal.py\`
* `#11937 <https://github.com/scipy/scipy/pull/11937>`__: DOC: Add
docstring examples to fft2, ifft2, io.savemat
* `#11938 <https://github.com/scipy/scipy/pull/11938>`__: MAINT: add helper
function for deprecating Cython API functions
* `#11942 <https://github.com/scipy/scipy/pull/11942>`__: MAINT: ignore
conditional import in _lib/_util
* `#11943 <https://github.com/scipy/scipy/pull/11943>`__: MAINT: special:
add types for geterr/seterr/errstate
* `#11946 <https://github.com/scipy/scipy/pull/11946>`__: MAINT: add
py.typed marker
* `#11950 <https://github.com/scipy/scipy/pull/11950>`__: TST:MAINT:
separated and stabilized heequb tests
* `#11952 <https://github.com/scipy/scipy/pull/11952>`__: DOC: update
toolchain roadmap for py38, C99, C++11/14
* `#11957 <https://github.com/scipy/scipy/pull/11957>`__: MAINT: Use
np.errstate context manager instead of np.seterr.
* `#11958 <https://github.com/scipy/scipy/pull/11958>`__: MAINT:
interpolate: Remove some trailing spaces.
* `#11960 <https://github.com/scipy/scipy/pull/11960>`__: MAINT: Cleanup
Python2 compatibility code
* `#11961 <https://github.com/scipy/scipy/pull/11961>`__: MAINT: Remove
numpy/npy_3kcompat.h from _superluobject.c
* `#11962 <https://github.com/scipy/scipy/pull/11962>`__: DOC: Fix type of
\`codes\` in docstring of \`_vq._vq()\`
* `#11964 <https://github.com/scipy/scipy/pull/11964>`__: MAINT: Cleanup
unused IS_PYPY
* `#11969 <https://github.com/scipy/scipy/pull/11969>`__: DOC: add Examples
and fix docstring for special.airye
* `#11970 <https://github.com/scipy/scipy/pull/11970>`__: BUG: sparse:
'diagonal' of sparse matrices fixed to match numpy's...
* `#11974 <https://github.com/scipy/scipy/pull/11974>`__: BUG: Reshape
oaconvolve output even when no axes are convolved
* `#11976 <https://github.com/scipy/scipy/pull/11976>`__: MAINT: add logo
for github actions
* `#11977 <https://github.com/scipy/scipy/pull/11977>`__: CI: test bleeding
edge Python
* `#11979 <https://github.com/scipy/scipy/pull/11979>`__: DOC: add Examples
for stats.ranksums() docstring.
* `#11982 <https://github.com/scipy/scipy/pull/11982>`__: Fix KMeans++
initialisation slowness
* `#11983 <https://github.com/scipy/scipy/pull/11983>`__: DOC: add Examples
for stats.mstats.argstoarray() docstring.
* `#11986 <https://github.com/scipy/scipy/pull/11986>`__: Avoid bugs in
ndimage when the output and input arrays overlap...
* `#11988 <https://github.com/scipy/scipy/pull/11988>`__: ENH: Override fit
method of Laplace distribution with Maximum...
* `#11993 <https://github.com/scipy/scipy/pull/11993>`__: TST, CI: Azure
Windows path fixups
* `#11995 <https://github.com/scipy/scipy/pull/11995>`__: MAINT, CI: remove
custom mingw Azure
* `#11996 <https://github.com/scipy/scipy/pull/11996>`__: DOC: add Examples
and fix pep warning for fft.set_global_backend...
* `#11997 <https://github.com/scipy/scipy/pull/11997>`__: MAINT, CI: Azure
OpenBLAS simplify
* `#11998 <https://github.com/scipy/scipy/pull/11998>`__: BENCH: Run
against current HEAD instead of master
* `#12001 <https://github.com/scipy/scipy/pull/12001>`__: ENH: stats:
Implement _logpdf for the maxwell distribution.
* `#12004 <https://github.com/scipy/scipy/pull/12004>`__: DOC: add examples
for integrate.quad_vec() and integrate.quad_explain()
* `#12005 <https://github.com/scipy/scipy/pull/12005>`__: MAINT: Use helper
functions in ?tbtrs tests
* `#12007 <https://github.com/scipy/scipy/pull/12007>`__: MAINT: updated
LICENSES_bundled for pybind11 and six
* `#12008 <https://github.com/scipy/scipy/pull/12008>`__: DOC: roadmap
update
* `#12009 <https://github.com/scipy/scipy/pull/12009>`__: ENH: optimize:
support 64-bit BLAS in lbfgsb
* `#12010 <https://github.com/scipy/scipy/pull/12010>`__: ENH:
sparse.linalg: support 64-bit BLAS in isolve
* `#12012 <https://github.com/scipy/scipy/pull/12012>`__: DOC: add Examples
for interpolate.barycentric_interpolate(),...
* `#12013 <https://github.com/scipy/scipy/pull/12013>`__: MAINT: remove
last uses of numpy.dual
* `#12014 <https://github.com/scipy/scipy/pull/12014>`__: CI: print 10
slowest tests
* `#12020 <https://github.com/scipy/scipy/pull/12020>`__: MAINT: Removed
handling of circular input in SphericalVoronoi
* `#12022 <https://github.com/scipy/scipy/pull/12022>`__: DOC : added
default value of absolute_sigma to False in scipy.optimize.curve_fit docs
* `#12024 <https://github.com/scipy/scipy/pull/12024>`__: DOC: add Examples
for io.hb_read() and io.hb_write()
* `#12025 <https://github.com/scipy/scipy/pull/12025>`__: MAINT: Remove
numpy/npy_3kcompat.h from nd_image
* `#12028 <https://github.com/scipy/scipy/pull/12028>`__: Spelling
correction
* `#12030 <https://github.com/scipy/scipy/pull/12030>`__: ENH:
optimize/_trlib: support ILP64 blas/lapack
* `#12036 <https://github.com/scipy/scipy/pull/12036>`__: MAINT: Add some
generated C files .gitignore
* `#12038 <https://github.com/scipy/scipy/pull/12038>`__: MAINT, CI: Travis
rackcdn->conda.org
* `#12039 <https://github.com/scipy/scipy/pull/12039>`__: MAINT: signal:
Lower the resolution of the plots in the chirp...
* `#12040 <https://github.com/scipy/scipy/pull/12040>`__: DOC: add Examples
for ndimage.spline_filter1d() and spline_filter()...
* `#12044 <https://github.com/scipy/scipy/pull/12044>`__: MAINT: combine
apt-get update and apt-get install into one RUN
* `#12045 <https://github.com/scipy/scipy/pull/12045>`__: TST: Reduce size
of test_diagonal_types to speed up tests
* `#12046 <https://github.com/scipy/scipy/pull/12046>`__: MAINT: Remove
unused npy_3kcompat.h
* `#12047 <https://github.com/scipy/scipy/pull/12047>`__: MAINT: Cython 3.0
compat
* `#12050 <https://github.com/scipy/scipy/pull/12050>`__: DOC: add download
number badges of PyPI and conda-forge in README.rst
* `#12052 <https://github.com/scipy/scipy/pull/12052>`__: DOC: add Examples
odr.models.polynomial() and fix odr.odr docstring...
* `#12056 <https://github.com/scipy/scipy/pull/12056>`__: ENH: Modifies
shapiro to return a named tuple
* `#12057 <https://github.com/scipy/scipy/pull/12057>`__: Adding my name
into THANKS.txt
* `#12060 <https://github.com/scipy/scipy/pull/12060>`__: TST: Reduce
number of test_diagonal_types configs
* `#12062 <https://github.com/scipy/scipy/pull/12062>`__: TST: Change
dec.slow to pytest.mark.slow
* `#12068 <https://github.com/scipy/scipy/pull/12068>`__: ENH: Modifies
jarque_bera to return a named tuple
* `#12070 <https://github.com/scipy/scipy/pull/12070>`__: MAINT, CI:
appveyor rack->conda.org
* `#12072 <https://github.com/scipy/scipy/pull/12072>`__: TST: filter out
factorial(float) deprecation warning
* `#12078 <https://github.com/scipy/scipy/pull/12078>`__: TST: Skip test on
colab with large memory alloc
* `#12079 <https://github.com/scipy/scipy/pull/12079>`__: DOC: Remove
Python2 reference from stats tutorial
* `#12081 <https://github.com/scipy/scipy/pull/12081>`__: DOC: add Examples
docstring for optimize.show_options()
* `#12084 <https://github.com/scipy/scipy/pull/12084>`__: BUG: interpolate:
fix BarycentricInterpolator with integer input...
* `#12089 <https://github.com/scipy/scipy/pull/12089>`__: ENH:
spatial/qhull: support ILP64 Lapack
* `#12090 <https://github.com/scipy/scipy/pull/12090>`__: ENH: integrate:
support ILP64 BLAS in odeint/vode/lsoda
* `#12091 <https://github.com/scipy/scipy/pull/12091>`__: ENH: integrate:
support ILP64 in quadpack
* `#12092 <https://github.com/scipy/scipy/pull/12092>`__: BUG: Fix dropping
dt in signal.StateSpace
* `#12093 <https://github.com/scipy/scipy/pull/12093>`__: MAINT: Rollback
python2.6 workaround
* `#12094 <https://github.com/scipy/scipy/pull/12094>`__: MAINT:
\`openblas_support\` hash checks
* `#12095 <https://github.com/scipy/scipy/pull/12095>`__: MAINT: ndimage:
change \`shares_memory\` to \`may_share_memory\`
* `#12098 <https://github.com/scipy/scipy/pull/12098>`__: Doc: change 4
model instances of odr to be instances of \`Model\`...
* `#12101 <https://github.com/scipy/scipy/pull/12101>`__: Removed more
unused imports and assignments.
* `#12107 <https://github.com/scipy/scipy/pull/12107>`__: ENH: Area
calculation for 2D inputs in SphericalVoronoi
* `#12108 <https://github.com/scipy/scipy/pull/12108>`__: MAINT: ensure
attributes have correct data type in \`SphericalVoronoi\`
* `#12109 <https://github.com/scipy/scipy/pull/12109>`__: degree is not
order in splines
* `#12110 <https://github.com/scipy/scipy/pull/12110>`__: ENH: More
helpful/forgiving io.wavfile errors
* `#12117 <https://github.com/scipy/scipy/pull/12117>`__: BUG: fix newline
* `#12123 <https://github.com/scipy/scipy/pull/12123>`__: [MAINT] Fix error
on PyData/Sparse import.
* `#12124 <https://github.com/scipy/scipy/pull/12124>`__: TST: Always test
matmul now that Python3.5+ is required
* `#12126 <https://github.com/scipy/scipy/pull/12126>`__: TST: Cleanup
unused matplotlib code.
* `#12127 <https://github.com/scipy/scipy/pull/12127>`__: DOC: update
docstrings of signal.cspline2d, qspline2d, sepfir2d
* `#12130 <https://github.com/scipy/scipy/pull/12130>`__: MAINT: Fixing
broken links with linkchecker
* `#12135 <https://github.com/scipy/scipy/pull/12135>`__: ENH: linalg: Add
the function convolution_matrix.
* `#12136 <https://github.com/scipy/scipy/pull/12136>`__: MAINT: Cleanup
np.poly1d hack
* `#12137 <https://github.com/scipy/scipy/pull/12137>`__: TST, CI:
reproduce wheels 32-bit setup
* `#12140 <https://github.com/scipy/scipy/pull/12140>`__: TST: stats: add
kstwo, ksone to slow tests.
* `#12141 <https://github.com/scipy/scipy/pull/12141>`__: Support 64-bit
integer size in Fitpack
* `#12151 <https://github.com/scipy/scipy/pull/12151>`__: DOC: Correct
Rosenbrock function sum
* `#12159 <https://github.com/scipy/scipy/pull/12159>`__: BUG: Fix length
calculation in upfirdn
* `#12160 <https://github.com/scipy/scipy/pull/12160>`__: BUG: Fix M_PI
* `#12168 <https://github.com/scipy/scipy/pull/12168>`__: DOC: add an
obsolete version checking javascript to doc release...
* `#12171 <https://github.com/scipy/scipy/pull/12171>`__: CI, MAINT: Azure
OpenBLAS drive flip
* `#12172 <https://github.com/scipy/scipy/pull/12172>`__: ENH: Bounds for
the Powell minimization method
* `#12175 <https://github.com/scipy/scipy/pull/12175>`__: BLD: support more
Fortran compilers for ilp64 and macro expansion...
* `#12179 <https://github.com/scipy/scipy/pull/12179>`__: BUG: stats: A few
distributions didn't accept lists as arguments.
* `#12180 <https://github.com/scipy/scipy/pull/12180>`__: MAINT: removed
redundant import in SphericalVoronoi tests
* `#12181 <https://github.com/scipy/scipy/pull/12181>`__: DOC: for
versionwarning don't use $.getScript
* `#12182 <https://github.com/scipy/scipy/pull/12182>`__: MAINT: random
sampling on the hypersphere in SphericalVoronoi...
* `#12194 <https://github.com/scipy/scipy/pull/12194>`__: MAINT: Module and
example cleanups for doc build
* `#12202 <https://github.com/scipy/scipy/pull/12202>`__: ENH: tool to DL
release wheels from Anaconda
* `#12210 <https://github.com/scipy/scipy/pull/12210>`__: Remove py.typed
marker (at least for the release)
* `#12217 <https://github.com/scipy/scipy/pull/12217>`__: BUG: stats: Fix
handling of edge cases in median_abs_deviation.
* `#12223 <https://github.com/scipy/scipy/pull/12223>`__: BUG: stats:
wilcoxon returned p > 1 for certain inputs.
* `#12227 <https://github.com/scipy/scipy/pull/12227>`__: BLD: Set macos
min version when building rectangular_lsap
* `#12229 <https://github.com/scipy/scipy/pull/12229>`__: MAINT:
tools/gh_lists.py: fix http header case sensitivity issue
* `#12236 <https://github.com/scipy/scipy/pull/12236>`__: DOC: Fix a couple
grammatical mistakes in 1.5.0-notes.rst.


Checksums
=========

MD5
~~~

06ae131459a8f9f3c937fd93df34941d
 scipy-1.5.0rc1-cp36-cp36m-macosx_10_9_x86_64.whl
dccbe43624b6653f6456573507575cee
 scipy-1.5.0rc1-cp36-cp36m-manylinux1_i686.whl
d8f025f467888674450ed38515083494
 scipy-1.5.0rc1-cp36-cp36m-manylinux1_x86_64.whl
64c3f1654e715bc08fc7e092b8262c30  scipy-1.5.0rc1-cp36-cp36m-win32.whl
3a8ec7956496ed7ee72beaf00421b1d0  scipy-1.5.0rc1-cp36-cp36m-win_amd64.whl
7e6860a337c06d79a19fbef7174acd41
 scipy-1.5.0rc1-cp37-cp37m-macosx_10_9_x86_64.whl
d825cf7fe16d80ad3584492589dc3460
 scipy-1.5.0rc1-cp37-cp37m-manylinux1_i686.whl
919412506218a00076538d8af5d7298d
 scipy-1.5.0rc1-cp37-cp37m-manylinux1_x86_64.whl
2979169481de902e252dc451154c477a  scipy-1.5.0rc1-cp37-cp37m-win32.whl
5f48084c65734a4aeae510f21bcf792a  scipy-1.5.0rc1-cp37-cp37m-win_amd64.whl
892607da25980af624c4a0cd82ff557f
 scipy-1.5.0rc1-cp38-cp38-macosx_10_9_x86_64.whl
fb0bcb4d0646e28e093154a98d3bf3eb
 scipy-1.5.0rc1-cp38-cp38-manylinux1_i686.whl
827b361a0db6671b42ed5aad4a8a906c
 scipy-1.5.0rc1-cp38-cp38-manylinux1_x86_64.whl
f71920b927c3d2eaed4df6c65407a56a  scipy-1.5.0rc1-cp38-cp38-win32.whl
eacc04102822177622c4e0d5061d580d  scipy-1.5.0rc1-cp38-cp38-win_amd64.whl
4dccc1db984fc0fb92697e464774e4da  scipy-1.5.0rc1.tar.gz
fad54bb2d322f02d4050e521cb856a27  scipy-1.5.0rc1.tar.xz
62867d716dfcb8ae9bd907da479c6926  scipy-1.5.0rc1.zip

SHA256
~~~~~~

ce0164965caadd3a53583ad63643679ccea70b6bb25a691e4a74d3e87e3fffea
 scipy-1.5.0rc1-cp36-cp36m-macosx_10_9_x86_64.whl
6591dc05981308fb620c3705bf684b57241b73fe9369748f36eaf7069969c67e
 scipy-1.5.0rc1-cp36-cp36m-manylinux1_i686.whl
b5d756e25e26184d19172db49b185a05c618d7c1323588fa261563b451b0dc7b
 scipy-1.5.0rc1-cp36-cp36m-manylinux1_x86_64.whl
a705d1c6b8b9b7a3f5f57aec792be3fce2d65cdf49a8559852084aa18c57af1e
 scipy-1.5.0rc1-cp36-cp36m-win32.whl
d395b63f6bfb737f3b45c8253af7e1761af1cc015db7347cbaacf1f643f3f7b8
 scipy-1.5.0rc1-cp36-cp36m-win_amd64.whl
1f57d75c49f6c8b17b4d9217011e5ecca4d04941eb79a465bdfdf9591f09a312
 scipy-1.5.0rc1-cp37-cp37m-macosx_10_9_x86_64.whl
38cf18ab60d853113137229e328c97719c22b02d3bf8873349472103015de5f7
 scipy-1.5.0rc1-cp37-cp37m-manylinux1_i686.whl
1f402f14e726d41fd34e30b6c54daac36ac84ee64c4a430ed4b5ec016705e053
 scipy-1.5.0rc1-cp37-cp37m-manylinux1_x86_64.whl
52998372c9179ebfbf7e875e4cb29137d4edc2b9d6614c5e57a180501dacf4f0
 scipy-1.5.0rc1-cp37-cp37m-win32.whl
fb642c6c4a19feeeee84a74d1e38c16952fde36c752e4c4a8ed70f9e4d70d5c7
 scipy-1.5.0rc1-cp37-cp37m-win_amd64.whl
eabc685cae91a899f6eff8aed3db3df2ad884df3b46f85314b5ca016d5bb93ea
 scipy-1.5.0rc1-cp38-cp38-macosx_10_9_x86_64.whl
52b693c1f842e126efb7882038680fed920fc2014cad3a16da4673e41dc8d0a9
 scipy-1.5.0rc1-cp38-cp38-manylinux1_i686.whl
25db07c206d81c9dd9b9a0ea4ea4a134026e4cddc83968e99bc2b95ce2b3c760
 scipy-1.5.0rc1-cp38-cp38-manylinux1_x86_64.whl
2a0d8504a08507d6e7b5c2b65db11fdb10ca63245166a5496fe3a781d0d9a452
 scipy-1.5.0rc1-cp38-cp38-win32.whl
142649a4487e8849aa7e3ea11e010f6201683ed56adc02270d2c7a8cdb93a7e8
 scipy-1.5.0rc1-cp38-cp38-win_amd64.whl
e90d679b96b9cbd249e900b2d03558bb01ae161aa9400e9b6cd435cce82552ea
 scipy-1.5.0rc1.tar.gz
e662fba1716763204a38293bf7a157af42c72dec3fc0ea55ff83dc8f49fbf0b5
 scipy-1.5.0rc1.tar.xz
90f6fb35601d3ce52cdc9d53888a92504efec9a267a524bc33ad66a407ce070d
 scipy-1.5.0rc1.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJe0sVbAAoJELD/41ZX0J71n/4P/3012tbgm9o+SaGUiaQy6PGj
TqzuX9vRbJipUUODVXQjDJz85oEKOlTLYFeTB1gS27p1s1DpsGs5rDhPv2t0DFUL
MKDFYGt3xwQf+3JTJXBAuEyIl62H/YrwIUvVJic9lzJ+b/lPm+5G4ax+Iso1H/x+
2hN/KiFsKS/ckQ3P2GYvTmW2WGVhacYd1qJM0NNBJa+12nJmLeFlHrWzC6D3hrT/
w1dlVGW7dbEBpRQ6IrH/TFY+8I+my3DyJlnhCDsKOoSRFvZSAXX5Ajsj9jB3s1l1
vRy/fjM7uTk6WBwLkfi64o01Z0RKL3wB0+mpjXEZd39IayjPT5vzS2iHm1gnpXzv
uxW+Btfem6XJlVEXeG9R7BWe7SDJq1f009QIlUfCB35k/G5y1Cd+F+I4l4hB/Vw+
2zoUgfJT9m/r0VZ2bvoIzLx8Q3fDtFceqMbxSy1HCQ/7BYJ/w/PM8eChKsBj7SgJ
BXh8EzVpSMeWTVuGWtztl9sZKGKJKkEVxuOVVze4V9PNkW4sQDNcz5YmPsfpQHvc
dIrivDKMAlxbOT8nUEZ8bAd6AaN5i9E8+450XmfN307Q1sRj1X5JdhtZTqITs1w1
/RBgwvM8XaQLn0wd8QtwVaEkyd5gu/ui0yPzwJ2WEb5zz5VbbHacm6pDR8avTXQW
zdR9OHUlD+Zgvah64iAW
=INrS
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200530/7d459095/attachment-0001.html>

From numpy_gsod at bigriver.xyz  Sun May 31 10:18:35 2020
From: numpy_gsod at bigriver.xyz (Ben Nathanson)
Date: Sun, 31 May 2020 10:18:35 -0400
Subject: [Numpy-discussion] Numpy Documentation: How-to content
In-Reply-To: <BL0PR05MB528269459BA7886D3839C434BA8F0@BL0PR05MB5282.namprd05.prod.outlook.com>
References: <BL0PR05MB528269459BA7886D3839C434BA8F0@BL0PR05MB5282.namprd05.prod.outlook.com>
Message-ID: <CAA7-tfh0hs_dgx7jnbSiTn67DtHLVJo8oWcwoAGosM7sHLPq+g@mail.gmail.com>

This sounds fantastic.

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?

What were your thoughts on submission workflow? You review initially,
then the student directly submits a PR?

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?

Were you planning to keep the mechanical engineering context for these
problems, or present abstractly?  (I myself would like to see the
application left intact. It doesn't obscure the steps, and I love the
brothers-and-sisters-under-the-skin glimpse of how other domains make
use of the same tools I do.)

> easier to organize and...write

I agree. Pedagogical soundness is also a plus. Procida says "what you
ask the beginner to do [in a tutorial] must work"
(https://documentation.divio.com/tutorials/). That means, among other
things, that we need to specify a single environment to run the
tutorial in. Notebook is the all-around win for this.

From charlesr.harris at gmail.com  Sun May 31 19:50:17 2020
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 31 May 2020 17:50:17 -0600
Subject: [Numpy-discussion] (no subject)
Message-ID: <CAB6mnxK_k7abg8DP9i-vkZ1FirgtcosOYpm5UweB-Jb8M4v6LA@mail.gmail.com>

Hi All,

On behalf of the NumPy team I am pleased to announce that
NumPy 1.19.0rc2 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
<https://pypi.org/project/numpy/1.19.0rc2/>, source archives and release
notes are available from Github
<https://github.com/numpy/numpy/releases/tag/v1.19.0rc2>.

*Contributors*

A total of 124 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
   - 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 +
   - 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: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200531/069939e0/attachment.html>