From deathcoderx at gmail.com  Tue Apr  2 02:20:49 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Tue, 2 Apr 2019 11:50:49 +0530
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CADYNDzgcYEQ4Wy9Yd2J+MCPE+q+k1bjYTR=X31qNd=MwmDC8ag@mail.gmail.com>
References: <CADYNDzi=VUB3GXJ7-KZYL9FU=md0CuXf6x0Tc_JEQ4OebTuf+Q@mail.gmail.com>
 <CAJR3sXcnSHv3Fxp=XOcq2jZLNU03A56Tn_bEp5o6V1V7AFcr-Q@mail.gmail.com>
 <CADYNDzi5CdieoA3hdfyd0ZTU+fePMctBFzkRPHUxxaNeK0X5Fg@mail.gmail.com>
 <CAJR3sXe+Cf45QaV+V=ciozo8+0M4YNkjCy-7SxCGbYct3nZKsQ@mail.gmail.com>
 <CADYNDzg8SEEuG_QTxt57TXsi4s3j-Pe_0X1ovrPSOoGxN+UVYw@mail.gmail.com>
 <CAGu2niWoLJ5u-Ux=jb3HFBBfN18L6fsdMcwb4OLH36044PEJ0g@mail.gmail.com>
 <CADYNDzi1xQokrvVPkPhS2smJYRrm96fu_TB=DTYZb=hXJheUZg@mail.gmail.com>
 <CAGu2niXhVZQPBe23a_ftypwp3oqq2ui14P9TnVc9MEXD5mu1SA@mail.gmail.com>
 <CADYNDzh=M2yTnEE0C2HNuCDARXJhHhbHC8UkYnXUgeTA8fdx=Q@mail.gmail.com>
 <CAGu2niUmN=3w=4TAsp0Nc4QN5z5D2p9XA6Ji_6JRAw1MvG1Pmw@mail.gmail.com>
 <CADYNDzh5td0x4sK50VvFw6YQD+Nhc=+hqrYTai4kfYv+F4ttpQ@mail.gmail.com>
 <CAGu2niU3NRhWyCpuMw8WMjfC0sLgq7=PtO8PZJDrsYLSR8V81w@mail.gmail.com>
 <CADYNDzipyXrOeDxbx+ngL0G06LdYpAq32qk2jEO+75=JUREedw@mail.gmail.com>
 <CAJR3sXdcPMAn_DETF8W-=MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw@mail.gmail.com>
 <CADYNDzgcYEQ4Wy9Yd2J+MCPE+q+k1bjYTR=X31qNd=MwmDC8ag@mail.gmail.com>
Message-ID: <CADYNDzjK4c+V6cnNMZW6vZkfhj=X50+DawpVFhBvTntt5-5hEg@mail.gmail.com>

Hey,
Greg, I went through the ideas you have mentioned and also looked up the
matplotlib docs as suggested.  And I feel like creating a new namespace
would be a better option as it won't require many changes in the current
implementation. As matplotlib.pyplot is a well-implemented module  I feel
like we can consider it as our basic structure and start implementing the
backend.

For the start, I think import can look like this(rough idea)
import scipy.fftpack.pyfftw as fft
where pyffw can be replaced by any third party fftpack.

Cheers.
-Gopi


On Sun, Mar 31, 2019 at 2:00 AM Gopi Manohar Tatiraju <deathcoderx at gmail.com>
wrote:

> Hey,
> I feel like I need to make some more changes regarding the idea. I went
> through your reply to Anany and I will consider all those points and will
> get back to you once I come up with something.
>
> -Gopi.
>
> On Sun, Mar 31, 2019 at 5:24 AM Gregory Lee <grlee77 at gmail.com> wrote:
>
>> Hi Gopi,
>>
>> I am not sure I follow exactly what you are suggesting here. Are you
>> proposing that the `fftpackN` variable in your example would be a Python
>> module corresponding to a given backend? If so, why is an array of data, z,
>> being passed into the newAPI function here? I don't see why a data array
>> should be needed at all to choose a backend.
>>
>> Please also see my response to Anany's recent post on this list for a
>> couple of other suggestions of things to consider in terms of the API.
>>
>> - Greg
>>
>>
>> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
>> deathcoderx at gmail.com> wrote:
>>
>>> Hey,
>>> I went through the code and got some ideas.
>>> So what will happen is:
>>> First, we will declare FFTW as we use them normally.
>>>
>>> z = np.random.rand(2, 128, 64)
>>> pyfftw.FFTW(z, axes=(-1, ))
>>> ..
>>> ..
>>> Now after declaring our basic work to shift to another FFTpack, what we
>>> can do is:
>>> fftPackN= newAPI(z, pack = 'PYFFTW');
>>>
>>> Pack will take the name of the 3rd party FFT pack which we want to use.
>>> Suggestions needed.
>>>
>>> Cheers.
>>>
>>>
>>
>>>
>>> On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <larson.eric.d at gmail.com>
>>> wrote:
>>>
>>>> After reading the related issues and thinking about the problem,
>>>> perhaps the best first step is you come up with some initial API proposal.
>>>>
>>>> One way to work through the process is to think about the use cases
>>>> that we want to support. How should users actually write code to use the
>>>> new functionality? You can start with short code snippets that do not work
>>>> currently, but should work for users at the end of the project. Then think
>>>> about what needs to change inside SciPy for these code snippets to work.
>>>> This can become an iterative process as you realize that the SciPy changes
>>>> might be better or easier with changes to the user-facing API, etc.
>>>>
>>>> Eric
>>>>
>>>>
>>>> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
>>>> deathcoderx at gmail.com> wrote:
>>>>
>>>>> Hey,
>>>>> As proposal submission period started I want to discuss a bit anobt
>>>>> how can we implement the API.
>>>>> I would very much appriciate inputs and guidance.
>>>>>
>>>>> Cheers.
>>>>>
>>>>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <larson.eric.d at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> The best way to figure that out is probably to take a look at some of
>>>>>> the existing (minor) SciPy GitHub issues and try to work on one or two that
>>>>>> you feel like working on. Actually trying to work out how to contribute
>>>>>> code changes (as independently as possible/reasonable based on the existing
>>>>>> guides/docs already discoverable online) will quickly highlight things that
>>>>>> need to be learned. Some of the general things are the SciPy contributing
>>>>>> guidelines, standard GitHub PR workflow, communication with reviewers, and
>>>>>> so forth.
>>>>>>
>>>>>> For this particular project, it's important to understand the various
>>>>>> flavors and properties of FFT in SciPy (real, complex, n-dimensional,
>>>>>> caching plans, etc.) as well as other projects like NumPy, CuPy, and
>>>>>> pyFFTW. Some of this can be learned and improved upon as part of GSoC, but
>>>>>> the more you know and can demonstrate / put into practice knowledge of
>>>>>> before the applications are reviewed, the better.
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>
>>>>>>> Thank you for the detailed reply.
>>>>>>> I will keep these point in mind while preparing my proposal. Apart
>>>>>>> from proposal, what skills shall I improve so that I can contribute more
>>>>>>> effectively and efficiently.
>>>>>>>
>>>>>>> Cheers.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <larson.eric.d at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> There are a number of considerations that would be good to address.
>>>>>>>> I'd start by considering the things that are typically considered
>>>>>>>> when making changes to SciPy
>>>>>>>> <https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy>,
>>>>>>>> but I'd expand it to a longer list since the scope is bigger than a typical
>>>>>>>> single PR. The list would contain (at least):
>>>>>>>>
>>>>>>>> - what will the user-facing API / contract be?
>>>>>>>> - what in SciPy needs to change to allow it (internals /
>>>>>>>> implementation outline, perhaps skeleton functions/classes)?
>>>>>>>> - what examples should we show users (in general this ends up being
>>>>>>>> just simple use cases of the API)?
>>>>>>>> - how will we test it for correctness?
>>>>>>>> - how will we benchmark it to prevent performance regressions?
>>>>>>>> - how can we break up the work for these steps (if possible) into
>>>>>>>> separable, sequential (or -- better but not usually possible --
>>>>>>>> independent) PRs?
>>>>>>>>
>>>>>>>> You might notice that none of these points are actually all that
>>>>>>>> specific to the FFT project, but can be generally applicable to GSoC
>>>>>>>> projects. For the FFT project, I would say "how do we build the backend" is
>>>>>>>> indeed implicitly contained / outlined in these bullet points. And as with
>>>>>>>> most projects, the first two points (and possibly the last) will probably
>>>>>>>> be the most challenging to sort out.
>>>>>>>>
>>>>>>>> Eric
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hey Eric,
>>>>>>>>> So for my proposal, shall I include how can we built a back end?
>>>>>>>>> What all points shall I include to make it effective?
>>>>>>>>>
>>>>>>>>> Cheers.
>>>>>>>>>
>>>>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <larson.eric.d at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> That would be me -- don't worry, I'm on this list, as are
>>>>>>>>>> (presumably) other developers interested in the discussion, so no need to
>>>>>>>>>> document elsewhere for now from our end. It looks like Greg has summarized
>>>>>>>>>> the current status and thoughts we've had, so I don't have much to add at
>>>>>>>>>> this point.
>>>>>>>>>>
>>>>>>>>>> Eric
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey Greg,
>>>>>>>>>>> I got the basic idea about what we want to implement this year.
>>>>>>>>>>> Our first priority is to create a backend for 3rd party
>>>>>>>>>>> fftpacks. We can create API using Python and Flask or any other suitable
>>>>>>>>>>> framework.
>>>>>>>>>>>
>>>>>>>>>>> I thought this discussion was going on on SciPy Developer List
>>>>>>>>>>> only. So do I need to document it all and post it somewhere so that other
>>>>>>>>>>> contributors can see this?
>>>>>>>>>>> Also, I couldn't find any contact info regarding Eric. It would
>>>>>>>>>>> be very helpful if we include him in this discussion as this is a roadmap
>>>>>>>>>>> for GSoC project and I can also get more insight into the project and
>>>>>>>>>>> expected outcomes.
>>>>>>>>>>>
>>>>>>>>>>> Cheers.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <grlee77 at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey Gregory,
>>>>>>>>>>>>> I went through the idea and I am very much interested in
>>>>>>>>>>>>> working on it. I had Fourier Transforms as a part of my academic course, so
>>>>>>>>>>>>> I am well aware with basic concepts.
>>>>>>>>>>>>> One thing I want to discuss is, its mentioned that we have to
>>>>>>>>>>>>> create a backend system for 3rd party FFTpacks so my dobuts
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> 1. How are we going to create API?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This will needed to be decided on in consensus with the SciPy
>>>>>>>>>>>> developers and user community. I am mentoring for the project as a
>>>>>>>>>>>> contributor here and a maintainer of the related pyFFTW package, but I am
>>>>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core dev here). I have
>>>>>>>>>>>> not discussed the API in any detail with the SciPy team at this stage.
>>>>>>>>>>>> Working out details of what the API should look like and working to
>>>>>>>>>>>> finalize that in collaboration with the community will be a primary task
>>>>>>>>>>>> during the early part of the GSOC project.
>>>>>>>>>>>>
>>>>>>>>>>>> 2. After the creation of backend will user at the time of
>>>>>>>>>>>>> installation of SciPy will decide what all 3rd party FFTpacks he needs or
>>>>>>>>>>>>> we will include some by default?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The idea is to allow users to opt-in to a different FFT
>>>>>>>>>>>> backend at run time, but these alternative libraries will not be
>>>>>>>>>>>> distributed with SciPy itself due to incompatible software licenses (pyFFTW
>>>>>>>>>>>> and mkl-fft) or a requirement for specific hardware (CuPy requires an
>>>>>>>>>>>> NVIDIA GPU). SciPy will continue to offer its own bundled FFT library
>>>>>>>>>>>> (currently fftpack, but this could be switched to pocketfft as discussed in
>>>>>>>>>>>> the ideas page). The purpose of the backend interface is to provide a
>>>>>>>>>>>> convenient way for users to have third party libraries perform the FFTs
>>>>>>>>>>>> instead, but under the existing scipy.fftpack API. This is motivated by a
>>>>>>>>>>>> desire by end users and downstream projects to have features such as
>>>>>>>>>>>> multi-threading (pyFFTW and mkl-fft) or GPU support (CuPy) that are not
>>>>>>>>>>>> implemented in scipy.fftpack. Ultimately it will be up to users that opt-in
>>>>>>>>>>>> to using these other libraries to confirm that the license terms and are
>>>>>>>>>>>> compatible with their use case.
>>>>>>>>>>>>
>>>>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev mailing
>>>>>>>>>>>> lists prefers replies **below** the email you are replying to so people can
>>>>>>>>>>>> more easily follow the thread of discussion. There are some guidelines at:
>>>>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I will research more about how to implement a backend myself
>>>>>>>>>>>>> and will let you know as soon as I come up with something new.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> CHeers,
>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <grlee77 at gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
>>>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started fixing some
>>>>>>>>>>>>>>> bugs, also made some pull request. Can anyone suggest me how should I
>>>>>>>>>>>>>>> proceed further?
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Gopi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think you have probably already found it, but the GSOC
>>>>>>>>>>>>>> project we have already identified mentors for in SciPy is here:
>>>>>>>>>>>>>> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If this is a project you are interested in then I would start
>>>>>>>>>>>>>> thinking about what the FFT interface would look like and reviewing some of
>>>>>>>>>>>>>> the past/present issues related to fftpack / FFT in SciPy. Please ask
>>>>>>>>>>>>>> questions you have related to that project here so that you can clarify
>>>>>>>>>>>>>> what would be involved in writing a successful application.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you have a different idea in mind you can propose it here,
>>>>>>>>>>>>>> but you should do that soon, because it will be necessary to determine if
>>>>>>>>>>>>>> there is interest from the SciPy team before you spend time coming up with
>>>>>>>>>>>>>> a detailed proposal. We have to determine if a project sounds feasible to
>>>>>>>>>>>>>> complete for GSOC and if appropriate mentors can be identified.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ultimately, you will need to submit an application to SciPy
>>>>>>>>>>>>>> between March 25th - April 9th.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190402/5936de07/attachment-0001.html>

From ralf.gommers at gmail.com  Tue Apr  2 02:47:11 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 2 Apr 2019 08:47:11 +0200
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CADYNDzjK4c+V6cnNMZW6vZkfhj=X50+DawpVFhBvTntt5-5hEg@mail.gmail.com>
References: <CADYNDzi=VUB3GXJ7-KZYL9FU=md0CuXf6x0Tc_JEQ4OebTuf+Q@mail.gmail.com>
 <CAJR3sXcnSHv3Fxp=XOcq2jZLNU03A56Tn_bEp5o6V1V7AFcr-Q@mail.gmail.com>
 <CADYNDzi5CdieoA3hdfyd0ZTU+fePMctBFzkRPHUxxaNeK0X5Fg@mail.gmail.com>
 <CAJR3sXe+Cf45QaV+V=ciozo8+0M4YNkjCy-7SxCGbYct3nZKsQ@mail.gmail.com>
 <CADYNDzg8SEEuG_QTxt57TXsi4s3j-Pe_0X1ovrPSOoGxN+UVYw@mail.gmail.com>
 <CAGu2niWoLJ5u-Ux=jb3HFBBfN18L6fsdMcwb4OLH36044PEJ0g@mail.gmail.com>
 <CADYNDzi1xQokrvVPkPhS2smJYRrm96fu_TB=DTYZb=hXJheUZg@mail.gmail.com>
 <CAGu2niXhVZQPBe23a_ftypwp3oqq2ui14P9TnVc9MEXD5mu1SA@mail.gmail.com>
 <CADYNDzh=M2yTnEE0C2HNuCDARXJhHhbHC8UkYnXUgeTA8fdx=Q@mail.gmail.com>
 <CAGu2niUmN=3w=4TAsp0Nc4QN5z5D2p9XA6Ji_6JRAw1MvG1Pmw@mail.gmail.com>
 <CADYNDzh5td0x4sK50VvFw6YQD+Nhc=+hqrYTai4kfYv+F4ttpQ@mail.gmail.com>
 <CAGu2niU3NRhWyCpuMw8WMjfC0sLgq7=PtO8PZJDrsYLSR8V81w@mail.gmail.com>
 <CADYNDzipyXrOeDxbx+ngL0G06LdYpAq32qk2jEO+75=JUREedw@mail.gmail.com>
 <CAJR3sXdcPMAn_DETF8W-=MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw@mail.gmail.com>
 <CADYNDzgcYEQ4Wy9Yd2J+MCPE+q+k1bjYTR=X31qNd=MwmDC8ag@mail.gmail.com>
 <CADYNDzjK4c+V6cnNMZW6vZkfhj=X50+DawpVFhBvTntt5-5hEg@mail.gmail.com>
Message-ID: <CABL7CQhoCz576DQApAgX-qG3Qp=hsmctOgk=7KEDTKuXN4jgeg@mail.gmail.com>

On Tue, Apr 2, 2019 at 8:17 AM Gopi Manohar Tatiraju <deathcoderx at gmail.com>
wrote:

> Hey,
> Greg, I went through the ideas you have mentioned and also looked up the
> matplotlib docs as suggested.  And I feel like creating a new namespace
> would be a better option as it won't require many changes in the current
> implementation. As matplotlib.pyplot is a well-implemented module  I feel
> like we can consider it as our basic structure and start implementing the
> backend.
>

A new namespace is not a good idea. There's no reason that things can't
work for the current namespace.


> For the start, I think import can look like this(rough idea)
> import scipy.fftpack.pyfftw as fft
> where pyffw can be replaced by any third party fftpack.
>

We don't want a PyFFTW namespace or direct support for PyFFTW (note that we
removed such support years ago due to license reasons). Instead, we want to
allow third parties to implement a backend; for FFTW this will live in
https://github.com/pyFFTW/pyFFTW

Cheers,
Ralf



> Cheers.
> -Gopi
>
>
> On Sun, Mar 31, 2019 at 2:00 AM Gopi Manohar Tatiraju <
> deathcoderx at gmail.com> wrote:
>
>> Hey,
>> I feel like I need to make some more changes regarding the idea. I went
>> through your reply to Anany and I will consider all those points and will
>> get back to you once I come up with something.
>>
>> -Gopi.
>>
>> On Sun, Mar 31, 2019 at 5:24 AM Gregory Lee <grlee77 at gmail.com> wrote:
>>
>>> Hi Gopi,
>>>
>>> I am not sure I follow exactly what you are suggesting here. Are you
>>> proposing that the `fftpackN` variable in your example would be a Python
>>> module corresponding to a given backend? If so, why is an array of data, z,
>>> being passed into the newAPI function here? I don't see why a data array
>>> should be needed at all to choose a backend.
>>>
>>> Please also see my response to Anany's recent post on this list for a
>>> couple of other suggestions of things to consider in terms of the API.
>>>
>>> - Greg
>>>
>>>
>>> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
>>> deathcoderx at gmail.com> wrote:
>>>
>>>> Hey,
>>>> I went through the code and got some ideas.
>>>> So what will happen is:
>>>> First, we will declare FFTW as we use them normally.
>>>>
>>>> z = np.random.rand(2, 128, 64)
>>>> pyfftw.FFTW(z, axes=(-1, ))
>>>> ..
>>>> ..
>>>> Now after declaring our basic work to shift to another FFTpack, what we
>>>> can do is:
>>>> fftPackN= newAPI(z, pack = 'PYFFTW');
>>>>
>>>> Pack will take the name of the 3rd party FFT pack which we want to use.
>>>> Suggestions needed.
>>>>
>>>> Cheers.
>>>>
>>>>
>>>
>>>>
>>>> On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <larson.eric.d at gmail.com>
>>>> wrote:
>>>>
>>>>> After reading the related issues and thinking about the problem,
>>>>> perhaps the best first step is you come up with some initial API proposal.
>>>>>
>>>>> One way to work through the process is to think about the use cases
>>>>> that we want to support. How should users actually write code to use the
>>>>> new functionality? You can start with short code snippets that do not work
>>>>> currently, but should work for users at the end of the project. Then think
>>>>> about what needs to change inside SciPy for these code snippets to work.
>>>>> This can become an iterative process as you realize that the SciPy changes
>>>>> might be better or easier with changes to the user-facing API, etc.
>>>>>
>>>>> Eric
>>>>>
>>>>>
>>>>> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
>>>>> deathcoderx at gmail.com> wrote:
>>>>>
>>>>>> Hey,
>>>>>> As proposal submission period started I want to discuss a bit anobt
>>>>>> how can we implement the API.
>>>>>> I would very much appriciate inputs and guidance.
>>>>>>
>>>>>> Cheers.
>>>>>>
>>>>>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <larson.eric.d at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> The best way to figure that out is probably to take a look at some
>>>>>>> of the existing (minor) SciPy GitHub issues and try to work on one or two
>>>>>>> that you feel like working on. Actually trying to work out how to
>>>>>>> contribute code changes (as independently as possible/reasonable based on
>>>>>>> the existing guides/docs already discoverable online) will quickly
>>>>>>> highlight things that need to be learned. Some of the general things are
>>>>>>> the SciPy contributing guidelines, standard GitHub PR workflow,
>>>>>>> communication with reviewers, and so forth.
>>>>>>>
>>>>>>> For this particular project, it's important to understand the
>>>>>>> various flavors and properties of FFT in SciPy (real, complex,
>>>>>>> n-dimensional, caching plans, etc.) as well as other projects like NumPy,
>>>>>>> CuPy, and pyFFTW. Some of this can be learned and improved upon as part of
>>>>>>> GSoC, but the more you know and can demonstrate / put into practice
>>>>>>> knowledge of before the applications are reviewed, the better.
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>
>>>>>>>> Thank you for the detailed reply.
>>>>>>>> I will keep these point in mind while preparing my proposal. Apart
>>>>>>>> from proposal, what skills shall I improve so that I can contribute more
>>>>>>>> effectively and efficiently.
>>>>>>>>
>>>>>>>> Cheers.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <larson.eric.d at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> There are a number of considerations that would be good to
>>>>>>>>> address. I'd start by considering the things that are typically considered
>>>>>>>>> when making changes to SciPy
>>>>>>>>> <https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy>,
>>>>>>>>> but I'd expand it to a longer list since the scope is bigger than a typical
>>>>>>>>> single PR. The list would contain (at least):
>>>>>>>>>
>>>>>>>>> - what will the user-facing API / contract be?
>>>>>>>>> - what in SciPy needs to change to allow it (internals /
>>>>>>>>> implementation outline, perhaps skeleton functions/classes)?
>>>>>>>>> - what examples should we show users (in general this ends up
>>>>>>>>> being just simple use cases of the API)?
>>>>>>>>> - how will we test it for correctness?
>>>>>>>>> - how will we benchmark it to prevent performance regressions?
>>>>>>>>> - how can we break up the work for these steps (if possible) into
>>>>>>>>> separable, sequential (or -- better but not usually possible --
>>>>>>>>> independent) PRs?
>>>>>>>>>
>>>>>>>>> You might notice that none of these points are actually all that
>>>>>>>>> specific to the FFT project, but can be generally applicable to GSoC
>>>>>>>>> projects. For the FFT project, I would say "how do we build the backend" is
>>>>>>>>> indeed implicitly contained / outlined in these bullet points. And as with
>>>>>>>>> most projects, the first two points (and possibly the last) will probably
>>>>>>>>> be the most challenging to sort out.
>>>>>>>>>
>>>>>>>>> Eric
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hey Eric,
>>>>>>>>>> So for my proposal, shall I include how can we built a back end?
>>>>>>>>>> What all points shall I include to make it effective?
>>>>>>>>>>
>>>>>>>>>> Cheers.
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <larson.eric.d at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> That would be me -- don't worry, I'm on this list, as are
>>>>>>>>>>> (presumably) other developers interested in the discussion, so no need to
>>>>>>>>>>> document elsewhere for now from our end. It looks like Greg has summarized
>>>>>>>>>>> the current status and thoughts we've had, so I don't have much to add at
>>>>>>>>>>> this point.
>>>>>>>>>>>
>>>>>>>>>>> Eric
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hey Greg,
>>>>>>>>>>>> I got the basic idea about what we want to implement this year.
>>>>>>>>>>>> Our first priority is to create a backend for 3rd party
>>>>>>>>>>>> fftpacks. We can create API using Python and Flask or any other suitable
>>>>>>>>>>>> framework.
>>>>>>>>>>>>
>>>>>>>>>>>> I thought this discussion was going on on SciPy Developer List
>>>>>>>>>>>> only. So do I need to document it all and post it somewhere so that other
>>>>>>>>>>>> contributors can see this?
>>>>>>>>>>>> Also, I couldn't find any contact info regarding Eric. It would
>>>>>>>>>>>> be very helpful if we include him in this discussion as this is a roadmap
>>>>>>>>>>>> for GSoC project and I can also get more insight into the project and
>>>>>>>>>>>> expected outcomes.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <grlee77 at gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
>>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hey Gregory,
>>>>>>>>>>>>>> I went through the idea and I am very much interested in
>>>>>>>>>>>>>> working on it. I had Fourier Transforms as a part of my academic course, so
>>>>>>>>>>>>>> I am well aware with basic concepts.
>>>>>>>>>>>>>> One thing I want to discuss is, its mentioned that we have to
>>>>>>>>>>>>>> create a backend system for 3rd party FFTpacks so my dobuts
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. How are we going to create API?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This will needed to be decided on in consensus with the SciPy
>>>>>>>>>>>>> developers and user community. I am mentoring for the project as a
>>>>>>>>>>>>> contributor here and a maintainer of the related pyFFTW package, but I am
>>>>>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core dev here). I have
>>>>>>>>>>>>> not discussed the API in any detail with the SciPy team at this stage.
>>>>>>>>>>>>> Working out details of what the API should look like and working to
>>>>>>>>>>>>> finalize that in collaboration with the community will be a primary task
>>>>>>>>>>>>> during the early part of the GSOC project.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2. After the creation of backend will user at the time of
>>>>>>>>>>>>>> installation of SciPy will decide what all 3rd party FFTpacks he needs or
>>>>>>>>>>>>>> we will include some by default?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The idea is to allow users to opt-in to a different FFT
>>>>>>>>>>>>> backend at run time, but these alternative libraries will not be
>>>>>>>>>>>>> distributed with SciPy itself due to incompatible software licenses (pyFFTW
>>>>>>>>>>>>> and mkl-fft) or a requirement for specific hardware (CuPy requires an
>>>>>>>>>>>>> NVIDIA GPU). SciPy will continue to offer its own bundled FFT library
>>>>>>>>>>>>> (currently fftpack, but this could be switched to pocketfft as discussed in
>>>>>>>>>>>>> the ideas page). The purpose of the backend interface is to provide a
>>>>>>>>>>>>> convenient way for users to have third party libraries perform the FFTs
>>>>>>>>>>>>> instead, but under the existing scipy.fftpack API. This is motivated by a
>>>>>>>>>>>>> desire by end users and downstream projects to have features such as
>>>>>>>>>>>>> multi-threading (pyFFTW and mkl-fft) or GPU support (CuPy) that are not
>>>>>>>>>>>>> implemented in scipy.fftpack. Ultimately it will be up to users that opt-in
>>>>>>>>>>>>> to using these other libraries to confirm that the license terms and are
>>>>>>>>>>>>> compatible with their use case.
>>>>>>>>>>>>>
>>>>>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev mailing
>>>>>>>>>>>>> lists prefers replies **below** the email you are replying to so people can
>>>>>>>>>>>>> more easily follow the thread of discussion. There are some guidelines at:
>>>>>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will research more about how to implement a backend myself
>>>>>>>>>>>>>> and will let you know as soon as I come up with something new.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> CHeers,
>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <
>>>>>>>>>>>>>> grlee77 at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
>>>>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started fixing some
>>>>>>>>>>>>>>>> bugs, also made some pull request. Can anyone suggest me how should I
>>>>>>>>>>>>>>>> proceed further?
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Gopi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think you have probably already found it, but the GSOC
>>>>>>>>>>>>>>> project we have already identified mentors for in SciPy is here:
>>>>>>>>>>>>>>> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If this is a project you are interested in then I would
>>>>>>>>>>>>>>> start thinking about what the FFT interface would look like and reviewing
>>>>>>>>>>>>>>> some of the past/present issues related to fftpack / FFT in SciPy. Please
>>>>>>>>>>>>>>> ask questions you have related to that project here so that you can clarify
>>>>>>>>>>>>>>> what would be involved in writing a successful application.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you have a different idea in mind you can propose it
>>>>>>>>>>>>>>> here, but you should do that soon, because it will be necessary to
>>>>>>>>>>>>>>> determine if there is interest from the SciPy team before you spend time
>>>>>>>>>>>>>>> coming up with a detailed proposal. We have to determine if a project
>>>>>>>>>>>>>>> sounds feasible to complete for GSOC and if appropriate mentors can be
>>>>>>>>>>>>>>> identified.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ultimately, you will need to submit an application to SciPy
>>>>>>>>>>>>>>> between March 25th - April 9th.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190402/1bdbe585/attachment-0001.html>

From deathcoderx at gmail.com  Tue Apr  2 03:03:13 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Tue, 2 Apr 2019 12:33:13 +0530
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CABL7CQhoCz576DQApAgX-qG3Qp=hsmctOgk=7KEDTKuXN4jgeg@mail.gmail.com>
References: <CADYNDzi=VUB3GXJ7-KZYL9FU=md0CuXf6x0Tc_JEQ4OebTuf+Q@mail.gmail.com>
 <CAJR3sXcnSHv3Fxp=XOcq2jZLNU03A56Tn_bEp5o6V1V7AFcr-Q@mail.gmail.com>
 <CADYNDzi5CdieoA3hdfyd0ZTU+fePMctBFzkRPHUxxaNeK0X5Fg@mail.gmail.com>
 <CAJR3sXe+Cf45QaV+V=ciozo8+0M4YNkjCy-7SxCGbYct3nZKsQ@mail.gmail.com>
 <CADYNDzg8SEEuG_QTxt57TXsi4s3j-Pe_0X1ovrPSOoGxN+UVYw@mail.gmail.com>
 <CAGu2niWoLJ5u-Ux=jb3HFBBfN18L6fsdMcwb4OLH36044PEJ0g@mail.gmail.com>
 <CADYNDzi1xQokrvVPkPhS2smJYRrm96fu_TB=DTYZb=hXJheUZg@mail.gmail.com>
 <CAGu2niXhVZQPBe23a_ftypwp3oqq2ui14P9TnVc9MEXD5mu1SA@mail.gmail.com>
 <CADYNDzh=M2yTnEE0C2HNuCDARXJhHhbHC8UkYnXUgeTA8fdx=Q@mail.gmail.com>
 <CAGu2niUmN=3w=4TAsp0Nc4QN5z5D2p9XA6Ji_6JRAw1MvG1Pmw@mail.gmail.com>
 <CADYNDzh5td0x4sK50VvFw6YQD+Nhc=+hqrYTai4kfYv+F4ttpQ@mail.gmail.com>
 <CAGu2niU3NRhWyCpuMw8WMjfC0sLgq7=PtO8PZJDrsYLSR8V81w@mail.gmail.com>
 <CADYNDzipyXrOeDxbx+ngL0G06LdYpAq32qk2jEO+75=JUREedw@mail.gmail.com>
 <CAJR3sXdcPMAn_DETF8W-=MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw@mail.gmail.com>
 <CADYNDzgcYEQ4Wy9Yd2J+MCPE+q+k1bjYTR=X31qNd=MwmDC8ag@mail.gmail.com>
 <CADYNDzjK4c+V6cnNMZW6vZkfhj=X50+DawpVFhBvTntt5-5hEg@mail.gmail.com>
 <CABL7CQhoCz576DQApAgX-qG3Qp=hsmctOgk=7KEDTKuXN4jgeg@mail.gmail.com>
Message-ID: <CADYNDziEzeWDgCxZUK55u2tFU1jfnr1pPU_KB8c0_6pr73+PLA@mail.gmail.com>

Hey,
Are you suggesting that we need to make changes in PYFFTW?
If so, then for every third party FFTPACK we need to make changes in that
specific pack, right?

Cheers,
Gopi

On Tue, Apr 2, 2019 at 12:18 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Tue, Apr 2, 2019 at 8:17 AM Gopi Manohar Tatiraju <
> deathcoderx at gmail.com> wrote:
>
>> Hey,
>> Greg, I went through the ideas you have mentioned and also looked up the
>> matplotlib docs as suggested.  And I feel like creating a new namespace
>> would be a better option as it won't require many changes in the current
>> implementation. As matplotlib.pyplot is a well-implemented module  I feel
>> like we can consider it as our basic structure and start implementing the
>> backend.
>>
>
> A new namespace is not a good idea. There's no reason that things can't
> work for the current namespace.
>
>
>> For the start, I think import can look like this(rough idea)
>> import scipy.fftpack.pyfftw as fft
>> where pyffw can be replaced by any third party fftpack.
>>
>
> We don't want a PyFFTW namespace or direct support for PyFFTW (note that
> we removed such support years ago due to license reasons). Instead, we want
> to allow third parties to implement a backend; for FFTW this will live in
> https://github.com/pyFFTW/pyFFTW
>
> Cheers,
> Ralf
>
>
>
>> Cheers.
>> -Gopi
>>
>>
>> On Sun, Mar 31, 2019 at 2:00 AM Gopi Manohar Tatiraju <
>> deathcoderx at gmail.com> wrote:
>>
>>> Hey,
>>> I feel like I need to make some more changes regarding the idea. I went
>>> through your reply to Anany and I will consider all those points and will
>>> get back to you once I come up with something.
>>>
>>> -Gopi.
>>>
>>> On Sun, Mar 31, 2019 at 5:24 AM Gregory Lee <grlee77 at gmail.com> wrote:
>>>
>>>> Hi Gopi,
>>>>
>>>> I am not sure I follow exactly what you are suggesting here. Are you
>>>> proposing that the `fftpackN` variable in your example would be a Python
>>>> module corresponding to a given backend? If so, why is an array of data, z,
>>>> being passed into the newAPI function here? I don't see why a data array
>>>> should be needed at all to choose a backend.
>>>>
>>>> Please also see my response to Anany's recent post on this list for a
>>>> couple of other suggestions of things to consider in terms of the API.
>>>>
>>>> - Greg
>>>>
>>>>
>>>> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
>>>> deathcoderx at gmail.com> wrote:
>>>>
>>>>> Hey,
>>>>> I went through the code and got some ideas.
>>>>> So what will happen is:
>>>>> First, we will declare FFTW as we use them normally.
>>>>>
>>>>> z = np.random.rand(2, 128, 64)
>>>>> pyfftw.FFTW(z, axes=(-1, ))
>>>>> ..
>>>>> ..
>>>>> Now after declaring our basic work to shift to another FFTpack, what
>>>>> we can do is:
>>>>> fftPackN= newAPI(z, pack = 'PYFFTW');
>>>>>
>>>>> Pack will take the name of the 3rd party FFT pack which we want to use.
>>>>> Suggestions needed.
>>>>>
>>>>> Cheers.
>>>>>
>>>>>
>>>>
>>>>>
>>>>> On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <larson.eric.d at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> After reading the related issues and thinking about the problem,
>>>>>> perhaps the best first step is you come up with some initial API proposal.
>>>>>>
>>>>>> One way to work through the process is to think about the use cases
>>>>>> that we want to support. How should users actually write code to use the
>>>>>> new functionality? You can start with short code snippets that do not work
>>>>>> currently, but should work for users at the end of the project. Then think
>>>>>> about what needs to change inside SciPy for these code snippets to work.
>>>>>> This can become an iterative process as you realize that the SciPy changes
>>>>>> might be better or easier with changes to the user-facing API, etc.
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>>
>>>>>> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>
>>>>>>> Hey,
>>>>>>> As proposal submission period started I want to discuss a bit anobt
>>>>>>> how can we implement the API.
>>>>>>> I would very much appriciate inputs and guidance.
>>>>>>>
>>>>>>> Cheers.
>>>>>>>
>>>>>>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <larson.eric.d at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> The best way to figure that out is probably to take a look at some
>>>>>>>> of the existing (minor) SciPy GitHub issues and try to work on one or two
>>>>>>>> that you feel like working on. Actually trying to work out how to
>>>>>>>> contribute code changes (as independently as possible/reasonable based on
>>>>>>>> the existing guides/docs already discoverable online) will quickly
>>>>>>>> highlight things that need to be learned. Some of the general things are
>>>>>>>> the SciPy contributing guidelines, standard GitHub PR workflow,
>>>>>>>> communication with reviewers, and so forth.
>>>>>>>>
>>>>>>>> For this particular project, it's important to understand the
>>>>>>>> various flavors and properties of FFT in SciPy (real, complex,
>>>>>>>> n-dimensional, caching plans, etc.) as well as other projects like NumPy,
>>>>>>>> CuPy, and pyFFTW. Some of this can be learned and improved upon as part of
>>>>>>>> GSoC, but the more you know and can demonstrate / put into practice
>>>>>>>> knowledge of before the applications are reviewed, the better.
>>>>>>>>
>>>>>>>> Eric
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Thank you for the detailed reply.
>>>>>>>>> I will keep these point in mind while preparing my proposal. Apart
>>>>>>>>> from proposal, what skills shall I improve so that I can contribute more
>>>>>>>>> effectively and efficiently.
>>>>>>>>>
>>>>>>>>> Cheers.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <larson.eric.d at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> There are a number of considerations that would be good to
>>>>>>>>>> address. I'd start by considering the things that are typically considered
>>>>>>>>>> when making changes to SciPy
>>>>>>>>>> <https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy>,
>>>>>>>>>> but I'd expand it to a longer list since the scope is bigger than a typical
>>>>>>>>>> single PR. The list would contain (at least):
>>>>>>>>>>
>>>>>>>>>> - what will the user-facing API / contract be?
>>>>>>>>>> - what in SciPy needs to change to allow it (internals /
>>>>>>>>>> implementation outline, perhaps skeleton functions/classes)?
>>>>>>>>>> - what examples should we show users (in general this ends up
>>>>>>>>>> being just simple use cases of the API)?
>>>>>>>>>> - how will we test it for correctness?
>>>>>>>>>> - how will we benchmark it to prevent performance regressions?
>>>>>>>>>> - how can we break up the work for these steps (if possible) into
>>>>>>>>>> separable, sequential (or -- better but not usually possible --
>>>>>>>>>> independent) PRs?
>>>>>>>>>>
>>>>>>>>>> You might notice that none of these points are actually all that
>>>>>>>>>> specific to the FFT project, but can be generally applicable to GSoC
>>>>>>>>>> projects. For the FFT project, I would say "how do we build the backend" is
>>>>>>>>>> indeed implicitly contained / outlined in these bullet points. And as with
>>>>>>>>>> most projects, the first two points (and possibly the last) will probably
>>>>>>>>>> be the most challenging to sort out.
>>>>>>>>>>
>>>>>>>>>> Eric
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey Eric,
>>>>>>>>>>> So for my proposal, shall I include how can we built a back end?
>>>>>>>>>>> What all points shall I include to make it effective?
>>>>>>>>>>>
>>>>>>>>>>> Cheers.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <
>>>>>>>>>>> larson.eric.d at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> That would be me -- don't worry, I'm on this list, as are
>>>>>>>>>>>> (presumably) other developers interested in the discussion, so no need to
>>>>>>>>>>>> document elsewhere for now from our end. It looks like Greg has summarized
>>>>>>>>>>>> the current status and thoughts we've had, so I don't have much to add at
>>>>>>>>>>>> this point.
>>>>>>>>>>>>
>>>>>>>>>>>> Eric
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey Greg,
>>>>>>>>>>>>> I got the basic idea about what we want to implement this
>>>>>>>>>>>>> year.
>>>>>>>>>>>>> Our first priority is to create a backend for 3rd party
>>>>>>>>>>>>> fftpacks. We can create API using Python and Flask or any other suitable
>>>>>>>>>>>>> framework.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I thought this discussion was going on on SciPy Developer List
>>>>>>>>>>>>> only. So do I need to document it all and post it somewhere so that other
>>>>>>>>>>>>> contributors can see this?
>>>>>>>>>>>>> Also, I couldn't find any contact info regarding Eric. It
>>>>>>>>>>>>> would be very helpful if we include him in this discussion as this is a
>>>>>>>>>>>>> roadmap for GSoC project and I can also get more insight into the project
>>>>>>>>>>>>> and expected outcomes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <grlee77 at gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
>>>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hey Gregory,
>>>>>>>>>>>>>>> I went through the idea and I am very much interested in
>>>>>>>>>>>>>>> working on it. I had Fourier Transforms as a part of my academic course, so
>>>>>>>>>>>>>>> I am well aware with basic concepts.
>>>>>>>>>>>>>>> One thing I want to discuss is, its mentioned that we have
>>>>>>>>>>>>>>> to create a backend system for 3rd party FFTpacks so my dobuts
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. How are we going to create API?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This will needed to be decided on in consensus with the SciPy
>>>>>>>>>>>>>> developers and user community. I am mentoring for the project as a
>>>>>>>>>>>>>> contributor here and a maintainer of the related pyFFTW package, but I am
>>>>>>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core dev here). I have
>>>>>>>>>>>>>> not discussed the API in any detail with the SciPy team at this stage.
>>>>>>>>>>>>>> Working out details of what the API should look like and working to
>>>>>>>>>>>>>> finalize that in collaboration with the community will be a primary task
>>>>>>>>>>>>>> during the early part of the GSOC project.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. After the creation of backend will user at the time of
>>>>>>>>>>>>>>> installation of SciPy will decide what all 3rd party FFTpacks he needs or
>>>>>>>>>>>>>>> we will include some by default?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The idea is to allow users to opt-in to a different FFT
>>>>>>>>>>>>>> backend at run time, but these alternative libraries will not be
>>>>>>>>>>>>>> distributed with SciPy itself due to incompatible software licenses (pyFFTW
>>>>>>>>>>>>>> and mkl-fft) or a requirement for specific hardware (CuPy requires an
>>>>>>>>>>>>>> NVIDIA GPU). SciPy will continue to offer its own bundled FFT library
>>>>>>>>>>>>>> (currently fftpack, but this could be switched to pocketfft as discussed in
>>>>>>>>>>>>>> the ideas page). The purpose of the backend interface is to provide a
>>>>>>>>>>>>>> convenient way for users to have third party libraries perform the FFTs
>>>>>>>>>>>>>> instead, but under the existing scipy.fftpack API. This is motivated by a
>>>>>>>>>>>>>> desire by end users and downstream projects to have features such as
>>>>>>>>>>>>>> multi-threading (pyFFTW and mkl-fft) or GPU support (CuPy) that are not
>>>>>>>>>>>>>> implemented in scipy.fftpack. Ultimately it will be up to users that opt-in
>>>>>>>>>>>>>> to using these other libraries to confirm that the license terms and are
>>>>>>>>>>>>>> compatible with their use case.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev mailing
>>>>>>>>>>>>>> lists prefers replies **below** the email you are replying to so people can
>>>>>>>>>>>>>> more easily follow the thread of discussion. There are some guidelines at:
>>>>>>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will research more about how to implement a backend myself
>>>>>>>>>>>>>>> and will let you know as soon as I come up with something new.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> CHeers,
>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <
>>>>>>>>>>>>>>> grlee77 at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
>>>>>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started fixing
>>>>>>>>>>>>>>>>> some bugs, also made some pull request. Can anyone suggest me how should I
>>>>>>>>>>>>>>>>> proceed further?
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Gopi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think you have probably already found it, but the GSOC
>>>>>>>>>>>>>>>> project we have already identified mentors for in SciPy is here:
>>>>>>>>>>>>>>>> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If this is a project you are interested in then I would
>>>>>>>>>>>>>>>> start thinking about what the FFT interface would look like and reviewing
>>>>>>>>>>>>>>>> some of the past/present issues related to fftpack / FFT in SciPy. Please
>>>>>>>>>>>>>>>> ask questions you have related to that project here so that you can clarify
>>>>>>>>>>>>>>>> what would be involved in writing a successful application.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If you have a different idea in mind you can propose it
>>>>>>>>>>>>>>>> here, but you should do that soon, because it will be necessary to
>>>>>>>>>>>>>>>> determine if there is interest from the SciPy team before you spend time
>>>>>>>>>>>>>>>> coming up with a detailed proposal. We have to determine if a project
>>>>>>>>>>>>>>>> sounds feasible to complete for GSOC and if appropriate mentors can be
>>>>>>>>>>>>>>>> identified.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ultimately, you will need to submit an application to SciPy
>>>>>>>>>>>>>>>> between March 25th - April 9th.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190402/5eb3e16d/attachment-0001.html>

From ralf.gommers at gmail.com  Tue Apr  2 04:22:52 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 2 Apr 2019 10:22:52 +0200
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CADYNDziEzeWDgCxZUK55u2tFU1jfnr1pPU_KB8c0_6pr73+PLA@mail.gmail.com>
References: <CADYNDzi=VUB3GXJ7-KZYL9FU=md0CuXf6x0Tc_JEQ4OebTuf+Q@mail.gmail.com>
 <CAJR3sXcnSHv3Fxp=XOcq2jZLNU03A56Tn_bEp5o6V1V7AFcr-Q@mail.gmail.com>
 <CADYNDzi5CdieoA3hdfyd0ZTU+fePMctBFzkRPHUxxaNeK0X5Fg@mail.gmail.com>
 <CAJR3sXe+Cf45QaV+V=ciozo8+0M4YNkjCy-7SxCGbYct3nZKsQ@mail.gmail.com>
 <CADYNDzg8SEEuG_QTxt57TXsi4s3j-Pe_0X1ovrPSOoGxN+UVYw@mail.gmail.com>
 <CAGu2niWoLJ5u-Ux=jb3HFBBfN18L6fsdMcwb4OLH36044PEJ0g@mail.gmail.com>
 <CADYNDzi1xQokrvVPkPhS2smJYRrm96fu_TB=DTYZb=hXJheUZg@mail.gmail.com>
 <CAGu2niXhVZQPBe23a_ftypwp3oqq2ui14P9TnVc9MEXD5mu1SA@mail.gmail.com>
 <CADYNDzh=M2yTnEE0C2HNuCDARXJhHhbHC8UkYnXUgeTA8fdx=Q@mail.gmail.com>
 <CAGu2niUmN=3w=4TAsp0Nc4QN5z5D2p9XA6Ji_6JRAw1MvG1Pmw@mail.gmail.com>
 <CADYNDzh5td0x4sK50VvFw6YQD+Nhc=+hqrYTai4kfYv+F4ttpQ@mail.gmail.com>
 <CAGu2niU3NRhWyCpuMw8WMjfC0sLgq7=PtO8PZJDrsYLSR8V81w@mail.gmail.com>
 <CADYNDzipyXrOeDxbx+ngL0G06LdYpAq32qk2jEO+75=JUREedw@mail.gmail.com>
 <CAJR3sXdcPMAn_DETF8W-=MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw@mail.gmail.com>
 <CADYNDzgcYEQ4Wy9Yd2J+MCPE+q+k1bjYTR=X31qNd=MwmDC8ag@mail.gmail.com>
 <CADYNDzjK4c+V6cnNMZW6vZkfhj=X50+DawpVFhBvTntt5-5hEg@mail.gmail.com>
 <CABL7CQhoCz576DQApAgX-qG3Qp=hsmctOgk=7KEDTKuXN4jgeg@mail.gmail.com>
 <CADYNDziEzeWDgCxZUK55u2tFU1jfnr1pPU_KB8c0_6pr73+PLA@mail.gmail.com>
Message-ID: <CABL7CQhB6K5nhtA15=u_+URKtfgHiLDQJtORBEnvh=gMcaVmQg@mail.gmail.com>

On Tue, Apr 2, 2019 at 8:59 AM Gopi Manohar Tatiraju <deathcoderx at gmail.com>
wrote:

> Hey,
> Are you suggesting that we need to make changes in PYFFTW?
> If so, then for every third party FFTPACK we need to make changes in that
> specific pack, right?
>

correct


>
> Cheers,
> Gopi
>
> On Tue, Apr 2, 2019 at 12:18 PM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>>
>>
>> On Tue, Apr 2, 2019 at 8:17 AM Gopi Manohar Tatiraju <
>> deathcoderx at gmail.com> wrote:
>>
>>> Hey,
>>> Greg, I went through the ideas you have mentioned and also looked up the
>>> matplotlib docs as suggested.  And I feel like creating a new namespace
>>> would be a better option as it won't require many changes in the current
>>> implementation. As matplotlib.pyplot is a well-implemented module  I feel
>>> like we can consider it as our basic structure and start implementing the
>>> backend.
>>>
>>
>> A new namespace is not a good idea. There's no reason that things can't
>> work for the current namespace.
>>
>>
>>> For the start, I think import can look like this(rough idea)
>>> import scipy.fftpack.pyfftw as fft
>>> where pyffw can be replaced by any third party fftpack.
>>>
>>
>> We don't want a PyFFTW namespace or direct support for PyFFTW (note that
>> we removed such support years ago due to license reasons). Instead, we want
>> to allow third parties to implement a backend; for FFTW this will live in
>> https://github.com/pyFFTW/pyFFTW
>>
>> Cheers,
>> Ralf
>>
>>
>>
>>> Cheers.
>>> -Gopi
>>>
>>>
>>> On Sun, Mar 31, 2019 at 2:00 AM Gopi Manohar Tatiraju <
>>> deathcoderx at gmail.com> wrote:
>>>
>>>> Hey,
>>>> I feel like I need to make some more changes regarding the idea. I went
>>>> through your reply to Anany and I will consider all those points and will
>>>> get back to you once I come up with something.
>>>>
>>>> -Gopi.
>>>>
>>>> On Sun, Mar 31, 2019 at 5:24 AM Gregory Lee <grlee77 at gmail.com> wrote:
>>>>
>>>>> Hi Gopi,
>>>>>
>>>>> I am not sure I follow exactly what you are suggesting here. Are you
>>>>> proposing that the `fftpackN` variable in your example would be a Python
>>>>> module corresponding to a given backend? If so, why is an array of data, z,
>>>>> being passed into the newAPI function here? I don't see why a data array
>>>>> should be needed at all to choose a backend.
>>>>>
>>>>> Please also see my response to Anany's recent post on this list for a
>>>>> couple of other suggestions of things to consider in terms of the API.
>>>>>
>>>>> - Greg
>>>>>
>>>>>
>>>>> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
>>>>> deathcoderx at gmail.com> wrote:
>>>>>
>>>>>> Hey,
>>>>>> I went through the code and got some ideas.
>>>>>> So what will happen is:
>>>>>> First, we will declare FFTW as we use them normally.
>>>>>>
>>>>>> z = np.random.rand(2, 128, 64)
>>>>>> pyfftw.FFTW(z, axes=(-1, ))
>>>>>> ..
>>>>>> ..
>>>>>> Now after declaring our basic work to shift to another FFTpack, what
>>>>>> we can do is:
>>>>>> fftPackN= newAPI(z, pack = 'PYFFTW');
>>>>>>
>>>>>> Pack will take the name of the 3rd party FFT pack which we want to
>>>>>> use.
>>>>>> Suggestions needed.
>>>>>>
>>>>>> Cheers.
>>>>>>
>>>>>>
>>>>>
>>>>>>
>>>>>> On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <larson.eric.d at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> After reading the related issues and thinking about the problem,
>>>>>>> perhaps the best first step is you come up with some initial API proposal.
>>>>>>>
>>>>>>> One way to work through the process is to think about the use cases
>>>>>>> that we want to support. How should users actually write code to use the
>>>>>>> new functionality? You can start with short code snippets that do not work
>>>>>>> currently, but should work for users at the end of the project. Then think
>>>>>>> about what needs to change inside SciPy for these code snippets to work.
>>>>>>> This can become an iterative process as you realize that the SciPy changes
>>>>>>> might be better or easier with changes to the user-facing API, etc.
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hey,
>>>>>>>> As proposal submission period started I want to discuss a bit anobt
>>>>>>>> how can we implement the API.
>>>>>>>> I would very much appriciate inputs and guidance.
>>>>>>>>
>>>>>>>> Cheers.
>>>>>>>>
>>>>>>>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <
>>>>>>>> larson.eric.d at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> The best way to figure that out is probably to take a look at some
>>>>>>>>> of the existing (minor) SciPy GitHub issues and try to work on one or two
>>>>>>>>> that you feel like working on. Actually trying to work out how to
>>>>>>>>> contribute code changes (as independently as possible/reasonable based on
>>>>>>>>> the existing guides/docs already discoverable online) will quickly
>>>>>>>>> highlight things that need to be learned. Some of the general things are
>>>>>>>>> the SciPy contributing guidelines, standard GitHub PR workflow,
>>>>>>>>> communication with reviewers, and so forth.
>>>>>>>>>
>>>>>>>>> For this particular project, it's important to understand the
>>>>>>>>> various flavors and properties of FFT in SciPy (real, complex,
>>>>>>>>> n-dimensional, caching plans, etc.) as well as other projects like NumPy,
>>>>>>>>> CuPy, and pyFFTW. Some of this can be learned and improved upon as part of
>>>>>>>>> GSoC, but the more you know and can demonstrate / put into practice
>>>>>>>>> knowledge of before the applications are reviewed, the better.
>>>>>>>>>
>>>>>>>>> Eric
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Thank you for the detailed reply.
>>>>>>>>>> I will keep these point in mind while preparing my proposal.
>>>>>>>>>> Apart from proposal, what skills shall I improve so that I can contribute
>>>>>>>>>> more effectively and efficiently.
>>>>>>>>>>
>>>>>>>>>> Cheers.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <larson.eric.d at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> There are a number of considerations that would be good to
>>>>>>>>>>> address. I'd start by considering the things that are typically considered
>>>>>>>>>>> when making changes to SciPy
>>>>>>>>>>> <https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy>,
>>>>>>>>>>> but I'd expand it to a longer list since the scope is bigger than a typical
>>>>>>>>>>> single PR. The list would contain (at least):
>>>>>>>>>>>
>>>>>>>>>>> - what will the user-facing API / contract be?
>>>>>>>>>>> - what in SciPy needs to change to allow it (internals /
>>>>>>>>>>> implementation outline, perhaps skeleton functions/classes)?
>>>>>>>>>>> - what examples should we show users (in general this ends up
>>>>>>>>>>> being just simple use cases of the API)?
>>>>>>>>>>> - how will we test it for correctness?
>>>>>>>>>>> - how will we benchmark it to prevent performance regressions?
>>>>>>>>>>> - how can we break up the work for these steps (if possible)
>>>>>>>>>>> into separable, sequential (or -- better but not usually possible --
>>>>>>>>>>> independent) PRs?
>>>>>>>>>>>
>>>>>>>>>>> You might notice that none of these points are actually all that
>>>>>>>>>>> specific to the FFT project, but can be generally applicable to GSoC
>>>>>>>>>>> projects. For the FFT project, I would say "how do we build the backend" is
>>>>>>>>>>> indeed implicitly contained / outlined in these bullet points. And as with
>>>>>>>>>>> most projects, the first two points (and possibly the last) will probably
>>>>>>>>>>> be the most challenging to sort out.
>>>>>>>>>>>
>>>>>>>>>>> Eric
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hey Eric,
>>>>>>>>>>>> So for my proposal, shall I include how can we built a back
>>>>>>>>>>>> end? What all points shall I include to make it effective?
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <
>>>>>>>>>>>> larson.eric.d at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> That would be me -- don't worry, I'm on this list, as are
>>>>>>>>>>>>> (presumably) other developers interested in the discussion, so no need to
>>>>>>>>>>>>> document elsewhere for now from our end. It looks like Greg has summarized
>>>>>>>>>>>>> the current status and thoughts we've had, so I don't have much to add at
>>>>>>>>>>>>> this point.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Eric
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
>>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hey Greg,
>>>>>>>>>>>>>> I got the basic idea about what we want to implement this
>>>>>>>>>>>>>> year.
>>>>>>>>>>>>>> Our first priority is to create a backend for 3rd party
>>>>>>>>>>>>>> fftpacks. We can create API using Python and Flask or any other suitable
>>>>>>>>>>>>>> framework.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I thought this discussion was going on on SciPy Developer
>>>>>>>>>>>>>> List only. So do I need to document it all and post it somewhere so that
>>>>>>>>>>>>>> other contributors can see this?
>>>>>>>>>>>>>> Also, I couldn't find any contact info regarding Eric. It
>>>>>>>>>>>>>> would be very helpful if we include him in this discussion as this is a
>>>>>>>>>>>>>> roadmap for GSoC project and I can also get more insight into the project
>>>>>>>>>>>>>> and expected outcomes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <grlee77 at gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
>>>>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hey Gregory,
>>>>>>>>>>>>>>>> I went through the idea and I am very much interested in
>>>>>>>>>>>>>>>> working on it. I had Fourier Transforms as a part of my academic course, so
>>>>>>>>>>>>>>>> I am well aware with basic concepts.
>>>>>>>>>>>>>>>> One thing I want to discuss is, its mentioned that we have
>>>>>>>>>>>>>>>> to create a backend system for 3rd party FFTpacks so my dobuts
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. How are we going to create API?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This will needed to be decided on in consensus with the
>>>>>>>>>>>>>>> SciPy developers and user community. I am mentoring for the project as a
>>>>>>>>>>>>>>> contributor here and a maintainer of the related pyFFTW package, but I am
>>>>>>>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core dev here). I have
>>>>>>>>>>>>>>> not discussed the API in any detail with the SciPy team at this stage.
>>>>>>>>>>>>>>> Working out details of what the API should look like and working to
>>>>>>>>>>>>>>> finalize that in collaboration with the community will be a primary task
>>>>>>>>>>>>>>> during the early part of the GSOC project.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2. After the creation of backend will user at the time of
>>>>>>>>>>>>>>>> installation of SciPy will decide what all 3rd party FFTpacks he needs or
>>>>>>>>>>>>>>>> we will include some by default?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The idea is to allow users to opt-in to a different FFT
>>>>>>>>>>>>>>> backend at run time, but these alternative libraries will not be
>>>>>>>>>>>>>>> distributed with SciPy itself due to incompatible software licenses (pyFFTW
>>>>>>>>>>>>>>> and mkl-fft) or a requirement for specific hardware (CuPy requires an
>>>>>>>>>>>>>>> NVIDIA GPU). SciPy will continue to offer its own bundled FFT library
>>>>>>>>>>>>>>> (currently fftpack, but this could be switched to pocketfft as discussed in
>>>>>>>>>>>>>>> the ideas page). The purpose of the backend interface is to provide a
>>>>>>>>>>>>>>> convenient way for users to have third party libraries perform the FFTs
>>>>>>>>>>>>>>> instead, but under the existing scipy.fftpack API. This is motivated by a
>>>>>>>>>>>>>>> desire by end users and downstream projects to have features such as
>>>>>>>>>>>>>>> multi-threading (pyFFTW and mkl-fft) or GPU support (CuPy) that are not
>>>>>>>>>>>>>>> implemented in scipy.fftpack. Ultimately it will be up to users that opt-in
>>>>>>>>>>>>>>> to using these other libraries to confirm that the license terms and are
>>>>>>>>>>>>>>> compatible with their use case.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev mailing
>>>>>>>>>>>>>>> lists prefers replies **below** the email you are replying to so people can
>>>>>>>>>>>>>>> more easily follow the thread of discussion. There are some guidelines at:
>>>>>>>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I will research more about how to implement a backend myself
>>>>>>>>>>>>>>>> and will let you know as soon as I come up with something new.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> CHeers,
>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <
>>>>>>>>>>>>>>>> grlee77 at gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
>>>>>>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started fixing
>>>>>>>>>>>>>>>>>> some bugs, also made some pull request. Can anyone suggest me how should I
>>>>>>>>>>>>>>>>>> proceed further?
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Gopi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think you have probably already found it, but the GSOC
>>>>>>>>>>>>>>>>> project we have already identified mentors for in SciPy is here:
>>>>>>>>>>>>>>>>> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If this is a project you are interested in then I would
>>>>>>>>>>>>>>>>> start thinking about what the FFT interface would look like and reviewing
>>>>>>>>>>>>>>>>> some of the past/present issues related to fftpack / FFT in SciPy. Please
>>>>>>>>>>>>>>>>> ask questions you have related to that project here so that you can clarify
>>>>>>>>>>>>>>>>> what would be involved in writing a successful application.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If you have a different idea in mind you can propose it
>>>>>>>>>>>>>>>>> here, but you should do that soon, because it will be necessary to
>>>>>>>>>>>>>>>>> determine if there is interest from the SciPy team before you spend time
>>>>>>>>>>>>>>>>> coming up with a detailed proposal. We have to determine if a project
>>>>>>>>>>>>>>>>> sounds feasible to complete for GSOC and if appropriate mentors can be
>>>>>>>>>>>>>>>>> identified.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ultimately, you will need to submit an application to
>>>>>>>>>>>>>>>>> SciPy between March 25th - April 9th.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190402/16fcd3c0/attachment-0001.html>

From deathcoderx at gmail.com  Tue Apr  2 04:30:40 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Tue, 2 Apr 2019 14:00:40 +0530
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CABL7CQhB6K5nhtA15=u_+URKtfgHiLDQJtORBEnvh=gMcaVmQg@mail.gmail.com>
References: <CADYNDzi=VUB3GXJ7-KZYL9FU=md0CuXf6x0Tc_JEQ4OebTuf+Q@mail.gmail.com>
 <CAJR3sXcnSHv3Fxp=XOcq2jZLNU03A56Tn_bEp5o6V1V7AFcr-Q@mail.gmail.com>
 <CADYNDzi5CdieoA3hdfyd0ZTU+fePMctBFzkRPHUxxaNeK0X5Fg@mail.gmail.com>
 <CAJR3sXe+Cf45QaV+V=ciozo8+0M4YNkjCy-7SxCGbYct3nZKsQ@mail.gmail.com>
 <CADYNDzg8SEEuG_QTxt57TXsi4s3j-Pe_0X1ovrPSOoGxN+UVYw@mail.gmail.com>
 <CAGu2niWoLJ5u-Ux=jb3HFBBfN18L6fsdMcwb4OLH36044PEJ0g@mail.gmail.com>
 <CADYNDzi1xQokrvVPkPhS2smJYRrm96fu_TB=DTYZb=hXJheUZg@mail.gmail.com>
 <CAGu2niXhVZQPBe23a_ftypwp3oqq2ui14P9TnVc9MEXD5mu1SA@mail.gmail.com>
 <CADYNDzh=M2yTnEE0C2HNuCDARXJhHhbHC8UkYnXUgeTA8fdx=Q@mail.gmail.com>
 <CAGu2niUmN=3w=4TAsp0Nc4QN5z5D2p9XA6Ji_6JRAw1MvG1Pmw@mail.gmail.com>
 <CADYNDzh5td0x4sK50VvFw6YQD+Nhc=+hqrYTai4kfYv+F4ttpQ@mail.gmail.com>
 <CAGu2niU3NRhWyCpuMw8WMjfC0sLgq7=PtO8PZJDrsYLSR8V81w@mail.gmail.com>
 <CADYNDzipyXrOeDxbx+ngL0G06LdYpAq32qk2jEO+75=JUREedw@mail.gmail.com>
 <CAJR3sXdcPMAn_DETF8W-=MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw@mail.gmail.com>
 <CADYNDzgcYEQ4Wy9Yd2J+MCPE+q+k1bjYTR=X31qNd=MwmDC8ag@mail.gmail.com>
 <CADYNDzjK4c+V6cnNMZW6vZkfhj=X50+DawpVFhBvTntt5-5hEg@mail.gmail.com>
 <CABL7CQhoCz576DQApAgX-qG3Qp=hsmctOgk=7KEDTKuXN4jgeg@mail.gmail.com>
 <CADYNDziEzeWDgCxZUK55u2tFU1jfnr1pPU_KB8c0_6pr73+PLA@mail.gmail.com>
 <CABL7CQhB6K5nhtA15=u_+URKtfgHiLDQJtORBEnvh=gMcaVmQg@mail.gmail.com>
Message-ID: <CADYNDzh56PjgSZFx1BAXndTw1FM4O83CaJpOR2cp6LnjbKQwqA@mail.gmail.com>

hey,
Ohk Ralf, then I will start thinking of some ways to do it while keeping in
my that the main changes should not be in Scipy but rather in the 3rd party
FFTPACKs.

Cheers.


On Tue, Apr 2, 2019 at 1:53 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Tue, Apr 2, 2019 at 8:59 AM Gopi Manohar Tatiraju <
> deathcoderx at gmail.com> wrote:
>
>> Hey,
>> Are you suggesting that we need to make changes in PYFFTW?
>> If so, then for every third party FFTPACK we need to make changes in that
>> specific pack, right?
>>
>
> correct
>
>
>>
>> Cheers,
>> Gopi
>>
>> On Tue, Apr 2, 2019 at 12:18 PM Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Apr 2, 2019 at 8:17 AM Gopi Manohar Tatiraju <
>>> deathcoderx at gmail.com> wrote:
>>>
>>>> Hey,
>>>> Greg, I went through the ideas you have mentioned and also looked up
>>>> the matplotlib docs as suggested.  And I feel like creating a new namespace
>>>> would be a better option as it won't require many changes in the current
>>>> implementation. As matplotlib.pyplot is a well-implemented module  I feel
>>>> like we can consider it as our basic structure and start implementing the
>>>> backend.
>>>>
>>>
>>> A new namespace is not a good idea. There's no reason that things can't
>>> work for the current namespace.
>>>
>>>
>>>> For the start, I think import can look like this(rough idea)
>>>> import scipy.fftpack.pyfftw as fft
>>>> where pyffw can be replaced by any third party fftpack.
>>>>
>>>
>>> We don't want a PyFFTW namespace or direct support for PyFFTW (note that
>>> we removed such support years ago due to license reasons). Instead, we want
>>> to allow third parties to implement a backend; for FFTW this will live in
>>> https://github.com/pyFFTW/pyFFTW
>>>
>>> Cheers,
>>> Ralf
>>>
>>>
>>>
>>>> Cheers.
>>>> -Gopi
>>>>
>>>>
>>>> On Sun, Mar 31, 2019 at 2:00 AM Gopi Manohar Tatiraju <
>>>> deathcoderx at gmail.com> wrote:
>>>>
>>>>> Hey,
>>>>> I feel like I need to make some more changes regarding the idea. I
>>>>> went through your reply to Anany and I will consider all those points and
>>>>> will get back to you once I come up with something.
>>>>>
>>>>> -Gopi.
>>>>>
>>>>> On Sun, Mar 31, 2019 at 5:24 AM Gregory Lee <grlee77 at gmail.com> wrote:
>>>>>
>>>>>> Hi Gopi,
>>>>>>
>>>>>> I am not sure I follow exactly what you are suggesting here. Are you
>>>>>> proposing that the `fftpackN` variable in your example would be a Python
>>>>>> module corresponding to a given backend? If so, why is an array of data, z,
>>>>>> being passed into the newAPI function here? I don't see why a data array
>>>>>> should be needed at all to choose a backend.
>>>>>>
>>>>>> Please also see my response to Anany's recent post on this list for a
>>>>>> couple of other suggestions of things to consider in terms of the API.
>>>>>>
>>>>>> - Greg
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>
>>>>>>> Hey,
>>>>>>> I went through the code and got some ideas.
>>>>>>> So what will happen is:
>>>>>>> First, we will declare FFTW as we use them normally.
>>>>>>>
>>>>>>> z = np.random.rand(2, 128, 64)
>>>>>>> pyfftw.FFTW(z, axes=(-1, ))
>>>>>>> ..
>>>>>>> ..
>>>>>>> Now after declaring our basic work to shift to another FFTpack, what
>>>>>>> we can do is:
>>>>>>> fftPackN= newAPI(z, pack = 'PYFFTW');
>>>>>>>
>>>>>>> Pack will take the name of the 3rd party FFT pack which we want to
>>>>>>> use.
>>>>>>> Suggestions needed.
>>>>>>>
>>>>>>> Cheers.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <larson.eric.d at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> After reading the related issues and thinking about the problem,
>>>>>>>> perhaps the best first step is you come up with some initial API proposal.
>>>>>>>>
>>>>>>>> One way to work through the process is to think about the use cases
>>>>>>>> that we want to support. How should users actually write code to use the
>>>>>>>> new functionality? You can start with short code snippets that do not work
>>>>>>>> currently, but should work for users at the end of the project. Then think
>>>>>>>> about what needs to change inside SciPy for these code snippets to work.
>>>>>>>> This can become an iterative process as you realize that the SciPy changes
>>>>>>>> might be better or easier with changes to the user-facing API, etc.
>>>>>>>>
>>>>>>>> Eric
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hey,
>>>>>>>>> As proposal submission period started I want to discuss a bit
>>>>>>>>> anobt how can we implement the API.
>>>>>>>>> I would very much appriciate inputs and guidance.
>>>>>>>>>
>>>>>>>>> Cheers.
>>>>>>>>>
>>>>>>>>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <
>>>>>>>>> larson.eric.d at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> The best way to figure that out is probably to take a look at
>>>>>>>>>> some of the existing (minor) SciPy GitHub issues and try to work on one or
>>>>>>>>>> two that you feel like working on. Actually trying to work out how to
>>>>>>>>>> contribute code changes (as independently as possible/reasonable based on
>>>>>>>>>> the existing guides/docs already discoverable online) will quickly
>>>>>>>>>> highlight things that need to be learned. Some of the general things are
>>>>>>>>>> the SciPy contributing guidelines, standard GitHub PR workflow,
>>>>>>>>>> communication with reviewers, and so forth.
>>>>>>>>>>
>>>>>>>>>> For this particular project, it's important to understand the
>>>>>>>>>> various flavors and properties of FFT in SciPy (real, complex,
>>>>>>>>>> n-dimensional, caching plans, etc.) as well as other projects like NumPy,
>>>>>>>>>> CuPy, and pyFFTW. Some of this can be learned and improved upon as part of
>>>>>>>>>> GSoC, but the more you know and can demonstrate / put into practice
>>>>>>>>>> knowledge of before the applications are reviewed, the better.
>>>>>>>>>>
>>>>>>>>>> Eric
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Thank you for the detailed reply.
>>>>>>>>>>> I will keep these point in mind while preparing my proposal.
>>>>>>>>>>> Apart from proposal, what skills shall I improve so that I can contribute
>>>>>>>>>>> more effectively and efficiently.
>>>>>>>>>>>
>>>>>>>>>>> Cheers.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <
>>>>>>>>>>> larson.eric.d at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> There are a number of considerations that would be good to
>>>>>>>>>>>> address. I'd start by considering the things that are typically considered
>>>>>>>>>>>> when making changes to SciPy
>>>>>>>>>>>> <https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy>,
>>>>>>>>>>>> but I'd expand it to a longer list since the scope is bigger than a typical
>>>>>>>>>>>> single PR. The list would contain (at least):
>>>>>>>>>>>>
>>>>>>>>>>>> - what will the user-facing API / contract be?
>>>>>>>>>>>> - what in SciPy needs to change to allow it (internals /
>>>>>>>>>>>> implementation outline, perhaps skeleton functions/classes)?
>>>>>>>>>>>> - what examples should we show users (in general this ends up
>>>>>>>>>>>> being just simple use cases of the API)?
>>>>>>>>>>>> - how will we test it for correctness?
>>>>>>>>>>>> - how will we benchmark it to prevent performance regressions?
>>>>>>>>>>>> - how can we break up the work for these steps (if possible)
>>>>>>>>>>>> into separable, sequential (or -- better but not usually possible --
>>>>>>>>>>>> independent) PRs?
>>>>>>>>>>>>
>>>>>>>>>>>> You might notice that none of these points are actually all
>>>>>>>>>>>> that specific to the FFT project, but can be generally applicable to GSoC
>>>>>>>>>>>> projects. For the FFT project, I would say "how do we build the backend" is
>>>>>>>>>>>> indeed implicitly contained / outlined in these bullet points. And as with
>>>>>>>>>>>> most projects, the first two points (and possibly the last) will probably
>>>>>>>>>>>> be the most challenging to sort out.
>>>>>>>>>>>>
>>>>>>>>>>>> Eric
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey Eric,
>>>>>>>>>>>>> So for my proposal, shall I include how can we built a back
>>>>>>>>>>>>> end? What all points shall I include to make it effective?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <
>>>>>>>>>>>>> larson.eric.d at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> That would be me -- don't worry, I'm on this list, as are
>>>>>>>>>>>>>> (presumably) other developers interested in the discussion, so no need to
>>>>>>>>>>>>>> document elsewhere for now from our end. It looks like Greg has summarized
>>>>>>>>>>>>>> the current status and thoughts we've had, so I don't have much to add at
>>>>>>>>>>>>>> this point.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Eric
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
>>>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hey Greg,
>>>>>>>>>>>>>>> I got the basic idea about what we want to implement this
>>>>>>>>>>>>>>> year.
>>>>>>>>>>>>>>> Our first priority is to create a backend for 3rd party
>>>>>>>>>>>>>>> fftpacks. We can create API using Python and Flask or any other suitable
>>>>>>>>>>>>>>> framework.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I thought this discussion was going on on SciPy Developer
>>>>>>>>>>>>>>> List only. So do I need to document it all and post it somewhere so that
>>>>>>>>>>>>>>> other contributors can see this?
>>>>>>>>>>>>>>> Also, I couldn't find any contact info regarding Eric. It
>>>>>>>>>>>>>>> would be very helpful if we include him in this discussion as this is a
>>>>>>>>>>>>>>> roadmap for GSoC project and I can also get more insight into the project
>>>>>>>>>>>>>>> and expected outcomes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <
>>>>>>>>>>>>>>> grlee77 at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
>>>>>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hey Gregory,
>>>>>>>>>>>>>>>>> I went through the idea and I am very much interested in
>>>>>>>>>>>>>>>>> working on it. I had Fourier Transforms as a part of my academic course, so
>>>>>>>>>>>>>>>>> I am well aware with basic concepts.
>>>>>>>>>>>>>>>>> One thing I want to discuss is, its mentioned that we have
>>>>>>>>>>>>>>>>> to create a backend system for 3rd party FFTpacks so my dobuts
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1. How are we going to create API?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This will needed to be decided on in consensus with the
>>>>>>>>>>>>>>>> SciPy developers and user community. I am mentoring for the project as a
>>>>>>>>>>>>>>>> contributor here and a maintainer of the related pyFFTW package, but I am
>>>>>>>>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core dev here). I have
>>>>>>>>>>>>>>>> not discussed the API in any detail with the SciPy team at this stage.
>>>>>>>>>>>>>>>> Working out details of what the API should look like and working to
>>>>>>>>>>>>>>>> finalize that in collaboration with the community will be a primary task
>>>>>>>>>>>>>>>> during the early part of the GSOC project.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2. After the creation of backend will user at the time of
>>>>>>>>>>>>>>>>> installation of SciPy will decide what all 3rd party FFTpacks he needs or
>>>>>>>>>>>>>>>>> we will include some by default?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The idea is to allow users to opt-in to a different FFT
>>>>>>>>>>>>>>>> backend at run time, but these alternative libraries will not be
>>>>>>>>>>>>>>>> distributed with SciPy itself due to incompatible software licenses (pyFFTW
>>>>>>>>>>>>>>>> and mkl-fft) or a requirement for specific hardware (CuPy requires an
>>>>>>>>>>>>>>>> NVIDIA GPU). SciPy will continue to offer its own bundled FFT library
>>>>>>>>>>>>>>>> (currently fftpack, but this could be switched to pocketfft as discussed in
>>>>>>>>>>>>>>>> the ideas page). The purpose of the backend interface is to provide a
>>>>>>>>>>>>>>>> convenient way for users to have third party libraries perform the FFTs
>>>>>>>>>>>>>>>> instead, but under the existing scipy.fftpack API. This is motivated by a
>>>>>>>>>>>>>>>> desire by end users and downstream projects to have features such as
>>>>>>>>>>>>>>>> multi-threading (pyFFTW and mkl-fft) or GPU support (CuPy) that are not
>>>>>>>>>>>>>>>> implemented in scipy.fftpack. Ultimately it will be up to users that opt-in
>>>>>>>>>>>>>>>> to using these other libraries to confirm that the license terms and are
>>>>>>>>>>>>>>>> compatible with their use case.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev
>>>>>>>>>>>>>>>> mailing lists prefers replies **below** the email you are replying to so
>>>>>>>>>>>>>>>> people can more easily follow the thread of discussion. There are some
>>>>>>>>>>>>>>>> guidelines at:
>>>>>>>>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I will research more about how to implement a backend
>>>>>>>>>>>>>>>>> myself and will let you know as soon as I come up with something new.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> CHeers,
>>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <
>>>>>>>>>>>>>>>>> grlee77 at gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
>>>>>>>>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started fixing
>>>>>>>>>>>>>>>>>>> some bugs, also made some pull request. Can anyone suggest me how should I
>>>>>>>>>>>>>>>>>>> proceed further?
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Gopi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think you have probably already found it, but the GSOC
>>>>>>>>>>>>>>>>>> project we have already identified mentors for in SciPy is here:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If this is a project you are interested in then I would
>>>>>>>>>>>>>>>>>> start thinking about what the FFT interface would look like and reviewing
>>>>>>>>>>>>>>>>>> some of the past/present issues related to fftpack / FFT in SciPy. Please
>>>>>>>>>>>>>>>>>> ask questions you have related to that project here so that you can clarify
>>>>>>>>>>>>>>>>>> what would be involved in writing a successful application.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If you have a different idea in mind you can propose it
>>>>>>>>>>>>>>>>>> here, but you should do that soon, because it will be necessary to
>>>>>>>>>>>>>>>>>> determine if there is interest from the SciPy team before you spend time
>>>>>>>>>>>>>>>>>> coming up with a detailed proposal. We have to determine if a project
>>>>>>>>>>>>>>>>>> sounds feasible to complete for GSOC and if appropriate mentors can be
>>>>>>>>>>>>>>>>>> identified.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ultimately, you will need to submit an application to
>>>>>>>>>>>>>>>>>> SciPy between March 25th - April 9th.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190402/5ce77926/attachment-0001.html>

From ralf.gommers at gmail.com  Tue Apr  2 04:40:20 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 2 Apr 2019 10:40:20 +0200
Subject: [SciPy-Dev] Google Season of Docs
In-Reply-To: <CABL7CQg43qU1RhtFUp_5C2RZ5nHLAx+6bBSs=6Q0QAKne4G0EA@mail.gmail.com>
References: <CABXY2qAKDhT=0K+EbUYXCpKWtjKOTVGKb_Q8TDX-mM=nGvZJHw@mail.gmail.com>
 <CABL7CQg43qU1RhtFUp_5C2RZ5nHLAx+6bBSs=6Q0QAKne4G0EA@mail.gmail.com>
Message-ID: <CABL7CQipvttnWrAE=V6Fr+iJKjGM1x0wgKbK-ea7ZNsOXx6YDg@mail.gmail.com>

On Fri, Mar 22, 2019 at 8:07 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Thu, Mar 21, 2019 at 12:10 PM Christoph Baumgarten <
> christoph.baumgarten at gmail.com> wrote:
>
>>
>> Hi,
>>
>> taking up Ralf's mail on GSoD, I had a look at the website and propose to
>> apply.
>>
>> My project suggestion would be to work on the documentation of a module
>> like stats:
>>
>
>> - improve the tutorial site
>> https://docs.scipy.org/doc/scipy/reference/tutorial/stats.html
>> - improve the documentation of the API
>>   - check whether current descriptions can be improved
>>   - add examples and references
>>   - cross-ref to other relevant / similar functions in the module
>>
>> The second point would require decent knowledge of statistics whereas the
>> first point should be easier to tackle for a technical writer. So I see the
>> second point as optional and one could also try to work on the tutorial
>> site of more than one module during the 3-month period.
>>
>
>> The task would leave quite a bit of freedom to the writer to choose what
>> areas to focus on, potentially taking up some of the documentation issues
>> that are already on Github.
>>
>> I could assist as a mentor for stats (we need at least two mentors).
>>
>> Any suggestions or comments?
>>
>
> Thanks Christoph, this sounds like a good idea to me. We have a lot of
> content on scipy.stats, and a tech writer could really make a difference in
> making that easier to understand for users. I suggest we write this up as
> an idea on our (to be created) ideas page as soon as we know whether we
> have an umbrella organization that we can participate with.
>

 An update on this: NumFOCUS is applying as an umbrella org. We'll need to
add our ideas at
https://github.com/numfocus/gsod/blob/master/2019/SciPy_ideas_list.md.
Since there are going to be few spots available, it's the quality of the
content that matters for acceptance of NumFOCUS as an umbrella org. We
should have 1-2 ideas that are well described up on that page by April
14th. There are some guidelines at
https://developers.google.com/season-of-docs/docs/project-ideas#project-idea

Christoph, could you add your idea in that SciPy_ideas_list.md file?

I will add some more general information there about getting started on the
SciPy docs. Also, if anyone has another idea, that would be great to hear.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190402/244fdd76/attachment.html>

From f20170920 at goa.bits-pilani.ac.in  Tue Apr  2 14:18:55 2019
From: f20170920 at goa.bits-pilani.ac.in (Anany Shrey Jain)
Date: Tue, 2 Apr 2019 23:48:55 +0530
Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 185, Issue 18
In-Reply-To: <mailman.99.1553989995.2938.scipy-dev@python.org>
References: <mailman.99.1553989995.2938.scipy-dev@python.org>
Message-ID: <CAG7Qgjhq8fFwGY2vy2CpkbUyymXKu-KrFouzpSuJs2ZqEcCRrg@mail.gmail.com>

Hey,
I have already sent the link to the page containing the list of ideas for
implementation of new API that I propose for this project. Would you like
to add something to it or give some comments on it? The Gsoc proposal
deadline is 9th of April and I am planning to put all of this in my
proposal to make it effective . So any more ideas or comments will be
really helpful for me . Here is the link to the page:
https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy .

On Sun, Mar 31, 2019 at 5:23 AM <scipy-dev-request at python.org> wrote:

>
> Message: 1
> Date: Sat, 30 Mar 2019 13:31:51 -0400
> From: Eric Larson <larson.eric.d at gmail.com>
> To: SciPy Developers List <scipy-dev at python.org>
> Subject: Re: [SciPy-Dev] GSoC 2019
> Message-ID:
>         <
> CAGu2niVWsKrMukfWcAWAtj-1NBm2utCeh3BOnNku7jNoAcx-kw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> It looks like the main ideas are in these bits of code, but not explicitly
> stated. In brief it looks like the proposed API is to add a `fft_object`
> kwarg to every function in `scipy.fftpack`. It would be good to discuss
> this choice explicitly -- what advantages and disadvantages it has relative
> to other approaches (e.g., creating new namespaces, or having a
> `set_backend` function (and/or context manager) that would change things
> under the hood).
>
> If you make changes and need more feedback, let us know. The more specific
> you can be about what you need feedback on (high level ideas, low level
> implementation, etc.), the better.
>
> Eric
>
>
> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
> f20170920 at goa.bits-pilani.ac.in> wrote:
>
> > Hey,
> > I went through the idea list of Scipy for this years's GSoC and I intend
> > to work towards the idea of revamping the Scipy's fftpack. I have already
> > been contributing to Scipy since the end of last year and I have some
> > knowledge about Fourier transforms as it was the part of my discipline. I
> > could not take part in this discussion earlier because my mid semester
> > exams were going on, but since they are now over so I can devote as much
> > time as required on this project. I have already created a github page
> with
> > some code snippets and functionalities that we can implement, here is the
> > link to it:
> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy .
> >
> > Cheers,
> > Anany Jain
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at python.org
> > https://mail.python.org/mailman/listinfo/scipy-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/f1755dfb/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Sat, 30 Mar 2019 19:38:41 -0400
> From: Gregory Lee <grlee77 at gmail.com>
> To: SciPy Developers List <scipy-dev at python.org>
> Subject: Re: [SciPy-Dev] GSoC 2019
> Message-ID:
>         <CAJR3sXfnnr-0JO87gLbhh-7b-w=KjaNpac+F+FHTeFt2K=_
> QMw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
> f20170920 at goa.bits-pilani.ac.in> wrote:
>
> > Hey,
> > I went through the idea list of Scipy for this years's GSoC and I intend
> > to work towards the idea of revamping the Scipy's fftpack. I have already
> > been contributing to Scipy since the end of last year and I have some
> > knowledge about Fourier transforms as it was the part of my discipline. I
> > could not take part in this discussion earlier because my mid semester
> > exams were going on, but since they are now over so I can devote as much
> > time as required on this project. I have already created a github page
> with
> > some code snippets and functionalities that we can implement, here is the
> > link to it:
> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy .
> >
> > Cheers,
> > Anany Jain
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at python.org
> > https://mail.python.org/mailman/listinfo/scipy-dev
>
>
> Hi Anany,
>
> Thank you for your interest in GSOC with SciPy!  It's great to see that you
> are already thinking about a potential API and learning about the 3rd party
> FFT libraries. Along the lines of Eric's comment, think about what this API
> choice implies for users of libraries built upon SciPy. Would users of 3rd
> party libraries that rely on SciPy's FFTs be immediately able to take
> advantage of a differentf FFT backend in this scenario? (in other words,
> the case where the user is not calling scipy.fftpack.fft directly but is
> using it only indirectly via a function in a downstream library).
>
> Matplotlib is an example of an existing Python library supporting multiple
> backends that can be considered for comparison (see:
> https://matplotlib.org/faq/usage_faq.html#what-is-a-backend). Think about
> the relative benefits/drawbacks of some of the methods they use for setting
> a backend there as compared to the approach proposed for FFTs here.
>
> Another thing that should be considered: pyFFTW, MKL and CuPy already have
> some functions that match the existing scipy.fftpack API, but they may have
> one or more additional arguments particular to features of that library.
> How would you propose to deal with supporting additional optional arguments
> on the SciPy end?
>
> One other minor comment: I know that the blog post you made may be serving
> partly as personal notes, but please do not directly copy sections of text
> (e.g. the description of BLAS/LAPACK libraries) from elsewhere without
> attribution when writing a final proposal. (Also, the FFT functions are
> separate from the BLAS/LAPACK functions in MKL, so you will not need to
> discuss BLAS or LAPACK specifically in your proposal)
>
> - Greg
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/c1351e7e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Sat, 30 Mar 2019 19:53:02 -0400
> From: Gregory Lee <grlee77 at gmail.com>
> To: SciPy Developers List <scipy-dev at python.org>
> Subject: Re: [SciPy-Dev] GSoC 2019
> Message-ID:
>         <CAJR3sXdcPMAn_DETF8W-=
> MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Gopi,
>
> I am not sure I follow exactly what you are suggesting here. Are you
> proposing that the `fftpackN` variable in your example would be a Python
> module corresponding to a given backend? If so, why is an array of data, z,
> being passed into the newAPI function here? I don't see why a data array
> should be needed at all to choose a backend.
>
> Please also see my response to Anany's recent post on this list for a
> couple of other suggestions of things to consider in terms of the API.
>
> - Greg
>
>
> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
> deathcoderx at gmail.com>
> wrote:
>
> > Hey,
> > I went through the code and got some ideas.
> > So what will happen is:
> > First, we will declare FFTW as we use them normally.
> >
> > z = np.random.rand(2, 128, 64)
> > pyfftw.FFTW(z, axes=(-1, ))
> > ..
> > ..
> > Now after declaring our basic work to shift to another FFTpack, what we
> > can do is:
> > fftPackN= newAPI(z, pack = 'PYFFTW');
> >
> > Pack will take the name of the 3rd party FFT pack which we want to use.
> > Suggestions needed.
> >
> > Cheers.
> >
> >
>
> >
> > On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <larson.eric.d at gmail.com>
> > wrote:
> >
> >> After reading the related issues and thinking about the problem, perhaps
> >> the best first step is you come up with some initial API proposal.
> >>
> >> One way to work through the process is to think about the use cases that
> >> we want to support. How should users actually write code to use the new
> >> functionality? You can start with short code snippets that do not work
> >> currently, but should work for users at the end of the project. Then
> think
> >> about what needs to change inside SciPy for these code snippets to work.
> >> This can become an iterative process as you realize that the SciPy
> changes
> >> might be better or easier with changes to the user-facing API, etc.
> >>
> >> Eric
> >>
> >>
> >> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
> >> deathcoderx at gmail.com> wrote:
> >>
> >>> Hey,
> >>> As proposal submission period started I want to discuss a bit anobt how
> >>> can we implement the API.
> >>> I would very much appriciate inputs and guidance.
> >>>
> >>> Cheers.
> >>>
> >>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <larson.eric.d at gmail.com>
> >>> wrote:
> >>>
> >>>> The best way to figure that out is probably to take a look at some of
> >>>> the existing (minor) SciPy GitHub issues and try to work on one or
> two that
> >>>> you feel like working on. Actually trying to work out how to
> contribute
> >>>> code changes (as independently as possible/reasonable based on the
> existing
> >>>> guides/docs already discoverable online) will quickly highlight
> things that
> >>>> need to be learned. Some of the general things are the SciPy
> contributing
> >>>> guidelines, standard GitHub PR workflow, communication with
> reviewers, and
> >>>> so forth.
> >>>>
> >>>> For this particular project, it's important to understand the various
> >>>> flavors and properties of FFT in SciPy (real, complex, n-dimensional,
> >>>> caching plans, etc.) as well as other projects like NumPy, CuPy, and
> >>>> pyFFTW. Some of this can be learned and improved upon as part of
> GSoC, but
> >>>> the more you know and can demonstrate / put into practice knowledge of
> >>>> before the applications are reviewed, the better.
> >>>>
> >>>> Eric
> >>>>
> >>>>
> >>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
> >>>> deathcoderx at gmail.com> wrote:
> >>>>
> >>>>> Thank you for the detailed reply.
> >>>>> I will keep these point in mind while preparing my proposal. Apart
> >>>>> from proposal, what skills shall I improve so that I can contribute
> more
> >>>>> effectively and efficiently.
> >>>>>
> >>>>> Cheers.
> >>>>>
> >>>>>
> >>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <larson.eric.d at gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> There are a number of considerations that would be good to address.
> >>>>>> I'd start by considering the things that are typically considered
> >>>>>> when making changes to SciPy
> >>>>>> <
> https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy
> >,
> >>>>>> but I'd expand it to a longer list since the scope is bigger than a
> typical
> >>>>>> single PR. The list would contain (at least):
> >>>>>>
> >>>>>> - what will the user-facing API / contract be?
> >>>>>> - what in SciPy needs to change to allow it (internals /
> >>>>>> implementation outline, perhaps skeleton functions/classes)?
> >>>>>> - what examples should we show users (in general this ends up being
> >>>>>> just simple use cases of the API)?
> >>>>>> - how will we test it for correctness?
> >>>>>> - how will we benchmark it to prevent performance regressions?
> >>>>>> - how can we break up the work for these steps (if possible) into
> >>>>>> separable, sequential (or -- better but not usually possible --
> >>>>>> independent) PRs?
> >>>>>>
> >>>>>> You might notice that none of these points are actually all that
> >>>>>> specific to the FFT project, but can be generally applicable to GSoC
> >>>>>> projects. For the FFT project, I would say "how do we build the
> backend" is
> >>>>>> indeed implicitly contained / outlined in these bullet points. And
> as with
> >>>>>> most projects, the first two points (and possibly the last) will
> probably
> >>>>>> be the most challenging to sort out.
> >>>>>>
> >>>>>> Eric
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
> >>>>>> deathcoderx at gmail.com> wrote:
> >>>>>>
> >>>>>>> Hey Eric,
> >>>>>>> So for my proposal, shall I include how can we built a back end?
> >>>>>>> What all points shall I include to make it effective?
> >>>>>>>
> >>>>>>> Cheers.
> >>>>>>>
> >>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <larson.eric.d at gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> That would be me -- don't worry, I'm on this list, as are
> >>>>>>>> (presumably) other developers interested in the discussion, so no
> need to
> >>>>>>>> document elsewhere for now from our end. It looks like Greg has
> summarized
> >>>>>>>> the current status and thoughts we've had, so I don't have much
> to add at
> >>>>>>>> this point.
> >>>>>>>>
> >>>>>>>> Eric
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
> >>>>>>>> deathcoderx at gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> Hey Greg,
> >>>>>>>>> I got the basic idea about what we want to implement this year.
> >>>>>>>>> Our first priority is to create a backend for 3rd party fftpacks.
> >>>>>>>>> We can create API using Python and Flask or any other suitable
> framework.
> >>>>>>>>>
> >>>>>>>>> I thought this discussion was going on on SciPy Developer List
> >>>>>>>>> only. So do I need to document it all and post it somewhere so
> that other
> >>>>>>>>> contributors can see this?
> >>>>>>>>> Also, I couldn't find any contact info regarding Eric. It would
> be
> >>>>>>>>> very helpful if we include him in this discussion as this is a
> roadmap for
> >>>>>>>>> GSoC project and I can also get more insight into the project
> and expected
> >>>>>>>>> outcomes.
> >>>>>>>>>
> >>>>>>>>> Cheers.
> >>>>>>>>>
> >>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <grlee77 at gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
> >>>>>>>>>> deathcoderx at gmail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hey Gregory,
> >>>>>>>>>>> I went through the idea and I am very much interested in
> working
> >>>>>>>>>>> on it. I had Fourier Transforms as a part of my academic
> course, so I am
> >>>>>>>>>>> well aware with basic concepts.
> >>>>>>>>>>> One thing I want to discuss is, its mentioned that we have to
> >>>>>>>>>>> create a backend system for 3rd party FFTpacks so my dobuts
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> 1. How are we going to create API?
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> This will needed to be decided on in consensus with the SciPy
> >>>>>>>>>> developers and user community. I am mentoring for the project
> as a
> >>>>>>>>>> contributor here and a maintainer of the related pyFFTW
> package, but I am
> >>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core dev
> here). I have
> >>>>>>>>>> not discussed the API in any detail with the SciPy team at this
> stage.
> >>>>>>>>>> Working out details of what the API should look like and
> working to
> >>>>>>>>>> finalize that in collaboration with the community will be a
> primary task
> >>>>>>>>>> during the early part of the GSOC project.
> >>>>>>>>>>
> >>>>>>>>>> 2. After the creation of backend will user at the time of
> >>>>>>>>>>> installation of SciPy will decide what all 3rd party FFTpacks
> he needs or
> >>>>>>>>>>> we will include some by default?
> >>>>>>>>>>>
> >>>>>>>>>>> The idea is to allow users to opt-in to a different FFT backend
> >>>>>>>>>> at run time, but these alternative libraries will not be
> distributed with
> >>>>>>>>>> SciPy itself due to incompatible software licenses (pyFFTW and
> mkl-fft) or
> >>>>>>>>>> a requirement for specific hardware (CuPy requires an NVIDIA
> GPU). SciPy
> >>>>>>>>>> will continue to offer its own bundled FFT library (currently
> fftpack, but
> >>>>>>>>>> this could be switched to pocketfft as discussed in the ideas
> page). The
> >>>>>>>>>> purpose of the backend interface is to provide a convenient way
> for users
> >>>>>>>>>> to have third party libraries perform the FFTs instead, but
> under the
> >>>>>>>>>> existing scipy.fftpack API. This is motivated by a desire by
> end users and
> >>>>>>>>>> downstream projects to have features such as multi-threading
> (pyFFTW and
> >>>>>>>>>> mkl-fft) or GPU support (CuPy) that are not implemented in
> scipy.fftpack.
> >>>>>>>>>> Ultimately it will be up to users that opt-in to using these
> other
> >>>>>>>>>> libraries to confirm that the license terms and are compatible
> with their
> >>>>>>>>>> use case.
> >>>>>>>>>>
> >>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev mailing
> >>>>>>>>>> lists prefers replies **below** the email you are replying to
> so people can
> >>>>>>>>>> more easily follow the thread of discussion. There are some
> guidelines at:
> >>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I will research more about how to implement a backend myself and
> >>>>>>>>>>> will let you know as soon as I come up with something new.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> CHeers,
> >>>>>>>>>>> Greg
> >>>>>>>>>>>
> >>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <grlee77 at gmail.com
> >
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
> >>>>>>>>>>>> deathcoderx at gmail.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started fixing some
> >>>>>>>>>>>>> bugs, also made some pull request. Can anyone suggest me how
> should I
> >>>>>>>>>>>>> proceed further?
> >>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>> SciPy-Dev mailing list
> >>>>>>>>>>>>> SciPy-Dev at python.org
> >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Gopi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think you have probably already found it, but the GSOC
> >>>>>>>>>>>> project we have already identified mentors for in SciPy is
> here:
> >>>>>>>>>>>> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
> >>>>>>>>>>>>
> >>>>>>>>>>>> If this is a project you are interested in then I would start
> >>>>>>>>>>>> thinking about what the FFT interface would look like and
> reviewing some of
> >>>>>>>>>>>> the past/present issues related to fftpack / FFT in SciPy.
> Please ask
> >>>>>>>>>>>> questions you have related to that project here so that you
> can clarify
> >>>>>>>>>>>> what would be involved in writing a successful application.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If you have a different idea in mind you can propose it here,
> >>>>>>>>>>>> but you should do that soon, because it will be necessary to
> determine if
> >>>>>>>>>>>> there is interest from the SciPy team before you spend time
> coming up with
> >>>>>>>>>>>> a detailed proposal. We have to determine if a project sounds
> feasible to
> >>>>>>>>>>>> complete for GSOC and if appropriate mentors can be
> identified.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ultimately, you will need to submit an application to SciPy
> >>>>>>>>>>>> between March 25th - April 9th.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Cheers,
> >>>>>>>>>>>> Greg
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>> SciPy-Dev mailing list
> >>>>>>>>>>>> SciPy-Dev at python.org
> >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >>>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> SciPy-Dev mailing list
> >>>>>>>>>>> SciPy-Dev at python.org
> >>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >>>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> SciPy-Dev mailing list
> >>>>>>>>>> SciPy-Dev at python.org
> >>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >>>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> SciPy-Dev mailing list
> >>>>>>>>> SciPy-Dev at python.org
> >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> SciPy-Dev mailing list
> >>>>>>>> SciPy-Dev at python.org
> >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> SciPy-Dev mailing list
> >>>>>>> SciPy-Dev at python.org
> >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> SciPy-Dev mailing list
> >>>>>> SciPy-Dev at python.org
> >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >>>>>>
> >>>>> _______________________________________________
> >>>>> SciPy-Dev mailing list
> >>>>> SciPy-Dev at python.org
> >>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >>>>>
> >>>> _______________________________________________
> >>>> SciPy-Dev mailing list
> >>>> SciPy-Dev at python.org
> >>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >>>>
> >>> _______________________________________________
> >>> SciPy-Dev mailing list
> >>> SciPy-Dev at python.org
> >>> https://mail.python.org/mailman/listinfo/scipy-dev
> >>>
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at python.org
> >> https://mail.python.org/mailman/listinfo/scipy-dev
> >>
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at python.org
> > https://mail.python.org/mailman/listinfo/scipy-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/54f38250/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
>
> ------------------------------
>
> End of SciPy-Dev Digest, Vol 185, Issue 18
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190402/e1f35f09/attachment-0001.html>

From peterbell10 at live.co.uk  Wed Apr  3 10:05:33 2019
From: peterbell10 at live.co.uk (Peter Bell)
Date: Wed, 3 Apr 2019 14:05:33 +0000
Subject: [SciPy-Dev] GSoC 2019 Projects
Message-ID: <DB6PR04MB32069A19ECEABBA9433E85158E570@DB6PR04MB3206.eurprd04.prod.outlook.com>

Hello,

I am interested in applying for Google summer of code and was wondering if you
are still looking for students?

A bit about myself
-------------------
My name is Peter and I'm in my 4th (penultimate) year of an integrated masters
in computational physics. Programming and numerical methods forms a key part of
this degree and many of my courses make heavy use of python with cython, numpy,
scipy, matplotlib, etc. While my degree is primarily Physics, I have taken a
number of computer science courses covering software engineering, object
oriented design and high performance programming.

I also have an interest in open source collaboration and, when time has allowed,
have contributed to a few projects via github (@peterbell10). The majority of
my contributions have been to a minecraft server which I've been contributing to
since summer 2017. You can see my pull requests here:
https://github.com/cuberite/cuberite/pulls?q=is%3Apr+is%3Amerged+author%3Apeterbell10

Questions about the projects
-----------------------------
I have some questions regarding both of the proposed projects.

Revamp fftpack:
* Is the primary intention to keep the scipy.fftpack interface the same, but add
  some mechanism to inject custom implementations? Or will this require changes
  to the front-facing interface as well? (e.g. for agreement with numpy.fft)
* What should this look like from the user's point of view? e.g.

       import scipy.fftpack
       import pyFFTW.interfaces.scipy_fftpack as fftw_pack

       scipy.fftpack.set_backend(fftw_pack)

  where we just provide a module implementing a well-documented backend
  interface. Alternatively, fftw_pack could be an object, potentially with
  its own instances of caches and settings which might allow for more
  configuration from the user.

Improve ODE solvers (mainly the first 3 tasks):
* How much mathematical background is required? I have done a course covering
  the mathematics of ODE schemes including RK methods and some variable timestep
  methods, but am not familiar with control theory which is mentioned for the
  3rd task.
* Will developing the test set just involve binding existing implementations to
  python for use in a testing framework, or do you expect these to be rewritten
  entirely in python or cython?


Best regards,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190403/340a31bb/attachment.html>

From christoph.baumgarten at gmail.com  Wed Apr  3 15:12:14 2019
From: christoph.baumgarten at gmail.com (Christoph Baumgarten)
Date: Wed, 3 Apr 2019 21:12:14 +0200
Subject: [SciPy-Dev] Google Season of Docs
In-Reply-To: <mailman.11.1554220802.22439.scipy-dev@python.org>
References: <mailman.11.1554220802.22439.scipy-dev@python.org>
Message-ID: <CABXY2qDxUsnWZWmptmOK4X+rrd7v04hULK95DMcVy2mPWAgi+Q@mail.gmail.com>

Sure, I will add it in the next few days.

On Tue, Apr 2, 2019 at 6:02 PM <scipy-dev-request at python.org> wrote:

> Send SciPy-Dev mailing list submissions to
>         scipy-dev at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.python.org/mailman/listinfo/scipy-dev
> or, via email, send a message with subject or body 'help' to
>         scipy-dev-request at python.org
>
> You can reach the person managing the list at
>         scipy-dev-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SciPy-Dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Google Season of Docs (Ralf Gommers)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 2 Apr 2019 10:40:20 +0200
> From: Ralf Gommers <ralf.gommers at gmail.com>
> To: SciPy Developers List <scipy-dev at python.org>
> Subject: Re: [SciPy-Dev] Google Season of Docs
> Message-ID:
>         <CABL7CQipvttnWrAE=
> V6Fr+iJKjGM1x0wgKbK-ea7ZNsOXx6YDg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, Mar 22, 2019 at 8:07 PM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
> >
> >
> > On Thu, Mar 21, 2019 at 12:10 PM Christoph Baumgarten <
> > christoph.baumgarten at gmail.com> wrote:
> >
> >>
> >> Hi,
> >>
> >> taking up Ralf's mail on GSoD, I had a look at the website and propose
> to
> >> apply.
> >>
> >> My project suggestion would be to work on the documentation of a module
> >> like stats:
> >>
> >
> >> - improve the tutorial site
> >> https://docs.scipy.org/doc/scipy/reference/tutorial/stats.html
> >> - improve the documentation of the API
> >>   - check whether current descriptions can be improved
> >>   - add examples and references
> >>   - cross-ref to other relevant / similar functions in the module
> >>
> >> The second point would require decent knowledge of statistics whereas
> the
> >> first point should be easier to tackle for a technical writer. So I see
> the
> >> second point as optional and one could also try to work on the tutorial
> >> site of more than one module during the 3-month period.
> >>
> >
> >> The task would leave quite a bit of freedom to the writer to choose what
> >> areas to focus on, potentially taking up some of the documentation
> issues
> >> that are already on Github.
> >>
> >> I could assist as a mentor for stats (we need at least two mentors).
> >>
> >> Any suggestions or comments?
> >>
> >
> > Thanks Christoph, this sounds like a good idea to me. We have a lot of
> > content on scipy.stats, and a tech writer could really make a difference
> in
> > making that easier to understand for users. I suggest we write this up as
> > an idea on our (to be created) ideas page as soon as we know whether we
> > have an umbrella organization that we can participate with.
> >
>
>  An update on this: NumFOCUS is applying as an umbrella org. We'll need to
> add our ideas at
> https://github.com/numfocus/gsod/blob/master/2019/SciPy_ideas_list.md.
> Since there are going to be few spots available, it's the quality of the
> content that matters for acceptance of NumFOCUS as an umbrella org. We
> should have 1-2 ideas that are well described up on that page by April
> 14th. There are some guidelines at
>
> https://developers.google.com/season-of-docs/docs/project-ideas#project-idea
>
> Christoph, could you add your idea in that SciPy_ideas_list.md file?
>
> I will add some more general information there about getting started on the
> SciPy docs. Also, if anyone has another idea, that would be great to hear.
>
> Cheers,
> Ralf
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/scipy-dev/attachments/20190402/244fdd76/attachment-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
>
> ------------------------------
>
> End of SciPy-Dev Digest, Vol 186, Issue 6
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190403/bcb13739/attachment.html>

From p.vanmulbregt at comcast.net  Wed Apr  3 17:40:09 2019
From: p.vanmulbregt at comcast.net (Paul van Mulbregt)
Date: Wed, 3 Apr 2019 17:40:09 -0400
Subject: [SciPy-Dev] Google Season of Docs
In-Reply-To: <CABXY2qDxUsnWZWmptmOK4X+rrd7v04hULK95DMcVy2mPWAgi+Q@mail.gmail.com>
References: <mailman.11.1554220802.22439.scipy-dev@python.org>
 <CABXY2qDxUsnWZWmptmOK4X+rrd7v04hULK95DMcVy2mPWAgi+Q@mail.gmail.com>
Message-ID: <30814876-3E04-40AD-AF43-FA63323C8DC6@comcast.net>

I can be a second mentor for the stats documentation proposal.

-Paul

> On Apr 3, 2019, at 3:12 PM, Christoph Baumgarten <christoph.baumgarten at gmail.com> wrote:
> 
> 
> Sure, I will add it in the next few days.
> 
>> On Tue, Apr 2, 2019 at 6:02 PM <scipy-dev-request at python.org> wrote:
>> Send SciPy-Dev mailing list submissions to
>>         scipy-dev at python.org
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://mail.python.org/mailman/listinfo/scipy-dev
>> or, via email, send a message with subject or body 'help' to
>>         scipy-dev-request at python.org
>> 
>> You can reach the person managing the list at
>>         scipy-dev-owner at python.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of SciPy-Dev digest..."
>> 
>> 
>> Today's Topics:
>> 
>>    1. Re: Google Season of Docs (Ralf Gommers)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Tue, 2 Apr 2019 10:40:20 +0200
>> From: Ralf Gommers <ralf.gommers at gmail.com>
>> To: SciPy Developers List <scipy-dev at python.org>
>> Subject: Re: [SciPy-Dev] Google Season of Docs
>> Message-ID:
>>         <CABL7CQipvttnWrAE=V6Fr+iJKjGM1x0wgKbK-ea7ZNsOXx6YDg at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> On Fri, Mar 22, 2019 at 8:07 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:
>> 
>> >
>> >
>> > On Thu, Mar 21, 2019 at 12:10 PM Christoph Baumgarten <
>> > christoph.baumgarten at gmail.com> wrote:
>> >
>> >>
>> >> Hi,
>> >>
>> >> taking up Ralf's mail on GSoD, I had a look at the website and propose to
>> >> apply.
>> >>
>> >> My project suggestion would be to work on the documentation of a module
>> >> like stats:
>> >>
>> >
>> >> - improve the tutorial site
>> >> https://docs.scipy.org/doc/scipy/reference/tutorial/stats.html
>> >> - improve the documentation of the API
>> >>   - check whether current descriptions can be improved
>> >>   - add examples and references
>> >>   - cross-ref to other relevant / similar functions in the module
>> >>
>> >> The second point would require decent knowledge of statistics whereas the
>> >> first point should be easier to tackle for a technical writer. So I see the
>> >> second point as optional and one could also try to work on the tutorial
>> >> site of more than one module during the 3-month period.
>> >>
>> >
>> >> The task would leave quite a bit of freedom to the writer to choose what
>> >> areas to focus on, potentially taking up some of the documentation issues
>> >> that are already on Github.
>> >>
>> >> I could assist as a mentor for stats (we need at least two mentors).
>> >>
>> >> Any suggestions or comments?
>> >>
>> >
>> > Thanks Christoph, this sounds like a good idea to me. We have a lot of
>> > content on scipy.stats, and a tech writer could really make a difference in
>> > making that easier to understand for users. I suggest we write this up as
>> > an idea on our (to be created) ideas page as soon as we know whether we
>> > have an umbrella organization that we can participate with.
>> >
>> 
>>  An update on this: NumFOCUS is applying as an umbrella org. We'll need to
>> add our ideas at
>> https://github.com/numfocus/gsod/blob/master/2019/SciPy_ideas_list.md.
>> Since there are going to be few spots available, it's the quality of the
>> content that matters for acceptance of NumFOCUS as an umbrella org. We
>> should have 1-2 ideas that are well described up on that page by April
>> 14th. There are some guidelines at
>> https://developers.google.com/season-of-docs/docs/project-ideas#project-idea
>> 
>> Christoph, could you add your idea in that SciPy_ideas_list.md file?
>> 
>> I will add some more general information there about getting started on the
>> SciPy docs. Also, if anyone has another idea, that would be great to hear.
>> 
>> Cheers,
>> Ralf
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190402/244fdd76/attachment-0001.html>
>> 
>> ------------------------------
>> 
>> Subject: Digest Footer
>> 
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>> 
>> 
>> ------------------------------
>> 
>> End of SciPy-Dev Digest, Vol 186, Issue 6
>> *****************************************
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190403/1a6d83c7/attachment-0001.html>

From ralf.gommers at gmail.com  Thu Apr  4 07:26:40 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 4 Apr 2019 13:26:40 +0200
Subject: [SciPy-Dev] Google Season of Docs
In-Reply-To: <30814876-3E04-40AD-AF43-FA63323C8DC6@comcast.net>
References: <mailman.11.1554220802.22439.scipy-dev@python.org>
 <CABXY2qDxUsnWZWmptmOK4X+rrd7v04hULK95DMcVy2mPWAgi+Q@mail.gmail.com>
 <30814876-3E04-40AD-AF43-FA63323C8DC6@comcast.net>
Message-ID: <CABL7CQg5Qyjb=xf_JMmAOvLamd330m47E1Y356-cLfj99TOXKA@mail.gmail.com>

On Wed, Apr 3, 2019 at 11:49 PM Paul van Mulbregt <p.vanmulbregt at comcast.net>
wrote:

> I can be a second mentor for the stats documentation proposal.
>

Great, thanks Paul!


> -Paul
>
> On Apr 3, 2019, at 3:12 PM, Christoph Baumgarten <
> christoph.baumgarten at gmail.com> wrote:
>
>
> Sure, I will add it in the next few days.
>
> On Tue, Apr 2, 2019 at 6:02 PM <scipy-dev-request at python.org> wrote:
>
>> Send SciPy-Dev mailing list submissions to
>>         scipy-dev at python.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://mail.python.org/mailman/listinfo/scipy-dev
>> or, via email, send a message with subject or body 'help' to
>>         scipy-dev-request at python.org
>>
>> You can reach the person managing the list at
>>         scipy-dev-owner at python.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of SciPy-Dev digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Google Season of Docs (Ralf Gommers)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 2 Apr 2019 10:40:20 +0200
>> From: Ralf Gommers <ralf.gommers at gmail.com>
>> To: SciPy Developers List <scipy-dev at python.org>
>> Subject: Re: [SciPy-Dev] Google Season of Docs
>> Message-ID:
>>         <CABL7CQipvttnWrAE=
>> V6Fr+iJKjGM1x0wgKbK-ea7ZNsOXx6YDg at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Fri, Mar 22, 2019 at 8:07 PM Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>> >
>> >
>> > On Thu, Mar 21, 2019 at 12:10 PM Christoph Baumgarten <
>> > christoph.baumgarten at gmail.com> wrote:
>> >
>> >>
>> >> Hi,
>> >>
>> >> taking up Ralf's mail on GSoD, I had a look at the website and propose
>> to
>> >> apply.
>> >>
>> >> My project suggestion would be to work on the documentation of a module
>> >> like stats:
>> >>
>> >
>> >> - improve the tutorial site
>> >> https://docs.scipy.org/doc/scipy/reference/tutorial/stats.html
>> >> - improve the documentation of the API
>> >>   - check whether current descriptions can be improved
>> >>   - add examples and references
>> >>   - cross-ref to other relevant / similar functions in the module
>> >>
>> >> The second point would require decent knowledge of statistics whereas
>> the
>> >> first point should be easier to tackle for a technical writer. So I
>> see the
>> >> second point as optional and one could also try to work on the tutorial
>> >> site of more than one module during the 3-month period.
>> >>
>> >
>> >> The task would leave quite a bit of freedom to the writer to choose
>> what
>> >> areas to focus on, potentially taking up some of the documentation
>> issues
>> >> that are already on Github.
>> >>
>> >> I could assist as a mentor for stats (we need at least two mentors).
>> >>
>> >> Any suggestions or comments?
>> >>
>> >
>> > Thanks Christoph, this sounds like a good idea to me. We have a lot of
>> > content on scipy.stats, and a tech writer could really make a
>> difference in
>> > making that easier to understand for users. I suggest we write this up
>> as
>> > an idea on our (to be created) ideas page as soon as we know whether we
>> > have an umbrella organization that we can participate with.
>> >
>>
>>  An update on this: NumFOCUS is applying as an umbrella org. We'll need to
>> add our ideas at
>> https://github.com/numfocus/gsod/blob/master/2019/SciPy_ideas_list.md.
>> Since there are going to be few spots available, it's the quality of the
>> content that matters for acceptance of NumFOCUS as an umbrella org. We
>> should have 1-2 ideas that are well described up on that page by April
>> 14th. There are some guidelines at
>>
>> https://developers.google.com/season-of-docs/docs/project-ideas#project-idea
>>
>> Christoph, could you add your idea in that SciPy_ideas_list.md file?
>>
>> I will add some more general information there about getting started on
>> the
>> SciPy docs. Also, if anyone has another idea, that would be great to hear.
>>
>> Cheers,
>> Ralf
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190402/244fdd76/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>>
>> ------------------------------
>>
>> End of SciPy-Dev Digest, Vol 186, Issue 6
>> *****************************************
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190404/8005557c/attachment.html>

From grlee77 at gmail.com  Thu Apr  4 10:42:04 2019
From: grlee77 at gmail.com (Gregory Lee)
Date: Thu, 4 Apr 2019 10:42:04 -0400
Subject: [SciPy-Dev] GSoC 2019 Projects
In-Reply-To: <DB6PR04MB32069A19ECEABBA9433E85158E570@DB6PR04MB3206.eurprd04.prod.outlook.com>
References: <DB6PR04MB32069A19ECEABBA9433E85158E570@DB6PR04MB3206.eurprd04.prod.outlook.com>
Message-ID: <CAJR3sXcsQATgJ952UK+Bigqf-L8EVL0hS=XMWahNyZKHVhcs0Q@mail.gmail.com>

Hi Peter,

Yes, the application period is still open for GSOC, although the final
deadline is the 9th, so time is becoming fairly short to get feedback on
proposals.

A few other students have expressed interest in the FFT-based backends, but
any interested candidates are welcome to apply. Please see some prior posts
on this lists for some discussions related to that project. The primary
intention is to allow 3rd party implementations to override the ones
provided by SciPy when requested. Ideally there should also be some way to
provide additional arguments specific to those implementations (e.g.
specifying number of threads, planner effort, etc in the case of PyFFTW).
We do not want any breaking changes to the existing scipy.fftpack
interfaces as we need to maintain backwards compatibility with a lot of
preexisting code in downstream libraries. Ideally downstream libraries
should be able to benefit from the changes made in SciPy without any
substantial refactoring on their end.

I am not personally familiar with the specifics of the ODE project and do
not know if other candidates are currently pursuing that topic. Hopefully
one of the mentors for it can respond here.

- Greg




On Wed, Apr 3, 2019 at 10:05 AM Peter Bell <peterbell10 at live.co.uk> wrote:

> Hello,
>
>
>
> I am interested in applying for Google summer of code and was wondering if
> you
>
> are still looking for students?
>
>
>
> A bit about myself
>
> -------------------
>
> My name is Peter and I'm in my 4th (penultimate) year of an integrated
> masters
>
> in computational physics. Programming and numerical methods forms a key
> part of
>
> this degree and many of my courses make heavy use of python with cython,
> numpy,
>
> scipy, matplotlib, etc. While my degree is primarily Physics, I have taken
> a
>
> number of computer science courses covering software engineering, object
>
> oriented design and high performance programming.
>
>
>
> I also have an interest in open source collaboration and, when time has
> allowed,
>
> have contributed to a few projects via github (@peterbell10). The majority
> of
>
> my contributions have been to a minecraft server which I've been
> contributing to
>
> since summer 2017. You can see my pull requests here:
>
>
> https://github.com/cuberite/cuberite/pulls?q=is%3Apr+is%3Amerged+author%3Apeterbell10
>
>
>
> Questions about the projects
>
> -----------------------------
>
> I have some questions regarding both of the proposed projects.
>
>
>
> Revamp fftpack:
>
> * Is the primary intention to keep the scipy.fftpack interface the same,
> but add
>
>   some mechanism to inject custom implementations? Or will this require
> changes
>
>   to the front-facing interface as well? (e.g. for agreement with
> numpy.fft)
>
> * What should this look like from the user's point of view? e.g.
>
>
>
>        import scipy.fftpack
>
>        import pyFFTW.interfaces.scipy_fftpack as fftw_pack
>
>
>
>        scipy.fftpack.set_backend(fftw_pack)
>
>
>
>   where we just provide a module implementing a well-documented backend
>
>   interface. Alternatively, fftw_pack could be an object, potentially with
>
>   its own instances of caches and settings which might allow for more
>
>   configuration from the user.
>
>
>
> Improve ODE solvers (mainly the first 3 tasks):
>
> * How much mathematical background is required? I have done a course
> covering
>
>   the mathematics of ODE schemes including RK methods and some variable
> timestep
>
>   methods, but am not familiar with control theory which is mentioned for
> the
>
>   3rd task.
>
> * Will developing the test set just involve binding existing
> implementations to
>
>   python for use in a testing framework, or do you expect these to be
> rewritten
>
>   entirely in python or cython?
>
>
>
>
>
> Best regards,
>
> Peter
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190404/484e79ff/attachment-0001.html>

From grlee77 at gmail.com  Thu Apr  4 10:58:27 2019
From: grlee77 at gmail.com (Gregory Lee)
Date: Thu, 4 Apr 2019 10:58:27 -0400
Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 185, Issue 18
In-Reply-To: <CAG7Qgjhq8fFwGY2vy2CpkbUyymXKu-KrFouzpSuJs2ZqEcCRrg@mail.gmail.com>
References: <mailman.99.1553989995.2938.scipy-dev@python.org>
 <CAG7Qgjhq8fFwGY2vy2CpkbUyymXKu-KrFouzpSuJs2ZqEcCRrg@mail.gmail.com>
Message-ID: <CAJR3sXcJuqQJrDboN5zH-pd7NG-wD8EWCdTCAtQ+vJpnZjKsRw@mail.gmail.com>

Hi Anany,

It is nice to see that you have updated with multiple potential APIs. Can
some other core SciPy devs also help give feedback on what SciPy would find
preferable? Out of the four you proposed, I think something along the lines
of the second method is cleanest in terms of setting the backend at
runtime. I think having some aspect from your 4th variant where the default
backend can be read from a configuration file and/or environment variable
is also desirable so that the user's desired default can always be
automatically set at import time.

I disagree with the following specific statement, though:
"It is better to use all the above mentioned ideas because every idea has
its own benefits besides it gives user the luxury to choose the method
implementation of backend."

I do not think we want to provide multiple ways to do the same thing. It
can be confusing to users and more work for devs to maintain. I think there
should be one method of setting the backend that the user can either call
at run time or have it be automatically called based on some sort of
configuration file and/or environment variable(s) at import time.

- Greg


On Tue, Apr 2, 2019 at 2:19 PM Anany Shrey Jain <
f20170920 at goa.bits-pilani.ac.in> wrote:

> Hey,
> I have already sent the link to the page containing the list of ideas for
> implementation of new API that I propose for this project. Would you like
> to add something to it or give some comments on it? The Gsoc proposal
> deadline is 9th of April and I am planning to put all of this in my
> proposal to make it effective . So any more ideas or comments will be
> really helpful for me . Here is the link to the page:
> https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy .
>
> On Sun, Mar 31, 2019 at 5:23 AM <scipy-dev-request at python.org> wrote:
>
>>
>> Message: 1
>> Date: Sat, 30 Mar 2019 13:31:51 -0400
>> From: Eric Larson <larson.eric.d at gmail.com>
>> To: SciPy Developers List <scipy-dev at python.org>
>> Subject: Re: [SciPy-Dev] GSoC 2019
>> Message-ID:
>>         <
>> CAGu2niVWsKrMukfWcAWAtj-1NBm2utCeh3BOnNku7jNoAcx-kw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> It looks like the main ideas are in these bits of code, but not explicitly
>> stated. In brief it looks like the proposed API is to add a `fft_object`
>> kwarg to every function in `scipy.fftpack`. It would be good to discuss
>> this choice explicitly -- what advantages and disadvantages it has
>> relative
>> to other approaches (e.g., creating new namespaces, or having a
>> `set_backend` function (and/or context manager) that would change things
>> under the hood).
>>
>> If you make changes and need more feedback, let us know. The more specific
>> you can be about what you need feedback on (high level ideas, low level
>> implementation, etc.), the better.
>>
>> Eric
>>
>>
>> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
>> f20170920 at goa.bits-pilani.ac.in> wrote:
>>
>> > Hey,
>> > I went through the idea list of Scipy for this years's GSoC and I intend
>> > to work towards the idea of revamping the Scipy's fftpack. I have
>> already
>> > been contributing to Scipy since the end of last year and I have some
>> > knowledge about Fourier transforms as it was the part of my discipline.
>> I
>> > could not take part in this discussion earlier because my mid semester
>> > exams were going on, but since they are now over so I can devote as much
>> > time as required on this project. I have already created a github page
>> with
>> > some code snippets and functionalities that we can implement, here is
>> the
>> > link to it:
>> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy .
>> >
>> > Cheers,
>> > Anany Jain
>> >
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/f1755dfb/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 30 Mar 2019 19:38:41 -0400
>> From: Gregory Lee <grlee77 at gmail.com>
>> To: SciPy Developers List <scipy-dev at python.org>
>> Subject: Re: [SciPy-Dev] GSoC 2019
>> Message-ID:
>>         <CAJR3sXfnnr-0JO87gLbhh-7b-w=KjaNpac+F+FHTeFt2K=_
>> QMw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
>> f20170920 at goa.bits-pilani.ac.in> wrote:
>>
>> > Hey,
>> > I went through the idea list of Scipy for this years's GSoC and I intend
>> > to work towards the idea of revamping the Scipy's fftpack. I have
>> already
>> > been contributing to Scipy since the end of last year and I have some
>> > knowledge about Fourier transforms as it was the part of my discipline.
>> I
>> > could not take part in this discussion earlier because my mid semester
>> > exams were going on, but since they are now over so I can devote as much
>> > time as required on this project. I have already created a github page
>> with
>> > some code snippets and functionalities that we can implement, here is
>> the
>> > link to it:
>> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy .
>> >
>> > Cheers,
>> > Anany Jain
>> >
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/scipy-dev
>>
>>
>> Hi Anany,
>>
>> Thank you for your interest in GSOC with SciPy!  It's great to see that
>> you
>> are already thinking about a potential API and learning about the 3rd
>> party
>> FFT libraries. Along the lines of Eric's comment, think about what this
>> API
>> choice implies for users of libraries built upon SciPy. Would users of 3rd
>> party libraries that rely on SciPy's FFTs be immediately able to take
>> advantage of a differentf FFT backend in this scenario? (in other words,
>> the case where the user is not calling scipy.fftpack.fft directly but is
>> using it only indirectly via a function in a downstream library).
>>
>> Matplotlib is an example of an existing Python library supporting multiple
>> backends that can be considered for comparison (see:
>> https://matplotlib.org/faq/usage_faq.html#what-is-a-backend). Think about
>> the relative benefits/drawbacks of some of the methods they use for
>> setting
>> a backend there as compared to the approach proposed for FFTs here.
>>
>> Another thing that should be considered: pyFFTW, MKL and CuPy already have
>> some functions that match the existing scipy.fftpack API, but they may
>> have
>> one or more additional arguments particular to features of that library.
>> How would you propose to deal with supporting additional optional
>> arguments
>> on the SciPy end?
>>
>> One other minor comment: I know that the blog post you made may be serving
>> partly as personal notes, but please do not directly copy sections of text
>> (e.g. the description of BLAS/LAPACK libraries) from elsewhere without
>> attribution when writing a final proposal. (Also, the FFT functions are
>> separate from the BLAS/LAPACK functions in MKL, so you will not need to
>> discuss BLAS or LAPACK specifically in your proposal)
>>
>> - Greg
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/c1351e7e/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Sat, 30 Mar 2019 19:53:02 -0400
>> From: Gregory Lee <grlee77 at gmail.com>
>> To: SciPy Developers List <scipy-dev at python.org>
>> Subject: Re: [SciPy-Dev] GSoC 2019
>> Message-ID:
>>         <CAJR3sXdcPMAn_DETF8W-=
>> MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi Gopi,
>>
>> I am not sure I follow exactly what you are suggesting here. Are you
>> proposing that the `fftpackN` variable in your example would be a Python
>> module corresponding to a given backend? If so, why is an array of data,
>> z,
>> being passed into the newAPI function here? I don't see why a data array
>> should be needed at all to choose a backend.
>>
>> Please also see my response to Anany's recent post on this list for a
>> couple of other suggestions of things to consider in terms of the API.
>>
>> - Greg
>>
>>
>> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
>> deathcoderx at gmail.com>
>> wrote:
>>
>> > Hey,
>> > I went through the code and got some ideas.
>> > So what will happen is:
>> > First, we will declare FFTW as we use them normally.
>> >
>> > z = np.random.rand(2, 128, 64)
>> > pyfftw.FFTW(z, axes=(-1, ))
>> > ..
>> > ..
>> > Now after declaring our basic work to shift to another FFTpack, what we
>> > can do is:
>> > fftPackN= newAPI(z, pack = 'PYFFTW');
>> >
>> > Pack will take the name of the 3rd party FFT pack which we want to use.
>> > Suggestions needed.
>> >
>> > Cheers.
>> >
>> >
>>
>> >
>> > On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <larson.eric.d at gmail.com>
>> > wrote:
>> >
>> >> After reading the related issues and thinking about the problem,
>> perhaps
>> >> the best first step is you come up with some initial API proposal.
>> >>
>> >> One way to work through the process is to think about the use cases
>> that
>> >> we want to support. How should users actually write code to use the new
>> >> functionality? You can start with short code snippets that do not work
>> >> currently, but should work for users at the end of the project. Then
>> think
>> >> about what needs to change inside SciPy for these code snippets to
>> work.
>> >> This can become an iterative process as you realize that the SciPy
>> changes
>> >> might be better or easier with changes to the user-facing API, etc.
>> >>
>> >> Eric
>> >>
>> >>
>> >> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
>> >> deathcoderx at gmail.com> wrote:
>> >>
>> >>> Hey,
>> >>> As proposal submission period started I want to discuss a bit anobt
>> how
>> >>> can we implement the API.
>> >>> I would very much appriciate inputs and guidance.
>> >>>
>> >>> Cheers.
>> >>>
>> >>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <larson.eric.d at gmail.com>
>> >>> wrote:
>> >>>
>> >>>> The best way to figure that out is probably to take a look at some of
>> >>>> the existing (minor) SciPy GitHub issues and try to work on one or
>> two that
>> >>>> you feel like working on. Actually trying to work out how to
>> contribute
>> >>>> code changes (as independently as possible/reasonable based on the
>> existing
>> >>>> guides/docs already discoverable online) will quickly highlight
>> things that
>> >>>> need to be learned. Some of the general things are the SciPy
>> contributing
>> >>>> guidelines, standard GitHub PR workflow, communication with
>> reviewers, and
>> >>>> so forth.
>> >>>>
>> >>>> For this particular project, it's important to understand the various
>> >>>> flavors and properties of FFT in SciPy (real, complex, n-dimensional,
>> >>>> caching plans, etc.) as well as other projects like NumPy, CuPy, and
>> >>>> pyFFTW. Some of this can be learned and improved upon as part of
>> GSoC, but
>> >>>> the more you know and can demonstrate / put into practice knowledge
>> of
>> >>>> before the applications are reviewed, the better.
>> >>>>
>> >>>> Eric
>> >>>>
>> >>>>
>> >>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
>> >>>> deathcoderx at gmail.com> wrote:
>> >>>>
>> >>>>> Thank you for the detailed reply.
>> >>>>> I will keep these point in mind while preparing my proposal. Apart
>> >>>>> from proposal, what skills shall I improve so that I can contribute
>> more
>> >>>>> effectively and efficiently.
>> >>>>>
>> >>>>> Cheers.
>> >>>>>
>> >>>>>
>> >>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <larson.eric.d at gmail.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> There are a number of considerations that would be good to address.
>> >>>>>> I'd start by considering the things that are typically considered
>> >>>>>> when making changes to SciPy
>> >>>>>> <
>> https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy
>> >,
>> >>>>>> but I'd expand it to a longer list since the scope is bigger than
>> a typical
>> >>>>>> single PR. The list would contain (at least):
>> >>>>>>
>> >>>>>> - what will the user-facing API / contract be?
>> >>>>>> - what in SciPy needs to change to allow it (internals /
>> >>>>>> implementation outline, perhaps skeleton functions/classes)?
>> >>>>>> - what examples should we show users (in general this ends up being
>> >>>>>> just simple use cases of the API)?
>> >>>>>> - how will we test it for correctness?
>> >>>>>> - how will we benchmark it to prevent performance regressions?
>> >>>>>> - how can we break up the work for these steps (if possible) into
>> >>>>>> separable, sequential (or -- better but not usually possible --
>> >>>>>> independent) PRs?
>> >>>>>>
>> >>>>>> You might notice that none of these points are actually all that
>> >>>>>> specific to the FFT project, but can be generally applicable to
>> GSoC
>> >>>>>> projects. For the FFT project, I would say "how do we build the
>> backend" is
>> >>>>>> indeed implicitly contained / outlined in these bullet points. And
>> as with
>> >>>>>> most projects, the first two points (and possibly the last) will
>> probably
>> >>>>>> be the most challenging to sort out.
>> >>>>>>
>> >>>>>> Eric
>> >>>>>>
>> >>>>>>
>> >>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
>> >>>>>> deathcoderx at gmail.com> wrote:
>> >>>>>>
>> >>>>>>> Hey Eric,
>> >>>>>>> So for my proposal, shall I include how can we built a back end?
>> >>>>>>> What all points shall I include to make it effective?
>> >>>>>>>
>> >>>>>>> Cheers.
>> >>>>>>>
>> >>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <larson.eric.d at gmail.com
>> >
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> That would be me -- don't worry, I'm on this list, as are
>> >>>>>>>> (presumably) other developers interested in the discussion, so
>> no need to
>> >>>>>>>> document elsewhere for now from our end. It looks like Greg has
>> summarized
>> >>>>>>>> the current status and thoughts we've had, so I don't have much
>> to add at
>> >>>>>>>> this point.
>> >>>>>>>>
>> >>>>>>>> Eric
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
>> >>>>>>>> deathcoderx at gmail.com> wrote:
>> >>>>>>>>
>> >>>>>>>>> Hey Greg,
>> >>>>>>>>> I got the basic idea about what we want to implement this year.
>> >>>>>>>>> Our first priority is to create a backend for 3rd party
>> fftpacks.
>> >>>>>>>>> We can create API using Python and Flask or any other suitable
>> framework.
>> >>>>>>>>>
>> >>>>>>>>> I thought this discussion was going on on SciPy Developer List
>> >>>>>>>>> only. So do I need to document it all and post it somewhere so
>> that other
>> >>>>>>>>> contributors can see this?
>> >>>>>>>>> Also, I couldn't find any contact info regarding Eric. It would
>> be
>> >>>>>>>>> very helpful if we include him in this discussion as this is a
>> roadmap for
>> >>>>>>>>> GSoC project and I can also get more insight into the project
>> and expected
>> >>>>>>>>> outcomes.
>> >>>>>>>>>
>> >>>>>>>>> Cheers.
>> >>>>>>>>>
>> >>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <grlee77 at gmail.com>
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
>> >>>>>>>>>> deathcoderx at gmail.com> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> Hey Gregory,
>> >>>>>>>>>>> I went through the idea and I am very much interested in
>> working
>> >>>>>>>>>>> on it. I had Fourier Transforms as a part of my academic
>> course, so I am
>> >>>>>>>>>>> well aware with basic concepts.
>> >>>>>>>>>>> One thing I want to discuss is, its mentioned that we have to
>> >>>>>>>>>>> create a backend system for 3rd party FFTpacks so my dobuts
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> 1. How are we going to create API?
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> This will needed to be decided on in consensus with the SciPy
>> >>>>>>>>>> developers and user community. I am mentoring for the project
>> as a
>> >>>>>>>>>> contributor here and a maintainer of the related pyFFTW
>> package, but I am
>> >>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core dev
>> here). I have
>> >>>>>>>>>> not discussed the API in any detail with the SciPy team at
>> this stage.
>> >>>>>>>>>> Working out details of what the API should look like and
>> working to
>> >>>>>>>>>> finalize that in collaboration with the community will be a
>> primary task
>> >>>>>>>>>> during the early part of the GSOC project.
>> >>>>>>>>>>
>> >>>>>>>>>> 2. After the creation of backend will user at the time of
>> >>>>>>>>>>> installation of SciPy will decide what all 3rd party FFTpacks
>> he needs or
>> >>>>>>>>>>> we will include some by default?
>> >>>>>>>>>>>
>> >>>>>>>>>>> The idea is to allow users to opt-in to a different FFT
>> backend
>> >>>>>>>>>> at run time, but these alternative libraries will not be
>> distributed with
>> >>>>>>>>>> SciPy itself due to incompatible software licenses (pyFFTW and
>> mkl-fft) or
>> >>>>>>>>>> a requirement for specific hardware (CuPy requires an NVIDIA
>> GPU). SciPy
>> >>>>>>>>>> will continue to offer its own bundled FFT library (currently
>> fftpack, but
>> >>>>>>>>>> this could be switched to pocketfft as discussed in the ideas
>> page). The
>> >>>>>>>>>> purpose of the backend interface is to provide a convenient
>> way for users
>> >>>>>>>>>> to have third party libraries perform the FFTs instead, but
>> under the
>> >>>>>>>>>> existing scipy.fftpack API. This is motivated by a desire by
>> end users and
>> >>>>>>>>>> downstream projects to have features such as multi-threading
>> (pyFFTW and
>> >>>>>>>>>> mkl-fft) or GPU support (CuPy) that are not implemented in
>> scipy.fftpack.
>> >>>>>>>>>> Ultimately it will be up to users that opt-in to using these
>> other
>> >>>>>>>>>> libraries to confirm that the license terms and are compatible
>> with their
>> >>>>>>>>>> use case.
>> >>>>>>>>>>
>> >>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev mailing
>> >>>>>>>>>> lists prefers replies **below** the email you are replying to
>> so people can
>> >>>>>>>>>> more easily follow the thread of discussion. There are some
>> guidelines at:
>> >>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> I will research more about how to implement a backend myself
>> and
>> >>>>>>>>>>> will let you know as soon as I come up with something new.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>> CHeers,
>> >>>>>>>>>>> Greg
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <
>> grlee77 at gmail.com>
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
>> >>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started fixing some
>> >>>>>>>>>>>>> bugs, also made some pull request. Can anyone suggest me
>> how should I
>> >>>>>>>>>>>>> proceed further?
>> >>>>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>>>> SciPy-Dev mailing list
>> >>>>>>>>>>>>> SciPy-Dev at python.org
>> >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Hi Gopi,
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I think you have probably already found it, but the GSOC
>> >>>>>>>>>>>> project we have already identified mentors for in SciPy is
>> here:
>> >>>>>>>>>>>> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> If this is a project you are interested in then I would start
>> >>>>>>>>>>>> thinking about what the FFT interface would look like and
>> reviewing some of
>> >>>>>>>>>>>> the past/present issues related to fftpack / FFT in SciPy.
>> Please ask
>> >>>>>>>>>>>> questions you have related to that project here so that you
>> can clarify
>> >>>>>>>>>>>> what would be involved in writing a successful application.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> If you have a different idea in mind you can propose it here,
>> >>>>>>>>>>>> but you should do that soon, because it will be necessary to
>> determine if
>> >>>>>>>>>>>> there is interest from the SciPy team before you spend time
>> coming up with
>> >>>>>>>>>>>> a detailed proposal. We have to determine if a project
>> sounds feasible to
>> >>>>>>>>>>>> complete for GSOC and if appropriate mentors can be
>> identified.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Ultimately, you will need to submit an application to SciPy
>> >>>>>>>>>>>> between March 25th - April 9th.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Cheers,
>> >>>>>>>>>>>> Greg
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>>> SciPy-Dev mailing list
>> >>>>>>>>>>>> SciPy-Dev at python.org
>> >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>>>>>>>>>>>
>> >>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>> SciPy-Dev mailing list
>> >>>>>>>>>>> SciPy-Dev at python.org
>> >>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>>>>>>>>>>
>> >>>>>>>>>> _______________________________________________
>> >>>>>>>>>> SciPy-Dev mailing list
>> >>>>>>>>>> SciPy-Dev at python.org
>> >>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>>>>>>>>>
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> SciPy-Dev mailing list
>> >>>>>>>>> SciPy-Dev at python.org
>> >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> SciPy-Dev mailing list
>> >>>>>>>> SciPy-Dev at python.org
>> >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> SciPy-Dev mailing list
>> >>>>>>> SciPy-Dev at python.org
>> >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> SciPy-Dev mailing list
>> >>>>>> SciPy-Dev at python.org
>> >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>>>>>
>> >>>>> _______________________________________________
>> >>>>> SciPy-Dev mailing list
>> >>>>> SciPy-Dev at python.org
>> >>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>>>>
>> >>>> _______________________________________________
>> >>>> SciPy-Dev mailing list
>> >>>> SciPy-Dev at python.org
>> >>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>>>
>> >>> _______________________________________________
>> >>> SciPy-Dev mailing list
>> >>> SciPy-Dev at python.org
>> >>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>>
>> >> _______________________________________________
>> >> SciPy-Dev mailing list
>> >> SciPy-Dev at python.org
>> >> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/54f38250/attachment.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>>
>> ------------------------------
>>
>> End of SciPy-Dev Digest, Vol 185, Issue 18
>> ******************************************
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190404/1a670020/attachment-0001.html>

From andrewjhynes at gmail.com  Thu Apr  4 17:30:32 2019
From: andrewjhynes at gmail.com (Andrew Hynes)
Date: Thu, 4 Apr 2019 17:30:32 -0400
Subject: [SciPy-Dev] [ANN] Release of scikit-spatial package
Message-ID: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>

Hello everyone,

I'm completing my master's in computer engineering, and it involved writing
several functions for computations in 3D space, such as finding the line of
best fit from multiple points and projecting a point onto a line. I decided
to package my code into 'scikit-spatial', which provides objects for
points, vectors, lines and planes, and computations between them.

I know SymPy has similar objects in their geometry package, but my package
is based on NumPy for the objects and computations. The Point and Vector
objects are actually subclasses of the NumPy ndarray.

It's my first Python package, so any feedback or contributions would be
greatly appreciated. The code is at
https://github.com/ajhynes7/scikit-spatial.

I apologize if this is the wrong mailing list to post this. The "Scikits"
page (https://www.scipy.org/scikits.html) just says "It can however be
useful to let people know about it by discussing the new project e.g. on
the Scipy mailing lists.", but it doesn't specify which one. Maybe the
website can be edited to specify a mailing list for future reference?

Thanks,

Andrew Hynes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190404/46c60fff/attachment.html>

From nikolay.mayorov at zoho.com  Thu Apr  4 18:54:36 2019
From: nikolay.mayorov at zoho.com (Nikolay Mayorov)
Date: Fri, 05 Apr 2019 03:54:36 +0500
Subject: [SciPy-Dev] GSoC 2019 Projects
In-Reply-To: <CAJR3sXcsQATgJ952UK+Bigqf-L8EVL0hS=XMWahNyZKHVhcs0Q@mail.gmail.com>
References: <DB6PR04MB32069A19ECEABBA9433E85158E570@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAJR3sXcsQATgJ952UK+Bigqf-L8EVL0hS=XMWahNyZKHVhcs0Q@mail.gmail.com>
Message-ID: <169ea8fa4ac.11c0bd92d77285.775100711616655162@zoho.com>

Hi, Peter!



About ODE project. First of all I must admit that it is not very well thought, it's just something I decided would be possible to do if a right student came along.



* How much mathematical background is required? I have done a course covering

? the mathematics of ODE schemes including RK methods and some variable timestep

? methods, but am not familiar with control theory which is mentioned for the

? 3rd task.










It really depends on how you feel about that yourself. We are happy to consider any motivated student who will write a good proposal and make some contributions to scipy (as required by PSF). For the time step selection problem --- my intuition is that this problem is more about empirical tuning and experimenting rather than some rigorous theory.



* Will developing the test set just involve binding existing implementations to

? python for use in a testing framework, or do you expect these to be rewritten

? entirely in python or cython?










I believe it should be made a part of scipy benchmarks (https://github.com/scipy/scipy/tree/master/benchmarks). So the problem definitions are supposed to be coded just in Python.





- Nikolay





Hi Peter,



Yes, the application period is still open for GSOC, although the final deadline is the 9th, so time is becoming fairly short to get feedback on proposals.



A few other students have expressed interest in the FFT-based backends, but any interested candidates are welcome to apply. Please see some prior posts on this lists for some discussions related to that project. The primary intention is to allow 3rd party implementations to override the ones provided by SciPy when requested. Ideally there should also be some way to provide additional arguments specific to those implementations (e.g. specifying number of threads, planner effort, etc in the case of PyFFTW). We do not want any breaking changes to the existing scipy.fftpack interfaces as we need to maintain backwards compatibility with a lot of preexisting code in downstream libraries. Ideally downstream libraries should be able to benefit from the changes made in SciPy without any substantial refactoring on their end.



I am not personally familiar with the specifics of the ODE project and do not know if other candidates are currently pursuing that topic. Hopefully one of the mentors for it can respond here.



- Greg










On Wed, Apr 3, 2019 at 10:05 AM Peter Bell <mailto:peterbell10 at live.co.uk> wrote:

Hello,

?

I am interested in applying for Google summer of code and was wondering if you

are still looking for students?

?

A bit about myself

-------------------

My name is Peter and I'm in my 4th (penultimate) year of an integrated masters

in computational physics. Programming and numerical methods forms a key part of

this degree and many of my courses make heavy use of python with cython, numpy,

scipy, matplotlib, etc. While my degree is primarily Physics, I have taken a

number of computer science courses covering software engineering, object

oriented design and high performance programming.

?

I also have an interest in open source collaboration and, when time has allowed,

have contributed to a few projects via github (@peterbell10). The majority of

my contributions have been to a minecraft server which I've been contributing to

since summer 2017. You can see my pull requests here:

https://github.com/cuberite/cuberite/pulls?q=is%3Apr+is%3Amerged+author%3Apeterbell10

?

Questions about the projects

-----------------------------

I have some questions regarding both of the proposed projects.

?

Revamp fftpack:

* Is the primary intention to keep the scipy.fftpack interface the same, but add

? some mechanism to inject custom implementations? Or will this require changes

? to the front-facing interface as well? (e.g. for agreement with numpy.fft)

* What should this look like from the user's point of view? e.g.

?

?????? import scipy.fftpack

?????? import pyFFTW.interfaces.scipy_fftpack as fftw_pack

?

?????? scipy.fftpack.set_backend(fftw_pack)

?

? where we just provide a module implementing a well-documented backend

? interface. Alternatively, fftw_pack could be an object, potentially with

? its own instances of caches and settings which might allow for more

? configuration from the user.

?

Improve ODE solvers (mainly the first 3 tasks):

* How much mathematical background is required? I have done a course covering

? the mathematics of ODE schemes including RK methods and some variable timestep

? methods, but am not familiar with control theory which is mentioned for the

? 3rd task.

* Will developing the test set just involve binding existing implementations to

? python for use in a testing framework, or do you expect these to be rewritten

? entirely in python or cython?

?

?

Best regards,

Peter



_______________________________________________

 SciPy-Dev mailing list

 mailto:SciPy-Dev at python.org

 https://mail.python.org/mailman/listinfo/scipy-dev



_______________________________________________

SciPy-Dev mailing list 

mailto:SciPy-Dev at python.org 

https://mail.python.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190405/4142640d/attachment-0001.html>

From millman at berkeley.edu  Thu Apr  4 20:50:08 2019
From: millman at berkeley.edu (Jarrod Millman)
Date: Thu, 4 Apr 2019 17:50:08 -0700
Subject: [SciPy-Dev] NetworkX 2.3rc3 released (Python 3 only)
Message-ID: <CAB6X4si9D5uUKu9M9ig-i+Bz_8mL+Z2GAHafsfS-M6E1EGiAOA@mail.gmail.com>

I am happy to announce the third **release candidate** for NetworkX
2.3!  NetworkX is a Python package for the creation, manipulation, and
study of the structure, dynamics, and functions of complex networks.

This release supports Python 3.5-3.7 (i.e., this is our first **Python
3 only** release).  Please try out the pre-release and let us know
about any problems you find.  If no major issues arise, we will
release 2.3 final next week.

Please see the draft of the 2.3 release announcement:
  https://networkx.github.io/documentation/latest/release/release_dev.html

Since this is a pre-release, pip won't automatically install it.  So
  $ pip install networkx
still installs networkx-2.2.  But
  $ pip install --pre networkx
will install networkx-2.3rc3.  If you already have networkx installed
then you need to do
  $ pip install --pre --upgrade networkx

For more information, please visit our `website
<http://networkx.github.io/>`_ and our `gallery of examples
<https://networkx.github.io/documentation/latest/auto_examples/index.html>`_.
Please send comments and questions to the `networkx-discuss mailing
list <http://groups.google.com/group/networkx-discuss>`_.

Best regards,
Jarrod

From ralf.gommers at gmail.com  Fri Apr  5 04:19:33 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Fri, 5 Apr 2019 10:19:33 +0200
Subject: [SciPy-Dev] [ANN] Release of scikit-spatial package
In-Reply-To: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
References: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
Message-ID: <CABL7CQgNV8gu3oFTwN0X-DDAxqXfig65+r--0y=ez+S_H12Lnw@mail.gmail.com>

Hi Andrew,


On Thu, Apr 4, 2019 at 11:29 PM Andrew Hynes <andrewjhynes at gmail.com> wrote:

> Hello everyone,
>
> I'm completing my master's in computer engineering, and it involved
> writing several functions for computations in 3D space, such as finding the
> line of best fit from multiple points and projecting a point onto a line. I
> decided to package my code into 'scikit-spatial', which provides objects
> for points, vectors, lines and planes, and computations between them.
>

Looks interesting.


> I know SymPy has similar objects in their geometry package, but my package
> is based on NumPy for the objects and computations. The Point and Vector
> objects are actually subclasses of the NumPy ndarray.
>

I'd also be interested in the comparison between scikit-spatial and
scipy.spatial. It would probably be useful if you added that, as well as
the SymPy comparison, to the readme of your repo and/or the first page of
your docs.


> It's my first Python package, so any feedback or contributions would be
> greatly appreciated. The code is at
> https://github.com/ajhynes7/scikit-spatial.
>
> I apologize if this is the wrong mailing list to post this. The "Scikits"
> page (https://www.scipy.org/scikits.html) just says "It can however be
> useful to let people know about it by discussing the new project e.g. on
> the Scipy mailing lists.", but it doesn't specify which one. Maybe the
> website can be edited to specify a mailing list for future reference?
>

Yeah, that website needs some maintenance. An announcement and first
discussion here is fine. If there's regular discussion happening going
forward, then it would be good to set up a dedicated list (very easy with
Google Groups for exampple).

Cheers,
Ralf


> Thanks,
>
> Andrew Hynes
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190405/16620582/attachment.html>

From f20170920 at goa.bits-pilani.ac.in  Fri Apr  5 04:24:33 2019
From: f20170920 at goa.bits-pilani.ac.in (Anany Shrey Jain)
Date: Fri, 5 Apr 2019 13:54:33 +0530
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <mailman.1691.1554389922.2938.scipy-dev@python.org>
References: <mailman.1691.1554389922.2938.scipy-dev@python.org>
Message-ID: <CAG7Qgji4EBjPKASG6+3MdPt5yHM45qJShFRRAc13Av5Mr-SR8Q@mail.gmail.com>

Hey Greg,
The project "Revamp FFTPACK" also aims at contributing to third party
libraries to fill in functionality gaps. For pyFFTW I can see that work on
adding Real-to-Real transforms has been going on for a long time. So do I
need to continue the work going on in
https://github.com/pyFFTW/pyFFTW/pull/256 as a part of this project? What
needs to be done for the other two libraries? Do I need to make a similar
PR to other two libraries as well?

For all the three libraries there are SciPy-compatible routines already
defined. After getting required information using the newly created
interface I need to use them at the backend, right?

-Anany

> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 4 Apr 2019 10:58:27 -0400
> From: Gregory Lee <grlee77 at gmail.com>
> To: SciPy Developers List <scipy-dev at python.org>
> Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 185, Issue 18
> Message-ID:
>         <
> CAJR3sXcJuqQJrDboN5zH-pd7NG-wD8EWCdTCAtQ+vJpnZjKsRw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Anany,
>
> It is nice to see that you have updated with multiple potential APIs. Can
> some other core SciPy devs also help give feedback on what SciPy would find
> preferable? Out of the four you proposed, I think something along the lines
> of the second method is cleanest in terms of setting the backend at
> runtime. I think having some aspect from your 4th variant where the default
> backend can be read from a configuration file and/or environment variable
> is also desirable so that the user's desired default can always be
> automatically set at import time.
>
> I disagree with the following specific statement, though:
> "It is better to use all the above mentioned ideas because every idea has
> its own benefits besides it gives user the luxury to choose the method
> implementation of backend."
>
> I do not think we want to provide multiple ways to do the same thing. It
> can be confusing to users and more work for devs to maintain. I think there
> should be one method of setting the backend that the user can either call
> at run time or have it be automatically called based on some sort of
> configuration file and/or environment variable(s) at import time.
>
> - Greg
>
>
> On Tue, Apr 2, 2019 at 2:19 PM Anany Shrey Jain <
> f20170920 at goa.bits-pilani.ac.in> wrote:
>
> > Hey,
> > I have already sent the link to the page containing the list of ideas for
> > implementation of new API that I propose for this project. Would you like
> > to add something to it or give some comments on it? The Gsoc proposal
> > deadline is 9th of April and I am planning to put all of this in my
> > proposal to make it effective . So any more ideas or comments will be
> > really helpful for me . Here is the link to the page:
> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy .
> >
> > On Sun, Mar 31, 2019 at 5:23 AM <scipy-dev-request at python.org> wrote:
> >
> >>
> >> Message: 1
> >> Date: Sat, 30 Mar 2019 13:31:51 -0400
> >> From: Eric Larson <larson.eric.d at gmail.com>
> >> To: SciPy Developers List <scipy-dev at python.org>
> >> Subject: Re: [SciPy-Dev] GSoC 2019
> >> Message-ID:
> >>         <
> >> CAGu2niVWsKrMukfWcAWAtj-1NBm2utCeh3BOnNku7jNoAcx-kw at mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> It looks like the main ideas are in these bits of code, but not
> explicitly
> >> stated. In brief it looks like the proposed API is to add a `fft_object`
> >> kwarg to every function in `scipy.fftpack`. It would be good to discuss
> >> this choice explicitly -- what advantages and disadvantages it has
> >> relative
> >> to other approaches (e.g., creating new namespaces, or having a
> >> `set_backend` function (and/or context manager) that would change things
> >> under the hood).
> >>
> >> If you make changes and need more feedback, let us know. The more
> specific
> >> you can be about what you need feedback on (high level ideas, low level
> >> implementation, etc.), the better.
> >>
> >> Eric
> >>
> >>
> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
> >> f20170920 at goa.bits-pilani.ac.in> wrote:
> >>
> >> > Hey,
> >> > I went through the idea list of Scipy for this years's GSoC and I
> intend
> >> > to work towards the idea of revamping the Scipy's fftpack. I have
> >> already
> >> > been contributing to Scipy since the end of last year and I have some
> >> > knowledge about Fourier transforms as it was the part of my
> discipline.
> >> I
> >> > could not take part in this discussion earlier because my mid semester
> >> > exams were going on, but since they are now over so I can devote as
> much
> >> > time as required on this project. I have already created a github page
> >> with
> >> > some code snippets and functionalities that we can implement, here is
> >> the
> >> > link to it:
> >> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy .
> >> >
> >> > Cheers,
> >> > Anany Jain
> >> >
> >> > _______________________________________________
> >> > SciPy-Dev mailing list
> >> > SciPy-Dev at python.org
> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> >> >
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <
> >>
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/f1755dfb/attachment-0001.html
> >> >
> >>
> >> ------------------------------
> >>
> >> Message: 2
> >> Date: Sat, 30 Mar 2019 19:38:41 -0400
> >> From: Gregory Lee <grlee77 at gmail.com>
> >> To: SciPy Developers List <scipy-dev at python.org>
> >> Subject: Re: [SciPy-Dev] GSoC 2019
> >> Message-ID:
> >>         <CAJR3sXfnnr-0JO87gLbhh-7b-w=KjaNpac+F+FHTeFt2K=_
> >> QMw at mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
> >> f20170920 at goa.bits-pilani.ac.in> wrote:
> >>
> >> > Hey,
> >> > I went through the idea list of Scipy for this years's GSoC and I
> intend
> >> > to work towards the idea of revamping the Scipy's fftpack. I have
> >> already
> >> > been contributing to Scipy since the end of last year and I have some
> >> > knowledge about Fourier transforms as it was the part of my
> discipline.
> >> I
> >> > could not take part in this discussion earlier because my mid semester
> >> > exams were going on, but since they are now over so I can devote as
> much
> >> > time as required on this project. I have already created a github page
> >> with
> >> > some code snippets and functionalities that we can implement, here is
> >> the
> >> > link to it:
> >> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy .
> >> >
> >> > Cheers,
> >> > Anany Jain
> >> >
> >> > _______________________________________________
> >> > SciPy-Dev mailing list
> >> > SciPy-Dev at python.org
> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> >>
> >>
> >> Hi Anany,
> >>
> >> Thank you for your interest in GSOC with SciPy!  It's great to see that
> >> you
> >> are already thinking about a potential API and learning about the 3rd
> >> party
> >> FFT libraries. Along the lines of Eric's comment, think about what this
> >> API
> >> choice implies for users of libraries built upon SciPy. Would users of
> 3rd
> >> party libraries that rely on SciPy's FFTs be immediately able to take
> >> advantage of a differentf FFT backend in this scenario? (in other words,
> >> the case where the user is not calling scipy.fftpack.fft directly but is
> >> using it only indirectly via a function in a downstream library).
> >>
> >> Matplotlib is an example of an existing Python library supporting
> multiple
> >> backends that can be considered for comparison (see:
> >> https://matplotlib.org/faq/usage_faq.html#what-is-a-backend). Think
> about
> >> the relative benefits/drawbacks of some of the methods they use for
> >> setting
> >> a backend there as compared to the approach proposed for FFTs here.
> >>
> >> Another thing that should be considered: pyFFTW, MKL and CuPy already
> have
> >> some functions that match the existing scipy.fftpack API, but they may
> >> have
> >> one or more additional arguments particular to features of that library.
> >> How would you propose to deal with supporting additional optional
> >> arguments
> >> on the SciPy end?
> >>
> >> One other minor comment: I know that the blog post you made may be
> serving
> >> partly as personal notes, but please do not directly copy sections of
> text
> >> (e.g. the description of BLAS/LAPACK libraries) from elsewhere without
> >> attribution when writing a final proposal. (Also, the FFT functions are
> >> separate from the BLAS/LAPACK functions in MKL, so you will not need to
> >> discuss BLAS or LAPACK specifically in your proposal)
> >>
> >> - Greg
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <
> >>
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/c1351e7e/attachment-0001.html
> >> >
> >>
> >> ------------------------------
> >>
> >> Message: 3
> >> Date: Sat, 30 Mar 2019 19:53:02 -0400
> >> From: Gregory Lee <grlee77 at gmail.com>
> >> To: SciPy Developers List <scipy-dev at python.org>
> >> Subject: Re: [SciPy-Dev] GSoC 2019
> >> Message-ID:
> >>         <CAJR3sXdcPMAn_DETF8W-=
> >> MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw at mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> Hi Gopi,
> >>
> >> I am not sure I follow exactly what you are suggesting here. Are you
> >> proposing that the `fftpackN` variable in your example would be a Python
> >> module corresponding to a given backend? If so, why is an array of data,
> >> z,
> >> being passed into the newAPI function here? I don't see why a data array
> >> should be needed at all to choose a backend.
> >>
> >> Please also see my response to Anany's recent post on this list for a
> >> couple of other suggestions of things to consider in terms of the API.
> >>
> >> - Greg
> >>
> >>
> >> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
> >> deathcoderx at gmail.com>
> >> wrote:
> >>
> >> > Hey,
> >> > I went through the code and got some ideas.
> >> > So what will happen is:
> >> > First, we will declare FFTW as we use them normally.
> >> >
> >> > z = np.random.rand(2, 128, 64)
> >> > pyfftw.FFTW(z, axes=(-1, ))
> >> > ..
> >> > ..
> >> > Now after declaring our basic work to shift to another FFTpack, what
> we
> >> > can do is:
> >> > fftPackN= newAPI(z, pack = 'PYFFTW');
> >> >
> >> > Pack will take the name of the 3rd party FFT pack which we want to
> use.
> >> > Suggestions needed.
> >> >
> >> > Cheers.
> >> >
> >> >
> >>
> >> >
> >> > On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <larson.eric.d at gmail.com>
> >> > wrote:
> >> >
> >> >> After reading the related issues and thinking about the problem,
> >> perhaps
> >> >> the best first step is you come up with some initial API proposal.
> >> >>
> >> >> One way to work through the process is to think about the use cases
> >> that
> >> >> we want to support. How should users actually write code to use the
> new
> >> >> functionality? You can start with short code snippets that do not
> work
> >> >> currently, but should work for users at the end of the project. Then
> >> think
> >> >> about what needs to change inside SciPy for these code snippets to
> >> work.
> >> >> This can become an iterative process as you realize that the SciPy
> >> changes
> >> >> might be better or easier with changes to the user-facing API, etc.
> >> >>
> >> >> Eric
> >> >>
> >> >>
> >> >> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
> >> >> deathcoderx at gmail.com> wrote:
> >> >>
> >> >>> Hey,
> >> >>> As proposal submission period started I want to discuss a bit anobt
> >> how
> >> >>> can we implement the API.
> >> >>> I would very much appriciate inputs and guidance.
> >> >>>
> >> >>> Cheers.
> >> >>>
> >> >>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <
> larson.eric.d at gmail.com>
> >> >>> wrote:
> >> >>>
> >> >>>> The best way to figure that out is probably to take a look at some
> of
> >> >>>> the existing (minor) SciPy GitHub issues and try to work on one or
> >> two that
> >> >>>> you feel like working on. Actually trying to work out how to
> >> contribute
> >> >>>> code changes (as independently as possible/reasonable based on the
> >> existing
> >> >>>> guides/docs already discoverable online) will quickly highlight
> >> things that
> >> >>>> need to be learned. Some of the general things are the SciPy
> >> contributing
> >> >>>> guidelines, standard GitHub PR workflow, communication with
> >> reviewers, and
> >> >>>> so forth.
> >> >>>>
> >> >>>> For this particular project, it's important to understand the
> various
> >> >>>> flavors and properties of FFT in SciPy (real, complex,
> n-dimensional,
> >> >>>> caching plans, etc.) as well as other projects like NumPy, CuPy,
> and
> >> >>>> pyFFTW. Some of this can be learned and improved upon as part of
> >> GSoC, but
> >> >>>> the more you know and can demonstrate / put into practice knowledge
> >> of
> >> >>>> before the applications are reviewed, the better.
> >> >>>>
> >> >>>> Eric
> >> >>>>
> >> >>>>
> >> >>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
> >> >>>> deathcoderx at gmail.com> wrote:
> >> >>>>
> >> >>>>> Thank you for the detailed reply.
> >> >>>>> I will keep these point in mind while preparing my proposal. Apart
> >> >>>>> from proposal, what skills shall I improve so that I can
> contribute
> >> more
> >> >>>>> effectively and efficiently.
> >> >>>>>
> >> >>>>> Cheers.
> >> >>>>>
> >> >>>>>
> >> >>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <larson.eric.d at gmail.com
> >
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>>> There are a number of considerations that would be good to
> address.
> >> >>>>>> I'd start by considering the things that are typically considered
> >> >>>>>> when making changes to SciPy
> >> >>>>>> <
> >>
> https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy
> >> >,
> >> >>>>>> but I'd expand it to a longer list since the scope is bigger than
> >> a typical
> >> >>>>>> single PR. The list would contain (at least):
> >> >>>>>>
> >> >>>>>> - what will the user-facing API / contract be?
> >> >>>>>> - what in SciPy needs to change to allow it (internals /
> >> >>>>>> implementation outline, perhaps skeleton functions/classes)?
> >> >>>>>> - what examples should we show users (in general this ends up
> being
> >> >>>>>> just simple use cases of the API)?
> >> >>>>>> - how will we test it for correctness?
> >> >>>>>> - how will we benchmark it to prevent performance regressions?
> >> >>>>>> - how can we break up the work for these steps (if possible) into
> >> >>>>>> separable, sequential (or -- better but not usually possible --
> >> >>>>>> independent) PRs?
> >> >>>>>>
> >> >>>>>> You might notice that none of these points are actually all that
> >> >>>>>> specific to the FFT project, but can be generally applicable to
> >> GSoC
> >> >>>>>> projects. For the FFT project, I would say "how do we build the
> >> backend" is
> >> >>>>>> indeed implicitly contained / outlined in these bullet points.
> And
> >> as with
> >> >>>>>> most projects, the first two points (and possibly the last) will
> >> probably
> >> >>>>>> be the most challenging to sort out.
> >> >>>>>>
> >> >>>>>> Eric
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
> >> >>>>>> deathcoderx at gmail.com> wrote:
> >> >>>>>>
> >> >>>>>>> Hey Eric,
> >> >>>>>>> So for my proposal, shall I include how can we built a back end?
> >> >>>>>>> What all points shall I include to make it effective?
> >> >>>>>>>
> >> >>>>>>> Cheers.
> >> >>>>>>>
> >> >>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <
> larson.eric.d at gmail.com
> >> >
> >> >>>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>>> That would be me -- don't worry, I'm on this list, as are
> >> >>>>>>>> (presumably) other developers interested in the discussion, so
> >> no need to
> >> >>>>>>>> document elsewhere for now from our end. It looks like Greg has
> >> summarized
> >> >>>>>>>> the current status and thoughts we've had, so I don't have much
> >> to add at
> >> >>>>>>>> this point.
> >> >>>>>>>>
> >> >>>>>>>> Eric
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
> >> >>>>>>>> deathcoderx at gmail.com> wrote:
> >> >>>>>>>>
> >> >>>>>>>>> Hey Greg,
> >> >>>>>>>>> I got the basic idea about what we want to implement this
> year.
> >> >>>>>>>>> Our first priority is to create a backend for 3rd party
> >> fftpacks.
> >> >>>>>>>>> We can create API using Python and Flask or any other suitable
> >> framework.
> >> >>>>>>>>>
> >> >>>>>>>>> I thought this discussion was going on on SciPy Developer List
> >> >>>>>>>>> only. So do I need to document it all and post it somewhere so
> >> that other
> >> >>>>>>>>> contributors can see this?
> >> >>>>>>>>> Also, I couldn't find any contact info regarding Eric. It
> would
> >> be
> >> >>>>>>>>> very helpful if we include him in this discussion as this is a
> >> roadmap for
> >> >>>>>>>>> GSoC project and I can also get more insight into the project
> >> and expected
> >> >>>>>>>>> outcomes.
> >> >>>>>>>>>
> >> >>>>>>>>> Cheers.
> >> >>>>>>>>>
> >> >>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <grlee77 at gmail.com
> >
> >> >>>>>>>>> wrote:
> >> >>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
> >> >>>>>>>>>> deathcoderx at gmail.com> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>>> Hey Gregory,
> >> >>>>>>>>>>> I went through the idea and I am very much interested in
> >> working
> >> >>>>>>>>>>> on it. I had Fourier Transforms as a part of my academic
> >> course, so I am
> >> >>>>>>>>>>> well aware with basic concepts.
> >> >>>>>>>>>>> One thing I want to discuss is, its mentioned that we have
> to
> >> >>>>>>>>>>> create a backend system for 3rd party FFTpacks so my dobuts
> >> >>>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>> 1. How are we going to create API?
> >> >>>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>> This will needed to be decided on in consensus with the SciPy
> >> >>>>>>>>>> developers and user community. I am mentoring for the project
> >> as a
> >> >>>>>>>>>> contributor here and a maintainer of the related pyFFTW
> >> package, but I am
> >> >>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core dev
> >> here). I have
> >> >>>>>>>>>> not discussed the API in any detail with the SciPy team at
> >> this stage.
> >> >>>>>>>>>> Working out details of what the API should look like and
> >> working to
> >> >>>>>>>>>> finalize that in collaboration with the community will be a
> >> primary task
> >> >>>>>>>>>> during the early part of the GSOC project.
> >> >>>>>>>>>>
> >> >>>>>>>>>> 2. After the creation of backend will user at the time of
> >> >>>>>>>>>>> installation of SciPy will decide what all 3rd party
> FFTpacks
> >> he needs or
> >> >>>>>>>>>>> we will include some by default?
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> The idea is to allow users to opt-in to a different FFT
> >> backend
> >> >>>>>>>>>> at run time, but these alternative libraries will not be
> >> distributed with
> >> >>>>>>>>>> SciPy itself due to incompatible software licenses (pyFFTW
> and
> >> mkl-fft) or
> >> >>>>>>>>>> a requirement for specific hardware (CuPy requires an NVIDIA
> >> GPU). SciPy
> >> >>>>>>>>>> will continue to offer its own bundled FFT library (currently
> >> fftpack, but
> >> >>>>>>>>>> this could be switched to pocketfft as discussed in the ideas
> >> page). The
> >> >>>>>>>>>> purpose of the backend interface is to provide a convenient
> >> way for users
> >> >>>>>>>>>> to have third party libraries perform the FFTs instead, but
> >> under the
> >> >>>>>>>>>> existing scipy.fftpack API. This is motivated by a desire by
> >> end users and
> >> >>>>>>>>>> downstream projects to have features such as multi-threading
> >> (pyFFTW and
> >> >>>>>>>>>> mkl-fft) or GPU support (CuPy) that are not implemented in
> >> scipy.fftpack.
> >> >>>>>>>>>> Ultimately it will be up to users that opt-in to using these
> >> other
> >> >>>>>>>>>> libraries to confirm that the license terms and are
> compatible
> >> with their
> >> >>>>>>>>>> use case.
> >> >>>>>>>>>>
> >> >>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev mailing
> >> >>>>>>>>>> lists prefers replies **below** the email you are replying to
> >> so people can
> >> >>>>>>>>>> more easily follow the thread of discussion. There are some
> >> guidelines at:
> >> >>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>> I will research more about how to implement a backend myself
> >> and
> >> >>>>>>>>>>> will let you know as soon as I come up with something new.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>> CHeers,
> >> >>>>>>>>>>> Greg
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <
> >> grlee77 at gmail.com>
> >> >>>>>>>>>>> wrote:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
> >> >>>>>>>>>>>> deathcoderx at gmail.com> wrote:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started fixing
> some
> >> >>>>>>>>>>>>> bugs, also made some pull request. Can anyone suggest me
> >> how should I
> >> >>>>>>>>>>>>> proceed further?
> >> >>>>>>>>>>>>> _______________________________________________
> >> >>>>>>>>>>>>> SciPy-Dev mailing list
> >> >>>>>>>>>>>>> SciPy-Dev at python.org
> >> >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Hi Gopi,
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> I think you have probably already found it, but the GSOC
> >> >>>>>>>>>>>> project we have already identified mentors for in SciPy is
> >> here:
> >> >>>>>>>>>>>>
> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> If this is a project you are interested in then I would
> start
> >> >>>>>>>>>>>> thinking about what the FFT interface would look like and
> >> reviewing some of
> >> >>>>>>>>>>>> the past/present issues related to fftpack / FFT in SciPy.
> >> Please ask
> >> >>>>>>>>>>>> questions you have related to that project here so that you
> >> can clarify
> >> >>>>>>>>>>>> what would be involved in writing a successful application.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> If you have a different idea in mind you can propose it
> here,
> >> >>>>>>>>>>>> but you should do that soon, because it will be necessary
> to
> >> determine if
> >> >>>>>>>>>>>> there is interest from the SciPy team before you spend time
> >> coming up with
> >> >>>>>>>>>>>> a detailed proposal. We have to determine if a project
> >> sounds feasible to
> >> >>>>>>>>>>>> complete for GSOC and if appropriate mentors can be
> >> identified.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Ultimately, you will need to submit an application to SciPy
> >> >>>>>>>>>>>> between March 25th - April 9th.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Cheers,
> >> >>>>>>>>>>>> Greg
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> _______________________________________________
> >> >>>>>>>>>>>> SciPy-Dev mailing list
> >> >>>>>>>>>>>> SciPy-Dev at python.org
> >> >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>> _______________________________________________
> >> >>>>>>>>>>> SciPy-Dev mailing list
> >> >>>>>>>>>>> SciPy-Dev at python.org
> >> >>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>>>>>>>>>>
> >> >>>>>>>>>> _______________________________________________
> >> >>>>>>>>>> SciPy-Dev mailing list
> >> >>>>>>>>>> SciPy-Dev at python.org
> >> >>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>>>>>>>>>
> >> >>>>>>>>> _______________________________________________
> >> >>>>>>>>> SciPy-Dev mailing list
> >> >>>>>>>>> SciPy-Dev at python.org
> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>>>>>>>>
> >> >>>>>>>> _______________________________________________
> >> >>>>>>>> SciPy-Dev mailing list
> >> >>>>>>>> SciPy-Dev at python.org
> >> >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>>>>>>>
> >> >>>>>>> _______________________________________________
> >> >>>>>>> SciPy-Dev mailing list
> >> >>>>>>> SciPy-Dev at python.org
> >> >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>>>>>>
> >> >>>>>> _______________________________________________
> >> >>>>>> SciPy-Dev mailing list
> >> >>>>>> SciPy-Dev at python.org
> >> >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>>>>>
> >> >>>>> _______________________________________________
> >> >>>>> SciPy-Dev mailing list
> >> >>>>> SciPy-Dev at python.org
> >> >>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>>>>
> >> >>>> _______________________________________________
> >> >>>> SciPy-Dev mailing list
> >> >>>> SciPy-Dev at python.org
> >> >>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>>>
> >> >>> _______________________________________________
> >> >>> SciPy-Dev mailing list
> >> >>> SciPy-Dev at python.org
> >> >>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>>
> >> >> _______________________________________________
> >> >> SciPy-Dev mailing list
> >> >> SciPy-Dev at python.org
> >> >> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>
> >> > _______________________________________________
> >> > SciPy-Dev mailing list
> >> > SciPy-Dev at python.org
> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> >> >
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <
> >>
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/54f38250/attachment.html
> >> >
> >>
> >> ------------------------------
> >>
> >> Subject: Digest Footer
> >>
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at python.org
> >> https://mail.python.org/mailman/listinfo/scipy-dev
> >>
> >>
> >> ------------------------------
> >>
> >> End of SciPy-Dev Digest, Vol 185, Issue 18
> >> ******************************************
> >>
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at python.org
> > https://mail.python.org/mailman/listinfo/scipy-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/scipy-dev/attachments/20190404/1a670020/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
>
> ------------------------------
>
> End of SciPy-Dev Digest, Vol 186, Issue 11
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190405/49ceeaf2/attachment-0001.html>

From peterbell10 at live.co.uk  Fri Apr  5 07:33:48 2019
From: peterbell10 at live.co.uk (Peter Bell)
Date: Fri, 5 Apr 2019 11:33:48 +0000
Subject: [SciPy-Dev] GSoC 2019 Projects
In-Reply-To: <CAJR3sXcsQATgJ952UK+Bigqf-L8EVL0hS=XMWahNyZKHVhcs0Q@mail.gmail.com>
References: <DB6PR04MB32069A19ECEABBA9433E85158E570@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAJR3sXcsQATgJ952UK+Bigqf-L8EVL0hS=XMWahNyZKHVhcs0Q@mail.gmail.com>
Message-ID: <DB6PR04MB32063F059BECBDD4962BF9698E510@DB6PR04MB3206.eurprd04.prod.outlook.com>

Hi Greg,

Thanks for your response.

>Ideally there should also be some way to provide additional arguments specific to those implementations

I see that pyFFTW adds additional keyword args to the fftpack functions. In your opinion is it okay to pass backend dependant arguments to SciPy? I think most of the same functionality could be done via global configuration and/or some generally applicable arguments could be incorporated into the fftpack API directly in a backwords compatible manner.
For example, pyFFTW?s ?planner_effort? is quite backend specific so would be global. Whereas ?overwrite_input? option might make sense for other FFT implementations and not just FFTW specifically; so could be added as an argument with a backwards compatible default value.

Peter

From: SciPy-Dev <scipy-dev-bounces+peterbell10=live.co.uk at python.org> On Behalf Of Gregory Lee
Sent: 04 April 2019 15:42
To: SciPy Developers List <scipy-dev at python.org>
Subject: Re: [SciPy-Dev] GSoC 2019 Projects

Hi Peter,

Yes, the application period is still open for GSOC, although the final deadline is the 9th, so time is becoming fairly short to get feedback on proposals.

A few other students have expressed interest in the FFT-based backends, but any interested candidates are welcome to apply. Please see some prior posts on this lists for some discussions related to that project. The primary intention is to allow 3rd party implementations to override the ones provided by SciPy when requested. Ideally there should also be some way to provide additional arguments specific to those implementations (e.g. specifying number of threads, planner effort, etc in the case of PyFFTW). We do not want any breaking changes to the existing scipy.fftpack interfaces as we need to maintain backwards compatibility with a lot of preexisting code in downstream libraries. Ideally downstream libraries should be able to benefit from the changes made in SciPy without any substantial refactoring on their end.

I am not personally familiar with the specifics of the ODE project and do not know if other candidates are currently pursuing that topic. Hopefully one of the mentors for it can respond here.

- Greg




On Wed, Apr 3, 2019 at 10:05 AM Peter Bell <peterbell10 at live.co.uk<mailto:peterbell10 at live.co.uk>> wrote:
Hello,

I am interested in applying for Google summer of code and was wondering if you
are still looking for students?

A bit about myself
-------------------
My name is Peter and I'm in my 4th (penultimate) year of an integrated masters
in computational physics. Programming and numerical methods forms a key part of
this degree and many of my courses make heavy use of python with cython, numpy,
scipy, matplotlib, etc. While my degree is primarily Physics, I have taken a
number of computer science courses covering software engineering, object
oriented design and high performance programming.

I also have an interest in open source collaboration and, when time has allowed,
have contributed to a few projects via github (@peterbell10). The majority of
my contributions have been to a minecraft server which I've been contributing to
since summer 2017. You can see my pull requests here:
https://github.com/cuberite/cuberite/pulls?q=is%3Apr+is%3Amerged+author%3Apeterbell10

Questions about the projects
-----------------------------
I have some questions regarding both of the proposed projects.

Revamp fftpack:
* Is the primary intention to keep the scipy.fftpack interface the same, but add
  some mechanism to inject custom implementations? Or will this require changes
  to the front-facing interface as well? (e.g. for agreement with numpy.fft)
* What should this look like from the user's point of view? e.g.

       import scipy.fftpack
       import pyFFTW.interfaces.scipy_fftpack as fftw_pack

       scipy.fftpack.set_backend(fftw_pack)

  where we just provide a module implementing a well-documented backend
  interface. Alternatively, fftw_pack could be an object, potentially with
  its own instances of caches and settings which might allow for more
  configuration from the user.

Improve ODE solvers (mainly the first 3 tasks):
* How much mathematical background is required? I have done a course covering
  the mathematics of ODE schemes including RK methods and some variable timestep
  methods, but am not familiar with control theory which is mentioned for the
  3rd task.
* Will developing the test set just involve binding existing implementations to
  python for use in a testing framework, or do you expect these to be rewritten
  entirely in python or cython?


Best regards,
Peter
_______________________________________________
SciPy-Dev mailing list
SciPy-Dev at python.org<mailto:SciPy-Dev at python.org>
https://mail.python.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190405/16b97a37/attachment-0001.html>

From grlee77 at gmail.com  Fri Apr  5 12:13:15 2019
From: grlee77 at gmail.com (Gregory Lee)
Date: Fri, 5 Apr 2019 12:13:15 -0400
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CAG7Qgji4EBjPKASG6+3MdPt5yHM45qJShFRRAc13Av5Mr-SR8Q@mail.gmail.com>
References: <mailman.1691.1554389922.2938.scipy-dev@python.org>
 <CAG7Qgji4EBjPKASG6+3MdPt5yHM45qJShFRRAc13Av5Mr-SR8Q@mail.gmail.com>
Message-ID: <CAJR3sXeVPAB+jGB_EdxiDg45jbR4wHzLVjjBk7+RiesT0XMrpw@mail.gmail.com>

On Fri, Apr 5, 2019 at 4:25 AM Anany Shrey Jain <
f20170920 at goa.bits-pilani.ac.in> wrote:

> Hey Greg,
> The project "Revamp FFTPACK" also aims at contributing to third party
> libraries to fill in functionality gaps. For pyFFTW I can see that work on
> adding Real-to-Real transforms has been going on for a long time. So do I
> need to continue the work going on in
> https://github.com/pyFFTW/pyFFTW/pull/256 as a part of this project?
>

It is not a requirement that you work on the pyFFTW wrappers, but that
would be a good complement to this project. Here are some thoughts.

1.) I would first have a mechanism to fall back to the existing
scipy.fftpack implementations for any functions not currently supported by
a given backend. pyFFTW currently already falls back to scipy's own
implementation for DCT and DST transforms (
https://github.com/pyFFTW/pyFFTW/blob/e9966e5d215a00f89156bd88e1d42b884f85df78/pyfftw/interfaces/scipy_fftpack.py#L81-L82).
The PR you referenced would allow it to use FFTW to perform these
transforms instead and there would be no remaining functions that fall back
to scipy.fftpack.

2.) You can work on adding real-to-real support in supporting libraries,
but this is a secondary goal to pursue once the SciPy side of the project
has been completed.
   pyFFTW builds on FFTW which does already have functions providing
real-to-real transforms. So what you see in the PR referenced above is
mainly adding the wrappers for those to pyFFTW.



> What needs to be done for the other two libraries? Do I need to make a
> similar PR to other two libraries as well?
>
>
You could potentially try that, but I think that is more of a stretch goal.
The approach for CuPy or mkl-fft would have to be different, because for
those two cases the underlying libraries DO NOT have dedicated functions
implementing the real-to-real transforms. Also, the underlying FFT
libraries are proprietary, so we cannot propose to add new transforms on
the C/C++ side. However, it is possible in principle to implement
real-to-real transforms using only the already existing complex-valued
transforms (albeit at some additional computational/memory cost). Some
detailed examples of this are given in the following thread on DSP
StackExchange:
https://dsp.stackexchange.com/questions/2807/fast-cosine-transform-via-fft

I think that is probably the only feasible route for real-to-real
transforms using those two backends. I think whether or not this type of
implementation would give a performance benefit over just reusing the
existing scipy.fftpack implementations is unknown.

One FFT-related issues that could be improved in CuPy in a more
straightforward manner than adding real-to-real support, is improving the
real-to-complex and complex-to-real support.  These transforms are
supported by the underlying CUFFT library, but support for this within CuPy
is incomplete.  One issue related to this was opened at (
https://github.com/cupy/cupy/issues/1936), but no PR implementing it has
been made.


> For all the three libraries there are SciPy-compatable routines already
> defined. After getting required information using the newly created
> interface I need to use them at the backend, right?
>

Yes, you should rely on the already existing interfaces when implementing
the backends in SciPy. Any additional 3rd party libraries would have to
provide a scipy-like interface in order to be compatible for use as a
backend.



>
> -Anany
>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 4 Apr 2019 10:58:27 -0400
>> From: Gregory Lee <grlee77 at gmail.com>
>> To: SciPy Developers List <scipy-dev at python.org>
>> Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 185, Issue 18
>> Message-ID:
>>         <
>> CAJR3sXcJuqQJrDboN5zH-pd7NG-wD8EWCdTCAtQ+vJpnZjKsRw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi Anany,
>>
>> It is nice to see that you have updated with multiple potential APIs. Can
>> some other core SciPy devs also help give feedback on what SciPy would
>> find
>> preferable? Out of the four you proposed, I think something along the
>> lines
>> of the second method is cleanest in terms of setting the backend at
>> runtime. I think having some aspect from your 4th variant where the
>> default
>> backend can be read from a configuration file and/or environment variable
>> is also desirable so that the user's desired default can always be
>> automatically set at import time.
>>
>> I disagree with the following specific statement, though:
>> "It is better to use all the above mentioned ideas because every idea has
>> its own benefits besides it gives user the luxury to choose the method
>> implementation of backend."
>>
>> I do not think we want to provide multiple ways to do the same thing. It
>> can be confusing to users and more work for devs to maintain. I think
>> there
>> should be one method of setting the backend that the user can either call
>> at run time or have it be automatically called based on some sort of
>> configuration file and/or environment variable(s) at import time.
>>
>> - Greg
>>
>>
>> On Tue, Apr 2, 2019 at 2:19 PM Anany Shrey Jain <
>> f20170920 at goa.bits-pilani.ac.in> wrote:
>>
>> > Hey,
>> > I have already sent the link to the page containing the list of ideas
>> for
>> > implementation of new API that I propose for this project. Would you
>> like
>> > to add something to it or give some comments on it? The Gsoc proposal
>> > deadline is 9th of April and I am planning to put all of this in my
>> > proposal to make it effective . So any more ideas or comments will be
>> > really helpful for me . Here is the link to the page:
>> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy .
>> >
>> > On Sun, Mar 31, 2019 at 5:23 AM <scipy-dev-request at python.org> wrote:
>> >
>> >>
>> >> Message: 1
>> >> Date: Sat, 30 Mar 2019 13:31:51 -0400
>> >> From: Eric Larson <larson.eric.d at gmail.com>
>> >> To: SciPy Developers List <scipy-dev at python.org>
>> >> Subject: Re: [SciPy-Dev] GSoC 2019
>> >> Message-ID:
>> >>         <
>> >> CAGu2niVWsKrMukfWcAWAtj-1NBm2utCeh3BOnNku7jNoAcx-kw at mail.gmail.com>
>> >> Content-Type: text/plain; charset="utf-8"
>> >>
>> >> It looks like the main ideas are in these bits of code, but not
>> explicitly
>> >> stated. In brief it looks like the proposed API is to add a
>> `fft_object`
>> >> kwarg to every function in `scipy.fftpack`. It would be good to discuss
>> >> this choice explicitly -- what advantages and disadvantages it has
>> >> relative
>> >> to other approaches (e.g., creating new namespaces, or having a
>> >> `set_backend` function (and/or context manager) that would change
>> things
>> >> under the hood).
>> >>
>> >> If you make changes and need more feedback, let us know. The more
>> specific
>> >> you can be about what you need feedback on (high level ideas, low level
>> >> implementation, etc.), the better.
>> >>
>> >> Eric
>> >>
>> >>
>> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
>> >> f20170920 at goa.bits-pilani.ac.in> wrote:
>> >>
>> >> > Hey,
>> >> > I went through the idea list of Scipy for this years's GSoC and I
>> intend
>> >> > to work towards the idea of revamping the Scipy's fftpack. I have
>> >> already
>> >> > been contributing to Scipy since the end of last year and I have some
>> >> > knowledge about Fourier transforms as it was the part of my
>> discipline.
>> >> I
>> >> > could not take part in this discussion earlier because my mid
>> semester
>> >> > exams were going on, but since they are now over so I can devote as
>> much
>> >> > time as required on this project. I have already created a github
>> page
>> >> with
>> >> > some code snippets and functionalities that we can implement, here is
>> >> the
>> >> > link to it:
>> >> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
>> .
>> >> >
>> >> > Cheers,
>> >> > Anany Jain
>> >> >
>> >> > _______________________________________________
>> >> > SciPy-Dev mailing list
>> >> > SciPy-Dev at python.org
>> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >> URL: <
>> >>
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/f1755dfb/attachment-0001.html
>> >> >
>> >>
>> >> ------------------------------
>> >>
>> >> Message: 2
>> >> Date: Sat, 30 Mar 2019 19:38:41 -0400
>> >> From: Gregory Lee <grlee77 at gmail.com>
>> >> To: SciPy Developers List <scipy-dev at python.org>
>> >> Subject: Re: [SciPy-Dev] GSoC 2019
>> >> Message-ID:
>> >>         <CAJR3sXfnnr-0JO87gLbhh-7b-w=KjaNpac+F+FHTeFt2K=_
>> >> QMw at mail.gmail.com>
>> >> Content-Type: text/plain; charset="utf-8"
>> >>
>> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
>> >> f20170920 at goa.bits-pilani.ac.in> wrote:
>> >>
>> >> > Hey,
>> >> > I went through the idea list of Scipy for this years's GSoC and I
>> intend
>> >> > to work towards the idea of revamping the Scipy's fftpack. I have
>> >> already
>> >> > been contributing to Scipy since the end of last year and I have some
>> >> > knowledge about Fourier transforms as it was the part of my
>> discipline.
>> >> I
>> >> > could not take part in this discussion earlier because my mid
>> semester
>> >> > exams were going on, but since they are now over so I can devote as
>> much
>> >> > time as required on this project. I have already created a github
>> page
>> >> with
>> >> > some code snippets and functionalities that we can implement, here is
>> >> the
>> >> > link to it:
>> >> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
>> .
>> >> >
>> >> > Cheers,
>> >> > Anany Jain
>> >> >
>> >> > _______________________________________________
>> >> > SciPy-Dev mailing list
>> >> > SciPy-Dev at python.org
>> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >>
>> >>
>> >> Hi Anany,
>> >>
>> >> Thank you for your interest in GSOC with SciPy!  It's great to see that
>> >> you
>> >> are already thinking about a potential API and learning about the 3rd
>> >> party
>> >> FFT libraries. Along the lines of Eric's comment, think about what this
>> >> API
>> >> choice implies for users of libraries built upon SciPy. Would users of
>> 3rd
>> >> party libraries that rely on SciPy's FFTs be immediately able to take
>> >> advantage of a differentf FFT backend in this scenario? (in other
>> words,
>> >> the case where the user is not calling scipy.fftpack.fft directly but
>> is
>> >> using it only indirectly via a function in a downstream library).
>> >>
>> >> Matplotlib is an example of an existing Python library supporting
>> multiple
>> >> backends that can be considered for comparison (see:
>> >> https://matplotlib.org/faq/usage_faq.html#what-is-a-backend). Think
>> about
>> >> the relative benefits/drawbacks of some of the methods they use for
>> >> setting
>> >> a backend there as compared to the approach proposed for FFTs here.
>> >>
>> >> Another thing that should be considered: pyFFTW, MKL and CuPy already
>> have
>> >> some functions that match the existing scipy.fftpack API, but they may
>> >> have
>> >> one or more additional arguments particular to features of that
>> library.
>> >> How would you propose to deal with supporting additional optional
>> >> arguments
>> >> on the SciPy end?
>> >>
>> >> One other minor comment: I know that the blog post you made may be
>> serving
>> >> partly as personal notes, but please do not directly copy sections of
>> text
>> >> (e.g. the description of BLAS/LAPACK libraries) from elsewhere without
>> >> attribution when writing a final proposal. (Also, the FFT functions are
>> >> separate from the BLAS/LAPACK functions in MKL, so you will not need to
>> >> discuss BLAS or LAPACK specifically in your proposal)
>> >>
>> >> - Greg
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >> URL: <
>> >>
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/c1351e7e/attachment-0001.html
>> >> >
>> >>
>> >> ------------------------------
>> >>
>> >> Message: 3
>> >> Date: Sat, 30 Mar 2019 19:53:02 -0400
>> >> From: Gregory Lee <grlee77 at gmail.com>
>> >> To: SciPy Developers List <scipy-dev at python.org>
>> >> Subject: Re: [SciPy-Dev] GSoC 2019
>> >> Message-ID:
>> >>         <CAJR3sXdcPMAn_DETF8W-=
>> >> MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw at mail.gmail.com>
>> >> Content-Type: text/plain; charset="utf-8"
>> >>
>> >> Hi Gopi,
>> >>
>> >> I am not sure I follow exactly what you are suggesting here. Are you
>> >> proposing that the `fftpackN` variable in your example would be a
>> Python
>> >> module corresponding to a given backend? If so, why is an array of
>> data,
>> >> z,
>> >> being passed into the newAPI function here? I don't see why a data
>> array
>> >> should be needed at all to choose a backend.
>> >>
>> >> Please also see my response to Anany's recent post on this list for a
>> >> couple of other suggestions of things to consider in terms of the API.
>> >>
>> >> - Greg
>> >>
>> >>
>> >> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
>> >> deathcoderx at gmail.com>
>> >> wrote:
>> >>
>> >> > Hey,
>> >> > I went through the code and got some ideas.
>> >> > So what will happen is:
>> >> > First, we will declare FFTW as we use them normally.
>> >> >
>> >> > z = np.random.rand(2, 128, 64)
>> >> > pyfftw.FFTW(z, axes=(-1, ))
>> >> > ..
>> >> > ..
>> >> > Now after declaring our basic work to shift to another FFTpack, what
>> we
>> >> > can do is:
>> >> > fftPackN= newAPI(z, pack = 'PYFFTW');
>> >> >
>> >> > Pack will take the name of the 3rd party FFT pack which we want to
>> use.
>> >> > Suggestions needed.
>> >> >
>> >> > Cheers.
>> >> >
>> >> >
>> >>
>> >> >
>> >> > On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <larson.eric.d at gmail.com
>> >
>> >> > wrote:
>> >> >
>> >> >> After reading the related issues and thinking about the problem,
>> >> perhaps
>> >> >> the best first step is you come up with some initial API proposal.
>> >> >>
>> >> >> One way to work through the process is to think about the use cases
>> >> that
>> >> >> we want to support. How should users actually write code to use the
>> new
>> >> >> functionality? You can start with short code snippets that do not
>> work
>> >> >> currently, but should work for users at the end of the project. Then
>> >> think
>> >> >> about what needs to change inside SciPy for these code snippets to
>> >> work.
>> >> >> This can become an iterative process as you realize that the SciPy
>> >> changes
>> >> >> might be better or easier with changes to the user-facing API, etc.
>> >> >>
>> >> >> Eric
>> >> >>
>> >> >>
>> >> >> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
>> >> >> deathcoderx at gmail.com> wrote:
>> >> >>
>> >> >>> Hey,
>> >> >>> As proposal submission period started I want to discuss a bit anobt
>> >> how
>> >> >>> can we implement the API.
>> >> >>> I would very much appriciate inputs and guidance.
>> >> >>>
>> >> >>> Cheers.
>> >> >>>
>> >> >>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <
>> larson.eric.d at gmail.com>
>> >> >>> wrote:
>> >> >>>
>> >> >>>> The best way to figure that out is probably to take a look at
>> some of
>> >> >>>> the existing (minor) SciPy GitHub issues and try to work on one or
>> >> two that
>> >> >>>> you feel like working on. Actually trying to work out how to
>> >> contribute
>> >> >>>> code changes (as independently as possible/reasonable based on the
>> >> existing
>> >> >>>> guides/docs already discoverable online) will quickly highlight
>> >> things that
>> >> >>>> need to be learned. Some of the general things are the SciPy
>> >> contributing
>> >> >>>> guidelines, standard GitHub PR workflow, communication with
>> >> reviewers, and
>> >> >>>> so forth.
>> >> >>>>
>> >> >>>> For this particular project, it's important to understand the
>> various
>> >> >>>> flavors and properties of FFT in SciPy (real, complex,
>> n-dimensional,
>> >> >>>> caching plans, etc.) as well as other projects like NumPy, CuPy,
>> and
>> >> >>>> pyFFTW. Some of this can be learned and improved upon as part of
>> >> GSoC, but
>> >> >>>> the more you know and can demonstrate / put into practice
>> knowledge
>> >> of
>> >> >>>> before the applications are reviewed, the better.
>> >> >>>>
>> >> >>>> Eric
>> >> >>>>
>> >> >>>>
>> >> >>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
>> >> >>>> deathcoderx at gmail.com> wrote:
>> >> >>>>
>> >> >>>>> Thank you for the detailed reply.
>> >> >>>>> I will keep these point in mind while preparing my proposal.
>> Apart
>> >> >>>>> from proposal, what skills shall I improve so that I can
>> contribute
>> >> more
>> >> >>>>> effectively and efficiently.
>> >> >>>>>
>> >> >>>>> Cheers.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <
>> larson.eric.d at gmail.com>
>> >> >>>>> wrote:
>> >> >>>>>
>> >> >>>>>> There are a number of considerations that would be good to
>> address.
>> >> >>>>>> I'd start by considering the things that are typically
>> considered
>> >> >>>>>> when making changes to SciPy
>> >> >>>>>> <
>> >>
>> https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy
>> >> >,
>> >> >>>>>> but I'd expand it to a longer list since the scope is bigger
>> than
>> >> a typical
>> >> >>>>>> single PR. The list would contain (at least):
>> >> >>>>>>
>> >> >>>>>> - what will the user-facing API / contract be?
>> >> >>>>>> - what in SciPy needs to change to allow it (internals /
>> >> >>>>>> implementation outline, perhaps skeleton functions/classes)?
>> >> >>>>>> - what examples should we show users (in general this ends up
>> being
>> >> >>>>>> just simple use cases of the API)?
>> >> >>>>>> - how will we test it for correctness?
>> >> >>>>>> - how will we benchmark it to prevent performance regressions?
>> >> >>>>>> - how can we break up the work for these steps (if possible)
>> into
>> >> >>>>>> separable, sequential (or -- better but not usually possible --
>> >> >>>>>> independent) PRs?
>> >> >>>>>>
>> >> >>>>>> You might notice that none of these points are actually all that
>> >> >>>>>> specific to the FFT project, but can be generally applicable to
>> >> GSoC
>> >> >>>>>> projects. For the FFT project, I would say "how do we build the
>> >> backend" is
>> >> >>>>>> indeed implicitly contained / outlined in these bullet points.
>> And
>> >> as with
>> >> >>>>>> most projects, the first two points (and possibly the last) will
>> >> probably
>> >> >>>>>> be the most challenging to sort out.
>> >> >>>>>>
>> >> >>>>>> Eric
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
>> >> >>>>>> deathcoderx at gmail.com> wrote:
>> >> >>>>>>
>> >> >>>>>>> Hey Eric,
>> >> >>>>>>> So for my proposal, shall I include how can we built a back
>> end?
>> >> >>>>>>> What all points shall I include to make it effective?
>> >> >>>>>>>
>> >> >>>>>>> Cheers.
>> >> >>>>>>>
>> >> >>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <
>> larson.eric.d at gmail.com
>> >> >
>> >> >>>>>>> wrote:
>> >> >>>>>>>
>> >> >>>>>>>> That would be me -- don't worry, I'm on this list, as are
>> >> >>>>>>>> (presumably) other developers interested in the discussion, so
>> >> no need to
>> >> >>>>>>>> document elsewhere for now from our end. It looks like Greg
>> has
>> >> summarized
>> >> >>>>>>>> the current status and thoughts we've had, so I don't have
>> much
>> >> to add at
>> >> >>>>>>>> this point.
>> >> >>>>>>>>
>> >> >>>>>>>> Eric
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
>> >> >>>>>>>> deathcoderx at gmail.com> wrote:
>> >> >>>>>>>>
>> >> >>>>>>>>> Hey Greg,
>> >> >>>>>>>>> I got the basic idea about what we want to implement this
>> year.
>> >> >>>>>>>>> Our first priority is to create a backend for 3rd party
>> >> fftpacks.
>> >> >>>>>>>>> We can create API using Python and Flask or any other
>> suitable
>> >> framework.
>> >> >>>>>>>>>
>> >> >>>>>>>>> I thought this discussion was going on on SciPy Developer
>> List
>> >> >>>>>>>>> only. So do I need to document it all and post it somewhere
>> so
>> >> that other
>> >> >>>>>>>>> contributors can see this?
>> >> >>>>>>>>> Also, I couldn't find any contact info regarding Eric. It
>> would
>> >> be
>> >> >>>>>>>>> very helpful if we include him in this discussion as this is
>> a
>> >> roadmap for
>> >> >>>>>>>>> GSoC project and I can also get more insight into the project
>> >> and expected
>> >> >>>>>>>>> outcomes.
>> >> >>>>>>>>>
>> >> >>>>>>>>> Cheers.
>> >> >>>>>>>>>
>> >> >>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <
>> grlee77 at gmail.com>
>> >> >>>>>>>>> wrote:
>> >> >>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
>> >> >>>>>>>>>> deathcoderx at gmail.com> wrote:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>> Hey Gregory,
>> >> >>>>>>>>>>> I went through the idea and I am very much interested in
>> >> working
>> >> >>>>>>>>>>> on it. I had Fourier Transforms as a part of my academic
>> >> course, so I am
>> >> >>>>>>>>>>> well aware with basic concepts.
>> >> >>>>>>>>>>> One thing I want to discuss is, its mentioned that we have
>> to
>> >> >>>>>>>>>>> create a backend system for 3rd party FFTpacks so my dobuts
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>> 1. How are we going to create API?
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> This will needed to be decided on in consensus with the
>> SciPy
>> >> >>>>>>>>>> developers and user community. I am mentoring for the
>> project
>> >> as a
>> >> >>>>>>>>>> contributor here and a maintainer of the related pyFFTW
>> >> package, but I am
>> >> >>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core dev
>> >> here). I have
>> >> >>>>>>>>>> not discussed the API in any detail with the SciPy team at
>> >> this stage.
>> >> >>>>>>>>>> Working out details of what the API should look like and
>> >> working to
>> >> >>>>>>>>>> finalize that in collaboration with the community will be a
>> >> primary task
>> >> >>>>>>>>>> during the early part of the GSOC project.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> 2. After the creation of backend will user at the time of
>> >> >>>>>>>>>>> installation of SciPy will decide what all 3rd party
>> FFTpacks
>> >> he needs or
>> >> >>>>>>>>>>> we will include some by default?
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> The idea is to allow users to opt-in to a different FFT
>> >> backend
>> >> >>>>>>>>>> at run time, but these alternative libraries will not be
>> >> distributed with
>> >> >>>>>>>>>> SciPy itself due to incompatible software licenses (pyFFTW
>> and
>> >> mkl-fft) or
>> >> >>>>>>>>>> a requirement for specific hardware (CuPy requires an NVIDIA
>> >> GPU). SciPy
>> >> >>>>>>>>>> will continue to offer its own bundled FFT library
>> (currently
>> >> fftpack, but
>> >> >>>>>>>>>> this could be switched to pocketfft as discussed in the
>> ideas
>> >> page). The
>> >> >>>>>>>>>> purpose of the backend interface is to provide a convenient
>> >> way for users
>> >> >>>>>>>>>> to have third party libraries perform the FFTs instead, but
>> >> under the
>> >> >>>>>>>>>> existing scipy.fftpack API. This is motivated by a desire by
>> >> end users and
>> >> >>>>>>>>>> downstream projects to have features such as multi-threading
>> >> (pyFFTW and
>> >> >>>>>>>>>> mkl-fft) or GPU support (CuPy) that are not implemented in
>> >> scipy.fftpack.
>> >> >>>>>>>>>> Ultimately it will be up to users that opt-in to using these
>> >> other
>> >> >>>>>>>>>> libraries to confirm that the license terms and are
>> compatible
>> >> with their
>> >> >>>>>>>>>> use case.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev mailing
>> >> >>>>>>>>>> lists prefers replies **below** the email you are replying
>> to
>> >> so people can
>> >> >>>>>>>>>> more easily follow the thread of discussion. There are some
>> >> guidelines at:
>> >> >>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> I will research more about how to implement a backend myself
>> >> and
>> >> >>>>>>>>>>> will let you know as soon as I come up with something new.
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> CHeers,
>> >> >>>>>>>>>>> Greg
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <
>> >> grlee77 at gmail.com>
>> >> >>>>>>>>>>> wrote:
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
>> >> >>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started fixing
>> some
>> >> >>>>>>>>>>>>> bugs, also made some pull request. Can anyone suggest me
>> >> how should I
>> >> >>>>>>>>>>>>> proceed further?
>> >> >>>>>>>>>>>>> _______________________________________________
>> >> >>>>>>>>>>>>> SciPy-Dev mailing list
>> >> >>>>>>>>>>>>> SciPy-Dev at python.org
>> >> >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> Hi Gopi,
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> I think you have probably already found it, but the GSOC
>> >> >>>>>>>>>>>> project we have already identified mentors for in SciPy is
>> >> here:
>> >> >>>>>>>>>>>>
>> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> If this is a project you are interested in then I would
>> start
>> >> >>>>>>>>>>>> thinking about what the FFT interface would look like and
>> >> reviewing some of
>> >> >>>>>>>>>>>> the past/present issues related to fftpack / FFT in SciPy.
>> >> Please ask
>> >> >>>>>>>>>>>> questions you have related to that project here so that
>> you
>> >> can clarify
>> >> >>>>>>>>>>>> what would be involved in writing a successful
>> application.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> If you have a different idea in mind you can propose it
>> here,
>> >> >>>>>>>>>>>> but you should do that soon, because it will be necessary
>> to
>> >> determine if
>> >> >>>>>>>>>>>> there is interest from the SciPy team before you spend
>> time
>> >> coming up with
>> >> >>>>>>>>>>>> a detailed proposal. We have to determine if a project
>> >> sounds feasible to
>> >> >>>>>>>>>>>> complete for GSOC and if appropriate mentors can be
>> >> identified.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> Ultimately, you will need to submit an application to
>> SciPy
>> >> >>>>>>>>>>>> between March 25th - April 9th.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> Cheers,
>> >> >>>>>>>>>>>> Greg
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> _______________________________________________
>> >> >>>>>>>>>>>> SciPy-Dev mailing list
>> >> >>>>>>>>>>>> SciPy-Dev at python.org
>> >> >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>> _______________________________________________
>> >> >>>>>>>>>>> SciPy-Dev mailing list
>> >> >>>>>>>>>>> SciPy-Dev at python.org
>> >> >>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> _______________________________________________
>> >> >>>>>>>>>> SciPy-Dev mailing list
>> >> >>>>>>>>>> SciPy-Dev at python.org
>> >> >>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>>>>>>>>>
>> >> >>>>>>>>> _______________________________________________
>> >> >>>>>>>>> SciPy-Dev mailing list
>> >> >>>>>>>>> SciPy-Dev at python.org
>> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>>>>>>>>
>> >> >>>>>>>> _______________________________________________
>> >> >>>>>>>> SciPy-Dev mailing list
>> >> >>>>>>>> SciPy-Dev at python.org
>> >> >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>>>>>>>
>> >> >>>>>>> _______________________________________________
>> >> >>>>>>> SciPy-Dev mailing list
>> >> >>>>>>> SciPy-Dev at python.org
>> >> >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>>>>>>
>> >> >>>>>> _______________________________________________
>> >> >>>>>> SciPy-Dev mailing list
>> >> >>>>>> SciPy-Dev at python.org
>> >> >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>>>>>
>> >> >>>>> _______________________________________________
>> >> >>>>> SciPy-Dev mailing list
>> >> >>>>> SciPy-Dev at python.org
>> >> >>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>>>>
>> >> >>>> _______________________________________________
>> >> >>>> SciPy-Dev mailing list
>> >> >>>> SciPy-Dev at python.org
>> >> >>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>>>
>> >> >>> _______________________________________________
>> >> >>> SciPy-Dev mailing list
>> >> >>> SciPy-Dev at python.org
>> >> >>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>>
>> >> >> _______________________________________________
>> >> >> SciPy-Dev mailing list
>> >> >> SciPy-Dev at python.org
>> >> >> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>
>> >> > _______________________________________________
>> >> > SciPy-Dev mailing list
>> >> > SciPy-Dev at python.org
>> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >> URL: <
>> >>
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/54f38250/attachment.html
>> >> >
>> >>
>> >> ------------------------------
>> >>
>> >> Subject: Digest Footer
>> >>
>> >> _______________________________________________
>> >> SciPy-Dev mailing list
>> >> SciPy-Dev at python.org
>> >> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>
>> >>
>> >> ------------------------------
>> >>
>> >> End of SciPy-Dev Digest, Vol 185, Issue 18
>> >> ******************************************
>> >>
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190404/1a670020/attachment.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>>
>> ------------------------------
>>
>> End of SciPy-Dev Digest, Vol 186, Issue 11
>> ******************************************
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190405/cc4019f5/attachment-0001.html>

From grlee77 at gmail.com  Fri Apr  5 12:29:50 2019
From: grlee77 at gmail.com (Gregory Lee)
Date: Fri, 5 Apr 2019 12:29:50 -0400
Subject: [SciPy-Dev] GSoC 2019 Projects
In-Reply-To: <DB6PR04MB32063F059BECBDD4962BF9698E510@DB6PR04MB3206.eurprd04.prod.outlook.com>
References: <DB6PR04MB32069A19ECEABBA9433E85158E570@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAJR3sXcsQATgJ952UK+Bigqf-L8EVL0hS=XMWahNyZKHVhcs0Q@mail.gmail.com>
 <DB6PR04MB32063F059BECBDD4962BF9698E510@DB6PR04MB3206.eurprd04.prod.outlook.com>
Message-ID: <CAJR3sXci50WD3_gvJYSFMSZyT1pQzau-wf0_8ptMw-6jWSYYVA@mail.gmail.com>

On Fri, Apr 5, 2019 at 7:34 AM Peter Bell <peterbell10 at live.co.uk> wrote:

> Hi Greg,
>
>
>
> Thanks for your response.
>
>
>
> >Ideally there should also be some way to provide additional arguments
> specific to those implementations
>
>
>
> I see that pyFFTW adds additional keyword args to the fftpack functions.
> In your opinion is it okay to pass backend dependant arguments to SciPy?
> I think most of the same functionality could be done via global
> configuration and/or some generally applicable arguments could be
> incorporated into the fftpack API directly in a backwords compatible
> manner.
>
> For example, pyFFTW?s ?planner_effort? is quite backend specific so would
> be global. Whereas ?overwrite_input? option might make sense for other
> FFT implementations and not just FFTW specifically; so could be added as an
> argument with a backwards compatible default value.
>
>
> Peter
>
>
I think one possibility on the SciPy side would be to just extend the
signature of the scipy functions to add **kwargs. Then any additional
keyword arguments would be passed onto the underlying backend's fft
routine. I would be curious of the opinion of other scipy dev's opinion on
what they would prefer. I think the problem with the **kwargs approach is
that if downstream libraries start relying on kwargs specific to a given
backend then it may no longer be possible for users of those libraries to
override the choice of backend.

A simpler option on the SciPy side would be to not support passing
additional keyword arguments to the backends at all. The obvious downside
of that approach is that it would prevent using some potentially beneficial
aspects of the underlying libraries. For pyFFTW you can configure some
things like the default number of threads and planner effort without
passing in arguments, so arguments for those are not strictly necessary.
Similarly, I think MKL respects a MKL_NUM_THREADS environment variable.




>
>
> *From:* SciPy-Dev <scipy-dev-bounces+peterbell10=live.co.uk at python.org> *On
> Behalf Of *Gregory Lee
> *Sent:* 04 April 2019 15:42
> *To:* SciPy Developers List <scipy-dev at python.org>
> *Subject:* Re: [SciPy-Dev] GSoC 2019 Projects
>
>
>
> Hi Peter,
>
>
>
> Yes, the application period is still open for GSOC, although the final
> deadline is the 9th, so time is becoming fairly short to get feedback on
> proposals.
>
>
>
> A few other students have expressed interest in the FFT-based backends,
> but any interested candidates are welcome to apply. Please see some prior
> posts on this lists for some discussions related to that project. The
> primary intention is to allow 3rd party implementations to override the
> ones provided by SciPy when requested. Ideally there should also be some
> way to provide additional arguments specific to those implementations (e.g.
> specifying number of threads, planner effort, etc in the case of PyFFTW).
> We do not want any breaking changes to the existing scipy.fftpack
> interfaces as we need to maintain backwards compatibility with a lot of
> preexisting code in downstream libraries. Ideally downstream libraries
> should be able to benefit from the changes made in SciPy without any
> substantial refactoring on their end.
>
>
>
> I am not personally familiar with the specifics of the ODE project and do
> not know if other candidates are currently pursuing that topic. Hopefully
> one of the mentors for it can respond here.
>
>
>
> - Greg
>
>
>
>
>
>
>
>
>
> On Wed, Apr 3, 2019 at 10:05 AM Peter Bell <peterbell10 at live.co.uk> wrote:
>
> Hello,
>
>
>
> I am interested in applying for Google summer of code and was wondering if
> you
>
> are still looking for students?
>
>
>
> A bit about myself
>
> -------------------
>
> My name is Peter and I'm in my 4th (penultimate) year of an integrated
> masters
>
> in computational physics. Programming and numerical methods forms a key
> part of
>
> this degree and many of my courses make heavy use of python with cython,
> numpy,
>
> scipy, matplotlib, etc. While my degree is primarily Physics, I have taken
> a
>
> number of computer science courses covering software engineering, object
>
> oriented design and high performance programming.
>
>
>
> I also have an interest in open source collaboration and, when time has
> allowed,
>
> have contributed to a few projects via github (@peterbell10). The majority
> of
>
> my contributions have been to a minecraft server which I've been
> contributing to
>
> since summer 2017. You can see my pull requests here:
>
>
> https://github.com/cuberite/cuberite/pulls?q=is%3Apr+is%3Amerged+author%3Apeterbell10
>
>
>
> Questions about the projects
>
> -----------------------------
>
> I have some questions regarding both of the proposed projects.
>
>
>
> Revamp fftpack:
>
> * Is the primary intention to keep the scipy.fftpack interface the same,
> but add
>
>   some mechanism to inject custom implementations? Or will this require
> changes
>
>   to the front-facing interface as well? (e.g. for agreement with
> numpy.fft)
>
> * What should this look like from the user's point of view? e.g.
>
>
>
>        import scipy.fftpack
>
>        import pyFFTW.interfaces.scipy_fftpack as fftw_pack
>
>
>
>        scipy.fftpack.set_backend(fftw_pack)
>
>
>
>   where we just provide a module implementing a well-documented backend
>
>   interface. Alternatively, fftw_pack could be an object, potentially with
>
>   its own instances of caches and settings which might allow for more
>
>   configuration from the user.
>
>
>
> Improve ODE solvers (mainly the first 3 tasks):
>
> * How much mathematical background is required? I have done a course
> covering
>
>   the mathematics of ODE schemes including RK methods and some variable
> timestep
>
>   methods, but am not familiar with control theory which is mentioned for
> the
>
>   3rd task.
>
> * Will developing the test set just involve binding existing
> implementations to
>
>   python for use in a testing framework, or do you expect these to be
> rewritten
>
>   entirely in python or cython?
>
>
>
>
>
> Best regards,
>
> Peter
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190405/e2f383d6/attachment.html>

From ralf.gommers at gmail.com  Fri Apr  5 13:49:35 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Fri, 5 Apr 2019 19:49:35 +0200
Subject: [SciPy-Dev] GSoC 2019 Projects
In-Reply-To: <CAJR3sXci50WD3_gvJYSFMSZyT1pQzau-wf0_8ptMw-6jWSYYVA@mail.gmail.com>
References: <DB6PR04MB32069A19ECEABBA9433E85158E570@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAJR3sXcsQATgJ952UK+Bigqf-L8EVL0hS=XMWahNyZKHVhcs0Q@mail.gmail.com>
 <DB6PR04MB32063F059BECBDD4962BF9698E510@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAJR3sXci50WD3_gvJYSFMSZyT1pQzau-wf0_8ptMw-6jWSYYVA@mail.gmail.com>
Message-ID: <CABL7CQh-wK7FkvFJiRHv=JnXMQTF=EcFE9azfWEKuxUObuGL9Q@mail.gmail.com>

On Fri, Apr 5, 2019 at 6:30 PM Gregory Lee <grlee77 at gmail.com> wrote:

>
>
> On Fri, Apr 5, 2019 at 7:34 AM Peter Bell <peterbell10 at live.co.uk> wrote:
>
>> Hi Greg,
>>
>>
>>
>> Thanks for your response.
>>
>>
>>
>> >Ideally there should also be some way to provide additional arguments
>> specific to those implementations
>>
>>
>>
>> I see that pyFFTW adds additional keyword args to the fftpack functions.
>> In your opinion is it okay to pass backend dependant arguments to SciPy?
>> I think most of the same functionality could be done via global
>> configuration and/or some generally applicable arguments could be
>> incorporated into the fftpack API directly in a backwords compatible
>> manner.
>>
>> For example, pyFFTW?s ?planner_effort? is quite backend specific so would
>> be global. Whereas ?overwrite_input? option might make sense for other
>> FFT implementations and not just FFTW specifically; so could be added as an
>> argument with a backwards compatible default value.
>>
>>
>> Peter
>>
>>
> I think one possibility on the SciPy side would be to just extend the
> signature of the scipy functions to add **kwargs. Then any additional
> keyword arguments would be passed onto the underlying backend's fft
> routine. I would be curious of the opinion of other scipy dev's opinion on
> what they would prefer. I think the problem with the **kwargs approach is
> that if downstream libraries start relying on kwargs specific to a given
> backend then it may no longer be possible for users of those libraries to
> override the choice of backend.
>
> A simpler option on the SciPy side would be to not support passing
> additional keyword arguments to the backends at all.
>

I think backend-specific keywords are hard to support without making the
API uglier, and the value is limited - if your code has become specific to
one backend, then you may as well use that backend directly right?


> The obvious downside of that approach is that it would prevent using some
> potentially beneficial aspects of the underlying libraries. For pyFFTW you
> can configure some things like the default number of threads and planner
> effort without passing in arguments, so arguments for those are not
> strictly necessary. Similarly, I think MKL respects a MKL_NUM_THREADS
> environment variable.
>

There will be a way to set the number of MKL, OpenBLAS and OpenMP threads
in NumPy soon probably: https://github.com/numpy/numpy/pull/13136

Cheers,
Ralf


>
>
>
>>
>>
>> *From:* SciPy-Dev <scipy-dev-bounces+peterbell10=live.co.uk at python.org> *On
>> Behalf Of *Gregory Lee
>> *Sent:* 04 April 2019 15:42
>> *To:* SciPy Developers List <scipy-dev at python.org>
>> *Subject:* Re: [SciPy-Dev] GSoC 2019 Projects
>>
>>
>>
>> Hi Peter,
>>
>>
>>
>> Yes, the application period is still open for GSOC, although the final
>> deadline is the 9th, so time is becoming fairly short to get feedback on
>> proposals.
>>
>>
>>
>> A few other students have expressed interest in the FFT-based backends,
>> but any interested candidates are welcome to apply. Please see some prior
>> posts on this lists for some discussions related to that project. The
>> primary intention is to allow 3rd party implementations to override the
>> ones provided by SciPy when requested. Ideally there should also be some
>> way to provide additional arguments specific to those implementations (e.g.
>> specifying number of threads, planner effort, etc in the case of PyFFTW).
>> We do not want any breaking changes to the existing scipy.fftpack
>> interfaces as we need to maintain backwards compatibility with a lot of
>> preexisting code in downstream libraries. Ideally downstream libraries
>> should be able to benefit from the changes made in SciPy without any
>> substantial refactoring on their end.
>>
>>
>>
>> I am not personally familiar with the specifics of the ODE project and do
>> not know if other candidates are currently pursuing that topic. Hopefully
>> one of the mentors for it can respond here.
>>
>>
>>
>> - Greg
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 3, 2019 at 10:05 AM Peter Bell <peterbell10 at live.co.uk>
>> wrote:
>>
>> Hello,
>>
>>
>>
>> I am interested in applying for Google summer of code and was wondering
>> if you
>>
>> are still looking for students?
>>
>>
>>
>> A bit about myself
>>
>> -------------------
>>
>> My name is Peter and I'm in my 4th (penultimate) year of an integrated
>> masters
>>
>> in computational physics. Programming and numerical methods forms a key
>> part of
>>
>> this degree and many of my courses make heavy use of python with cython,
>> numpy,
>>
>> scipy, matplotlib, etc. While my degree is primarily Physics, I have
>> taken a
>>
>> number of computer science courses covering software engineering, object
>>
>> oriented design and high performance programming.
>>
>>
>>
>> I also have an interest in open source collaboration and, when time has
>> allowed,
>>
>> have contributed to a few projects via github (@peterbell10). The
>> majority of
>>
>> my contributions have been to a minecraft server which I've been
>> contributing to
>>
>> since summer 2017. You can see my pull requests here:
>>
>>
>> https://github.com/cuberite/cuberite/pulls?q=is%3Apr+is%3Amerged+author%3Apeterbell10
>>
>>
>>
>> Questions about the projects
>>
>> -----------------------------
>>
>> I have some questions regarding both of the proposed projects.
>>
>>
>>
>> Revamp fftpack:
>>
>> * Is the primary intention to keep the scipy.fftpack interface the same,
>> but add
>>
>>   some mechanism to inject custom implementations? Or will this require
>> changes
>>
>>   to the front-facing interface as well? (e.g. for agreement with
>> numpy.fft)
>>
>> * What should this look like from the user's point of view? e.g.
>>
>>
>>
>>        import scipy.fftpack
>>
>>        import pyFFTW.interfaces.scipy_fftpack as fftw_pack
>>
>>
>>
>>        scipy.fftpack.set_backend(fftw_pack)
>>
>>
>>
>>   where we just provide a module implementing a well-documented backend
>>
>>   interface. Alternatively, fftw_pack could be an object, potentially with
>>
>>   its own instances of caches and settings which might allow for more
>>
>>   configuration from the user.
>>
>>
>>
>> Improve ODE solvers (mainly the first 3 tasks):
>>
>> * How much mathematical background is required? I have done a course
>> covering
>>
>>   the mathematics of ODE schemes including RK methods and some variable
>> timestep
>>
>>   methods, but am not familiar with control theory which is mentioned for
>> the
>>
>>   3rd task.
>>
>> * Will developing the test set just involve binding existing
>> implementations to
>>
>>   python for use in a testing framework, or do you expect these to be
>> rewritten
>>
>>   entirely in python or cython?
>>
>>
>>
>>
>>
>> Best regards,
>>
>> Peter
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190405/443ce897/attachment-0001.html>

From christoph.baumgarten at gmail.com  Fri Apr  5 15:24:36 2019
From: christoph.baumgarten at gmail.com (Christoph Baumgarten)
Date: Fri, 5 Apr 2019 21:24:36 +0200
Subject: [SciPy-Dev] Google Season of Docs
In-Reply-To: <mailman.1683.1554388938.2938.scipy-dev@python.org>
References: <mailman.1683.1554388938.2938.scipy-dev@python.org>
Message-ID: <CABXY2qB5NuaTdfWnPOF+BUDZWHdMrzgWG4ZMC97LBMZr4TCrQQ@mail.gmail.com>

I created a first draft in a forked repo:

https://github.com/chrisb83/gsod/blob/gsod-stats/2019/SciPy_ideas_list.md

Feedback is welcome!
https://github.com/chrisb83/gsod/pull/1

On Thu, Apr 4, 2019 at 4:43 PM <scipy-dev-request at python.org> wrote:

> Send SciPy-Dev mailing list submissions to
>         scipy-dev at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.python.org/mailman/listinfo/scipy-dev
> or, via email, send a message with subject or body 'help' to
>         scipy-dev-request at python.org
>
> You can reach the person managing the list at
>         scipy-dev-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SciPy-Dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Google Season of Docs (Ralf Gommers)
>    2. Re: GSoC 2019 Projects (Gregory Lee)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 4 Apr 2019 13:26:40 +0200
> From: Ralf Gommers <ralf.gommers at gmail.com>
> To: SciPy Developers List <scipy-dev at python.org>
> Subject: Re: [SciPy-Dev] Google Season of Docs
> Message-ID:
>         <CABL7CQg5Qyjb=
> xf_JMmAOvLamd330m47E1Y356-cLfj99TOXKA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Apr 3, 2019 at 11:49 PM Paul van Mulbregt <
> p.vanmulbregt at comcast.net>
> wrote:
>
> > I can be a second mentor for the stats documentation proposal.
> >
>
> Great, thanks Paul!
>
>
> > -Paul
> >
> > On Apr 3, 2019, at 3:12 PM, Christoph Baumgarten <
> > christoph.baumgarten at gmail.com> wrote:
> >
> >
> > Sure, I will add it in the next few days.
> >
> > On Tue, Apr 2, 2019 at 6:02 PM <scipy-dev-request at python.org> wrote:
> >
> >> Send SciPy-Dev mailing list submissions to
> >>         scipy-dev at python.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >>         https://mail.python.org/mailman/listinfo/scipy-dev
> >> or, via email, send a message with subject or body 'help' to
> >>         scipy-dev-request at python.org
> >>
> >> You can reach the person managing the list at
> >>         scipy-dev-owner at python.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of SciPy-Dev digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >>    1. Re: Google Season of Docs (Ralf Gommers)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Tue, 2 Apr 2019 10:40:20 +0200
> >> From: Ralf Gommers <ralf.gommers at gmail.com>
> >> To: SciPy Developers List <scipy-dev at python.org>
> >> Subject: Re: [SciPy-Dev] Google Season of Docs
> >> Message-ID:
> >>         <CABL7CQipvttnWrAE=
> >> V6Fr+iJKjGM1x0wgKbK-ea7ZNsOXx6YDg at mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> On Fri, Mar 22, 2019 at 8:07 PM Ralf Gommers <ralf.gommers at gmail.com>
> >> wrote:
> >>
> >> >
> >> >
> >> > On Thu, Mar 21, 2019 at 12:10 PM Christoph Baumgarten <
> >> > christoph.baumgarten at gmail.com> wrote:
> >> >
> >> >>
> >> >> Hi,
> >> >>
> >> >> taking up Ralf's mail on GSoD, I had a look at the website and
> propose
> >> to
> >> >> apply.
> >> >>
> >> >> My project suggestion would be to work on the documentation of a
> module
> >> >> like stats:
> >> >>
> >> >
> >> >> - improve the tutorial site
> >> >> https://docs.scipy.org/doc/scipy/reference/tutorial/stats.html
> >> >> - improve the documentation of the API
> >> >>   - check whether current descriptions can be improved
> >> >>   - add examples and references
> >> >>   - cross-ref to other relevant / similar functions in the module
> >> >>
> >> >> The second point would require decent knowledge of statistics whereas
> >> the
> >> >> first point should be easier to tackle for a technical writer. So I
> >> see the
> >> >> second point as optional and one could also try to work on the
> tutorial
> >> >> site of more than one module during the 3-month period.
> >> >>
> >> >
> >> >> The task would leave quite a bit of freedom to the writer to choose
> >> what
> >> >> areas to focus on, potentially taking up some of the documentation
> >> issues
> >> >> that are already on Github.
> >> >>
> >> >> I could assist as a mentor for stats (we need at least two mentors).
> >> >>
> >> >> Any suggestions or comments?
> >> >>
> >> >
> >> > Thanks Christoph, this sounds like a good idea to me. We have a lot of
> >> > content on scipy.stats, and a tech writer could really make a
> >> difference in
> >> > making that easier to understand for users. I suggest we write this up
> >> as
> >> > an idea on our (to be created) ideas page as soon as we know whether
> we
> >> > have an umbrella organization that we can participate with.
> >> >
> >>
> >>  An update on this: NumFOCUS is applying as an umbrella org. We'll need
> to
> >> add our ideas at
> >> https://github.com/numfocus/gsod/blob/master/2019/SciPy_ideas_list.md.
> >> Since there are going to be few spots available, it's the quality of the
> >> content that matters for acceptance of NumFOCUS as an umbrella org. We
> >> should have 1-2 ideas that are well described up on that page by April
> >> 14th. There are some guidelines at
> >>
> >>
> https://developers.google.com/season-of-docs/docs/project-ideas#project-idea
> >>
> >> Christoph, could you add your idea in that SciPy_ideas_list.md file?
> >>
> >> I will add some more general information there about getting started on
> >> the
> >> SciPy docs. Also, if anyone has another idea, that would be great to
> hear.
> >>
> >> Cheers,
> >> Ralf
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <
> >>
> http://mail.python.org/pipermail/scipy-dev/attachments/20190402/244fdd76/attachment-0001.html
> >> >
> >>
> >> ------------------------------
> >>
> >> Subject: Digest Footer
> >>
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at python.org
> >> https://mail.python.org/mailman/listinfo/scipy-dev
> >>
> >>
> >> ------------------------------
> >>
> >> End of SciPy-Dev Digest, Vol 186, Issue 6
> >> *****************************************
> >>
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at python.org
> > https://mail.python.org/mailman/listinfo/scipy-dev
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at python.org
> > https://mail.python.org/mailman/listinfo/scipy-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/scipy-dev/attachments/20190404/8005557c/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Thu, 4 Apr 2019 10:42:04 -0400
> From: Gregory Lee <grlee77 at gmail.com>
> To: SciPy Developers List <scipy-dev at python.org>
> Subject: Re: [SciPy-Dev] GSoC 2019 Projects
> Message-ID:
>         <CAJR3sXcsQATgJ952UK+Bigqf-L8EVL0hS=
> XMWahNyZKHVhcs0Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Peter,
>
> Yes, the application period is still open for GSOC, although the final
> deadline is the 9th, so time is becoming fairly short to get feedback on
> proposals.
>
> A few other students have expressed interest in the FFT-based backends, but
> any interested candidates are welcome to apply. Please see some prior posts
> on this lists for some discussions related to that project. The primary
> intention is to allow 3rd party implementations to override the ones
> provided by SciPy when requested. Ideally there should also be some way to
> provide additional arguments specific to those implementations (e.g.
> specifying number of threads, planner effort, etc in the case of PyFFTW).
> We do not want any breaking changes to the existing scipy.fftpack
> interfaces as we need to maintain backwards compatibility with a lot of
> preexisting code in downstream libraries. Ideally downstream libraries
> should be able to benefit from the changes made in SciPy without any
> substantial refactoring on their end.
>
> I am not personally familiar with the specifics of the ODE project and do
> not know if other candidates are currently pursuing that topic. Hopefully
> one of the mentors for it can respond here.
>
> - Greg
>
>
>
>
> On Wed, Apr 3, 2019 at 10:05 AM Peter Bell <peterbell10 at live.co.uk> wrote:
>
> > Hello,
> >
> >
> >
> > I am interested in applying for Google summer of code and was wondering
> if
> > you
> >
> > are still looking for students?
> >
> >
> >
> > A bit about myself
> >
> > -------------------
> >
> > My name is Peter and I'm in my 4th (penultimate) year of an integrated
> > masters
> >
> > in computational physics. Programming and numerical methods forms a key
> > part of
> >
> > this degree and many of my courses make heavy use of python with cython,
> > numpy,
> >
> > scipy, matplotlib, etc. While my degree is primarily Physics, I have
> taken
> > a
> >
> > number of computer science courses covering software engineering, object
> >
> > oriented design and high performance programming.
> >
> >
> >
> > I also have an interest in open source collaboration and, when time has
> > allowed,
> >
> > have contributed to a few projects via github (@peterbell10). The
> majority
> > of
> >
> > my contributions have been to a minecraft server which I've been
> > contributing to
> >
> > since summer 2017. You can see my pull requests here:
> >
> >
> >
> https://github.com/cuberite/cuberite/pulls?q=is%3Apr+is%3Amerged+author%3Apeterbell10
> >
> >
> >
> > Questions about the projects
> >
> > -----------------------------
> >
> > I have some questions regarding both of the proposed projects.
> >
> >
> >
> > Revamp fftpack:
> >
> > * Is the primary intention to keep the scipy.fftpack interface the same,
> > but add
> >
> >   some mechanism to inject custom implementations? Or will this require
> > changes
> >
> >   to the front-facing interface as well? (e.g. for agreement with
> > numpy.fft)
> >
> > * What should this look like from the user's point of view? e.g.
> >
> >
> >
> >        import scipy.fftpack
> >
> >        import pyFFTW.interfaces.scipy_fftpack as fftw_pack
> >
> >
> >
> >        scipy.fftpack.set_backend(fftw_pack)
> >
> >
> >
> >   where we just provide a module implementing a well-documented backend
> >
> >   interface. Alternatively, fftw_pack could be an object, potentially
> with
> >
> >   its own instances of caches and settings which might allow for more
> >
> >   configuration from the user.
> >
> >
> >
> > Improve ODE solvers (mainly the first 3 tasks):
> >
> > * How much mathematical background is required? I have done a course
> > covering
> >
> >   the mathematics of ODE schemes including RK methods and some variable
> > timestep
> >
> >   methods, but am not familiar with control theory which is mentioned for
> > the
> >
> >   3rd task.
> >
> > * Will developing the test set just involve binding existing
> > implementations to
> >
> >   python for use in a testing framework, or do you expect these to be
> > rewritten
> >
> >   entirely in python or cython?
> >
> >
> >
> >
> >
> > Best regards,
> >
> > Peter
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at python.org
> > https://mail.python.org/mailman/listinfo/scipy-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/scipy-dev/attachments/20190404/484e79ff/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
>
> ------------------------------
>
> End of SciPy-Dev Digest, Vol 186, Issue 10
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190405/06033616/attachment-0001.html>

From andrewjhynes at gmail.com  Sat Apr  6 10:06:26 2019
From: andrewjhynes at gmail.com (Andrew Hynes)
Date: Sat, 6 Apr 2019 10:06:26 -0400
Subject: [SciPy-Dev] [ANN] Release of scikit-spatial package
In-Reply-To: <CABL7CQgNV8gu3oFTwN0X-DDAxqXfig65+r--0y=ez+S_H12Lnw@mail.gmail.com>
References: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
 <CABL7CQgNV8gu3oFTwN0X-DDAxqXfig65+r--0y=ez+S_H12Lnw@mail.gmail.com>
Message-ID: <CAD-yzHabNxhEv9i2OtFjsawYO19fhBiGdVpdUw1c64G67Of-ew@mail.gmail.com>

Hi Ralf,

Thanks for getting back to me.

I'd also be interested in the comparison between scikit-spatial and
> scipy.spatial. It would probably be useful if you added that, as well as
> the SymPy comparison, to the readme of your repo and/or the first page of
> your docs.
>

>From what I can see, there is no overlap between scipy.spatial functions
and those in my package. Do you think my code could be added to
scipy.spatial? I'd be happy to go that route instead of maintaining a
scikit.

Thanks,

Andrew

On Fri, Apr 5, 2019 at 4:20 AM Ralf Gommers <ralf.gommers at gmail.com> wrote:

> Hi Andrew,
>
>
> On Thu, Apr 4, 2019 at 11:29 PM Andrew Hynes <andrewjhynes at gmail.com>
> wrote:
>
>> Hello everyone,
>>
>> I'm completing my master's in computer engineering, and it involved
>> writing several functions for computations in 3D space, such as finding the
>> line of best fit from multiple points and projecting a point onto a line. I
>> decided to package my code into 'scikit-spatial', which provides objects
>> for points, vectors, lines and planes, and computations between them.
>>
>
> Looks interesting.
>
>
>> I know SymPy has similar objects in their geometry package, but my
>> package is based on NumPy for the objects and computations. The Point and
>> Vector objects are actually subclasses of the NumPy ndarray.
>>
>
> I'd also be interested in the comparison between scikit-spatial and
> scipy.spatial. It would probably be useful if you added that, as well as
> the SymPy comparison, to the readme of your repo and/or the first page of
> your docs.
>
>
>> It's my first Python package, so any feedback or contributions would be
>> greatly appreciated. The code is at
>> https://github.com/ajhynes7/scikit-spatial.
>>
>> I apologize if this is the wrong mailing list to post this. The "Scikits"
>> page (https://www.scipy.org/scikits.html) just says "It can however be
>> useful to let people know about it by discussing the new project e.g. on
>> the Scipy mailing lists.", but it doesn't specify which one. Maybe the
>> website can be edited to specify a mailing list for future reference?
>>
>
> Yeah, that website needs some maintenance. An announcement and first
> discussion here is fine. If there's regular discussion happening going
> forward, then it would be good to set up a dedicated list (very easy with
> Google Groups for exampple).
>
> Cheers,
> Ralf
>
>
>> Thanks,
>>
>> Andrew Hynes
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190406/3a9d0ea7/attachment.html>

From f20170920 at goa.bits-pilani.ac.in  Sat Apr  6 17:08:19 2019
From: f20170920 at goa.bits-pilani.ac.in (Anany Shrey Jain)
Date: Sun, 7 Apr 2019 02:38:19 +0530
Subject: [SciPy-Dev] GSoC 2019: Project Proposal
In-Reply-To: <mailman.2071.1554480810.2938.scipy-dev@python.org>
References: <mailman.2071.1554480810.2938.scipy-dev@python.org>
Message-ID: <CAG7Qgjhy-X-vDqxS8sS7SZ8Lv-YdySpwTQKb1QUuXRvXmM4y4w@mail.gmail.com>

Hey ,
Thanks Greg for a detailed reply. I will be working on both
https://github.com/pyFFTW/pyFFTW/pull/256 and
https://github.com/cupy/cupy/issues/1936 as a part of this project. I have
constructed my API implementation based on the `set_backend`  function
approach, but in comparatively cleaner way. I have written my proposal for
this project and here is a link to it:
https://docs.google.com/document/d/1TIiH9j3rPAN--53MwjZz7NFO1GGtxmEH3RiGzvqnEBk/edit?usp=sharing.
Please go through my proposal and if possible send some feedback on it.

-Anany

Message: 1
> Date: Fri, 5 Apr 2019 12:13:15 -0400
> From: Gregory Lee <grlee77 at gmail.com>
> To: SciPy Developers List <scipy-dev at python.org>
> Subject: Re: [SciPy-Dev] GSoC 2019
> Message-ID:
>         <
> CAJR3sXeVPAB+jGB_EdxiDg45jbR4wHzLVjjBk7+RiesT0XMrpw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, Apr 5, 2019 at 4:25 AM Anany Shrey Jain <
> f20170920 at goa.bits-pilani.ac.in> wrote:
>
> > Hey Greg,
> > The project "Revamp FFTPACK" also aims at contributing to third party
> > libraries to fill in functionality gaps. For pyFFTW I can see that work
> on
> > adding Real-to-Real transforms has been going on for a long time. So do I
> > need to continue the work going on in
> > https://github.com/pyFFTW/pyFFTW/pull/256 as a part of this project?
> >
>
> It is not a requirement that you work on the pyFFTW wrappers, but that
> would be a good complement to this project. Here are some thoughts.
>
> 1.) I would first have a mechanism to fall back to the existing
> scipy.fftpack implementations for any functions not currently supported by
> a given backend. pyFFTW currently already falls back to scipy's own
> implementation for DCT and DST transforms (
>
> https://github.com/pyFFTW/pyFFTW/blob/e9966e5d215a00f89156bd88e1d42b884f85df78/pyfftw/interfaces/scipy_fftpack.py#L81-L82
> ).
> The PR you referenced would allow it to use FFTW to perform these
> transforms instead and there would be no remaining functions that fall back
> to scipy.fftpack.
>
> 2.) You can work on adding real-to-real support in supporting libraries,
> but this is a secondary goal to pursue once the SciPy side of the project
> has been completed.
>    pyFFTW builds on FFTW which does already have functions providing
> real-to-real transforms. So what you see in the PR referenced above is
> mainly adding the wrappers for those to pyFFTW.
>
>
>
> > What needs to be done for the other two libraries? Do I need to make a
> > similar PR to other two libraries as well?
> >
> >
> You could potentially try that, but I think that is more of a stretch goal.
> The approach for CuPy or mkl-fft would have to be different, because for
> those two cases the underlying libraries DO NOT have dedicated functions
> implementing the real-to-real transforms. Also, the underlying FFT
> libraries are proprietary, so we cannot propose to add new transforms on
> the C/C++ side. However, it is possible in principle to implement
> real-to-real transforms using only the already existing complex-valued
> transforms (albeit at some additional computational/memory cost). Some
> detailed examples of this are given in the following thread on DSP
> StackExchange:
> https://dsp.stackexchange.com/questions/2807/fast-cosine-transform-via-fft
>
> I think that is probably the only feasible route for real-to-real
> transforms using those two backends. I think whether or not this type of
> implementation would give a performance benefit over just reusing the
> existing scipy.fftpack implementations is unknown.
>
> One FFT-related issues that could be improved in CuPy in a more
> straightforward manner than adding real-to-real support, is improving the
> real-to-complex and complex-to-real support.  These transforms are
> supported by the underlying CUFFT library, but support for this within CuPy
> is incomplete.  One issue related to this was opened at (
> https://github.com/cupy/cupy/issues/1936), but no PR implementing it has
> been made.
>
>
> > For all the three libraries there are SciPy-compatable routines already
> > defined. After getting required information using the newly created
> > interface I need to use them at the backend, right?
> >
>
> Yes, you should rely on the already existing interfaces when implementing
> the backends in SciPy. Any additional 3rd party libraries would have to
> provide a scipy-like interface in order to be compatible for use as a
> backend.
>
>
>
> >
> > -Anany
> >
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Thu, 4 Apr 2019 10:58:27 -0400
> >> From: Gregory Lee <grlee77 at gmail.com>
> >> To: SciPy Developers List <scipy-dev at python.org>
> >> Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 185, Issue 18
> >> Message-ID:
> >>         <
> >> CAJR3sXcJuqQJrDboN5zH-pd7NG-wD8EWCdTCAtQ+vJpnZjKsRw at mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> Hi Anany,
> >>
> >> It is nice to see that you have updated with multiple potential APIs.
> Can
> >> some other core SciPy devs also help give feedback on what SciPy would
> >> find
> >> preferable? Out of the four you proposed, I think something along the
> >> lines
> >> of the second method is cleanest in terms of setting the backend at
> >> runtime. I think having some aspect from your 4th variant where the
> >> default
> >> backend can be read from a configuration file and/or environment
> variable
> >> is also desirable so that the user's desired default can always be
> >> automatically set at import time.
> >>
> >> I disagree with the following specific statement, though:
> >> "It is better to use all the above mentioned ideas because every idea
> has
> >> its own benefits besides it gives user the luxury to choose the method
> >> implementation of backend."
> >>
> >> I do not think we want to provide multiple ways to do the same thing. It
> >> can be confusing to users and more work for devs to maintain. I think
> >> there
> >> should be one method of setting the backend that the user can either
> call
> >> at run time or have it be automatically called based on some sort of
> >> configuration file and/or environment variable(s) at import time.
> >>
> >> - Greg
> >>
> >>
> >> On Tue, Apr 2, 2019 at 2:19 PM Anany Shrey Jain <
> >> f20170920 at goa.bits-pilani.ac.in> wrote:
> >>
> >> > Hey,
> >> > I have already sent the link to the page containing the list of ideas
> >> for
> >> > implementation of new API that I propose for this project. Would you
> >> like
> >> > to add something to it or give some comments on it? The Gsoc proposal
> >> > deadline is 9th of April and I am planning to put all of this in my
> >> > proposal to make it effective . So any more ideas or comments will be
> >> > really helpful for me . Here is the link to the page:
> >> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy .
> >> >
> >> > On Sun, Mar 31, 2019 at 5:23 AM <scipy-dev-request at python.org> wrote:
> >> >
> >> >>
> >> >> Message: 1
> >> >> Date: Sat, 30 Mar 2019 13:31:51 -0400
> >> >> From: Eric Larson <larson.eric.d at gmail.com>
> >> >> To: SciPy Developers List <scipy-dev at python.org>
> >> >> Subject: Re: [SciPy-Dev] GSoC 2019
> >> >> Message-ID:
> >> >>         <
> >> >> CAGu2niVWsKrMukfWcAWAtj-1NBm2utCeh3BOnNku7jNoAcx-kw at mail.gmail.com>
> >> >> Content-Type: text/plain; charset="utf-8"
> >> >>
> >> >> It looks like the main ideas are in these bits of code, but not
> >> explicitly
> >> >> stated. In brief it looks like the proposed API is to add a
> >> `fft_object`
> >> >> kwarg to every function in `scipy.fftpack`. It would be good to
> discuss
> >> >> this choice explicitly -- what advantages and disadvantages it has
> >> >> relative
> >> >> to other approaches (e.g., creating new namespaces, or having a
> >> >> `set_backend` function (and/or context manager) that would change
> >> things
> >> >> under the hood).
> >> >>
> >> >> If you make changes and need more feedback, let us know. The more
> >> specific
> >> >> you can be about what you need feedback on (high level ideas, low
> level
> >> >> implementation, etc.), the better.
> >> >>
> >> >> Eric
> >> >>
> >> >>
> >> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
> >> >> f20170920 at goa.bits-pilani.ac.in> wrote:
> >> >>
> >> >> > Hey,
> >> >> > I went through the idea list of Scipy for this years's GSoC and I
> >> intend
> >> >> > to work towards the idea of revamping the Scipy's fftpack. I have
> >> >> already
> >> >> > been contributing to Scipy since the end of last year and I have
> some
> >> >> > knowledge about Fourier transforms as it was the part of my
> >> discipline.
> >> >> I
> >> >> > could not take part in this discussion earlier because my mid
> >> semester
> >> >> > exams were going on, but since they are now over so I can devote as
> >> much
> >> >> > time as required on this project. I have already created a github
> >> page
> >> >> with
> >> >> > some code snippets and functionalities that we can implement, here
> is
> >> >> the
> >> >> > link to it:
> >> >> >
> https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
> >> .
> >> >> >
> >> >> > Cheers,
> >> >> > Anany Jain
> >> >> >
> >> >> > _______________________________________________
> >> >> > SciPy-Dev mailing list
> >> >> > SciPy-Dev at python.org
> >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >
> >> >> -------------- next part --------------
> >> >> An HTML attachment was scrubbed...
> >> >> URL: <
> >> >>
> >>
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/f1755dfb/attachment-0001.html
> >> >> >
> >> >>
> >> >> ------------------------------
> >> >>
> >> >> Message: 2
> >> >> Date: Sat, 30 Mar 2019 19:38:41 -0400
> >> >> From: Gregory Lee <grlee77 at gmail.com>
> >> >> To: SciPy Developers List <scipy-dev at python.org>
> >> >> Subject: Re: [SciPy-Dev] GSoC 2019
> >> >> Message-ID:
> >> >>         <CAJR3sXfnnr-0JO87gLbhh-7b-w=KjaNpac+F+FHTeFt2K=_
> >> >> QMw at mail.gmail.com>
> >> >> Content-Type: text/plain; charset="utf-8"
> >> >>
> >> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
> >> >> f20170920 at goa.bits-pilani.ac.in> wrote:
> >> >>
> >> >> > Hey,
> >> >> > I went through the idea list of Scipy for this years's GSoC and I
> >> intend
> >> >> > to work towards the idea of revamping the Scipy's fftpack. I have
> >> >> already
> >> >> > been contributing to Scipy since the end of last year and I have
> some
> >> >> > knowledge about Fourier transforms as it was the part of my
> >> discipline.
> >> >> I
> >> >> > could not take part in this discussion earlier because my mid
> >> semester
> >> >> > exams were going on, but since they are now over so I can devote as
> >> much
> >> >> > time as required on this project. I have already created a github
> >> page
> >> >> with
> >> >> > some code snippets and functionalities that we can implement, here
> is
> >> >> the
> >> >> > link to it:
> >> >> >
> https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
> >> .
> >> >> >
> >> >> > Cheers,
> >> >> > Anany Jain
> >> >> >
> >> >> > _______________________________________________
> >> >> > SciPy-Dev mailing list
> >> >> > SciPy-Dev at python.org
> >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>
> >> >>
> >> >> Hi Anany,
> >> >>
> >> >> Thank you for your interest in GSOC with SciPy!  It's great to see
> that
> >> >> you
> >> >> are already thinking about a potential API and learning about the 3rd
> >> >> party
> >> >> FFT libraries. Along the lines of Eric's comment, think about what
> this
> >> >> API
> >> >> choice implies for users of libraries built upon SciPy. Would users
> of
> >> 3rd
> >> >> party libraries that rely on SciPy's FFTs be immediately able to take
> >> >> advantage of a differentf FFT backend in this scenario? (in other
> >> words,
> >> >> the case where the user is not calling scipy.fftpack.fft directly but
> >> is
> >> >> using it only indirectly via a function in a downstream library).
> >> >>
> >> >> Matplotlib is an example of an existing Python library supporting
> >> multiple
> >> >> backends that can be considered for comparison (see:
> >> >> https://matplotlib.org/faq/usage_faq.html#what-is-a-backend). Think
> >> about
> >> >> the relative benefits/drawbacks of some of the methods they use for
> >> >> setting
> >> >> a backend there as compared to the approach proposed for FFTs here.
> >> >>
> >> >> Another thing that should be considered: pyFFTW, MKL and CuPy already
> >> have
> >> >> some functions that match the existing scipy.fftpack API, but they
> may
> >> >> have
> >> >> one or more additional arguments particular to features of that
> >> library.
> >> >> How would you propose to deal with supporting additional optional
> >> >> arguments
> >> >> on the SciPy end?
> >> >>
> >> >> One other minor comment: I know that the blog post you made may be
> >> serving
> >> >> partly as personal notes, but please do not directly copy sections of
> >> text
> >> >> (e.g. the description of BLAS/LAPACK libraries) from elsewhere
> without
> >> >> attribution when writing a final proposal. (Also, the FFT functions
> are
> >> >> separate from the BLAS/LAPACK functions in MKL, so you will not need
> to
> >> >> discuss BLAS or LAPACK specifically in your proposal)
> >> >>
> >> >> - Greg
> >> >> -------------- next part --------------
> >> >> An HTML attachment was scrubbed...
> >> >> URL: <
> >> >>
> >>
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/c1351e7e/attachment-0001.html
> >> >> >
> >> >>
> >> >> ------------------------------
> >> >>
> >> >> Message: 3
> >> >> Date: Sat, 30 Mar 2019 19:53:02 -0400
> >> >> From: Gregory Lee <grlee77 at gmail.com>
> >> >> To: SciPy Developers List <scipy-dev at python.org>
> >> >> Subject: Re: [SciPy-Dev] GSoC 2019
> >> >> Message-ID:
> >> >>         <CAJR3sXdcPMAn_DETF8W-=
> >> >> MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw at mail.gmail.com>
> >> >> Content-Type: text/plain; charset="utf-8"
> >> >>
> >> >> Hi Gopi,
> >> >>
> >> >> I am not sure I follow exactly what you are suggesting here. Are you
> >> >> proposing that the `fftpackN` variable in your example would be a
> >> Python
> >> >> module corresponding to a given backend? If so, why is an array of
> >> data,
> >> >> z,
> >> >> being passed into the newAPI function here? I don't see why a data
> >> array
> >> >> should be needed at all to choose a backend.
> >> >>
> >> >> Please also see my response to Anany's recent post on this list for a
> >> >> couple of other suggestions of things to consider in terms of the
> API.
> >> >>
> >> >> - Greg
> >> >>
> >> >>
> >> >> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
> >> >> deathcoderx at gmail.com>
> >> >> wrote:
> >> >>
> >> >> > Hey,
> >> >> > I went through the code and got some ideas.
> >> >> > So what will happen is:
> >> >> > First, we will declare FFTW as we use them normally.
> >> >> >
> >> >> > z = np.random.rand(2, 128, 64)
> >> >> > pyfftw.FFTW(z, axes=(-1, ))
> >> >> > ..
> >> >> > ..
> >> >> > Now after declaring our basic work to shift to another FFTpack,
> what
> >> we
> >> >> > can do is:
> >> >> > fftPackN= newAPI(z, pack = 'PYFFTW');
> >> >> >
> >> >> > Pack will take the name of the 3rd party FFT pack which we want to
> >> use.
> >> >> > Suggestions needed.
> >> >> >
> >> >> > Cheers.
> >> >> >
> >> >> >
> >> >>
> >> >> >
> >> >> > On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <
> larson.eric.d at gmail.com
> >> >
> >> >> > wrote:
> >> >> >
> >> >> >> After reading the related issues and thinking about the problem,
> >> >> perhaps
> >> >> >> the best first step is you come up with some initial API proposal.
> >> >> >>
> >> >> >> One way to work through the process is to think about the use
> cases
> >> >> that
> >> >> >> we want to support. How should users actually write code to use
> the
> >> new
> >> >> >> functionality? You can start with short code snippets that do not
> >> work
> >> >> >> currently, but should work for users at the end of the project.
> Then
> >> >> think
> >> >> >> about what needs to change inside SciPy for these code snippets to
> >> >> work.
> >> >> >> This can become an iterative process as you realize that the SciPy
> >> >> changes
> >> >> >> might be better or easier with changes to the user-facing API,
> etc.
> >> >> >>
> >> >> >> Eric
> >> >> >>
> >> >> >>
> >> >> >> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
> >> >> >> deathcoderx at gmail.com> wrote:
> >> >> >>
> >> >> >>> Hey,
> >> >> >>> As proposal submission period started I want to discuss a bit
> anobt
> >> >> how
> >> >> >>> can we implement the API.
> >> >> >>> I would very much appriciate inputs and guidance.
> >> >> >>>
> >> >> >>> Cheers.
> >> >> >>>
> >> >> >>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <
> >> larson.eric.d at gmail.com>
> >> >> >>> wrote:
> >> >> >>>
> >> >> >>>> The best way to figure that out is probably to take a look at
> >> some of
> >> >> >>>> the existing (minor) SciPy GitHub issues and try to work on one
> or
> >> >> two that
> >> >> >>>> you feel like working on. Actually trying to work out how to
> >> >> contribute
> >> >> >>>> code changes (as independently as possible/reasonable based on
> the
> >> >> existing
> >> >> >>>> guides/docs already discoverable online) will quickly highlight
> >> >> things that
> >> >> >>>> need to be learned. Some of the general things are the SciPy
> >> >> contributing
> >> >> >>>> guidelines, standard GitHub PR workflow, communication with
> >> >> reviewers, and
> >> >> >>>> so forth.
> >> >> >>>>
> >> >> >>>> For this particular project, it's important to understand the
> >> various
> >> >> >>>> flavors and properties of FFT in SciPy (real, complex,
> >> n-dimensional,
> >> >> >>>> caching plans, etc.) as well as other projects like NumPy, CuPy,
> >> and
> >> >> >>>> pyFFTW. Some of this can be learned and improved upon as part of
> >> >> GSoC, but
> >> >> >>>> the more you know and can demonstrate / put into practice
> >> knowledge
> >> >> of
> >> >> >>>> before the applications are reviewed, the better.
> >> >> >>>>
> >> >> >>>> Eric
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
> >> >> >>>> deathcoderx at gmail.com> wrote:
> >> >> >>>>
> >> >> >>>>> Thank you for the detailed reply.
> >> >> >>>>> I will keep these point in mind while preparing my proposal.
> >> Apart
> >> >> >>>>> from proposal, what skills shall I improve so that I can
> >> contribute
> >> >> more
> >> >> >>>>> effectively and efficiently.
> >> >> >>>>>
> >> >> >>>>> Cheers.
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <
> >> larson.eric.d at gmail.com>
> >> >> >>>>> wrote:
> >> >> >>>>>
> >> >> >>>>>> There are a number of considerations that would be good to
> >> address.
> >> >> >>>>>> I'd start by considering the things that are typically
> >> considered
> >> >> >>>>>> when making changes to SciPy
> >> >> >>>>>> <
> >> >>
> >>
> https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy
> >> >> >,
> >> >> >>>>>> but I'd expand it to a longer list since the scope is bigger
> >> than
> >> >> a typical
> >> >> >>>>>> single PR. The list would contain (at least):
> >> >> >>>>>>
> >> >> >>>>>> - what will the user-facing API / contract be?
> >> >> >>>>>> - what in SciPy needs to change to allow it (internals /
> >> >> >>>>>> implementation outline, perhaps skeleton functions/classes)?
> >> >> >>>>>> - what examples should we show users (in general this ends up
> >> being
> >> >> >>>>>> just simple use cases of the API)?
> >> >> >>>>>> - how will we test it for correctness?
> >> >> >>>>>> - how will we benchmark it to prevent performance regressions?
> >> >> >>>>>> - how can we break up the work for these steps (if possible)
> >> into
> >> >> >>>>>> separable, sequential (or -- better but not usually possible
> --
> >> >> >>>>>> independent) PRs?
> >> >> >>>>>>
> >> >> >>>>>> You might notice that none of these points are actually all
> that
> >> >> >>>>>> specific to the FFT project, but can be generally applicable
> to
> >> >> GSoC
> >> >> >>>>>> projects. For the FFT project, I would say "how do we build
> the
> >> >> backend" is
> >> >> >>>>>> indeed implicitly contained / outlined in these bullet points.
> >> And
> >> >> as with
> >> >> >>>>>> most projects, the first two points (and possibly the last)
> will
> >> >> probably
> >> >> >>>>>> be the most challenging to sort out.
> >> >> >>>>>>
> >> >> >>>>>> Eric
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
> >> >> >>>>>> deathcoderx at gmail.com> wrote:
> >> >> >>>>>>
> >> >> >>>>>>> Hey Eric,
> >> >> >>>>>>> So for my proposal, shall I include how can we built a back
> >> end?
> >> >> >>>>>>> What all points shall I include to make it effective?
> >> >> >>>>>>>
> >> >> >>>>>>> Cheers.
> >> >> >>>>>>>
> >> >> >>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <
> >> larson.eric.d at gmail.com
> >> >> >
> >> >> >>>>>>> wrote:
> >> >> >>>>>>>
> >> >> >>>>>>>> That would be me -- don't worry, I'm on this list, as are
> >> >> >>>>>>>> (presumably) other developers interested in the discussion,
> so
> >> >> no need to
> >> >> >>>>>>>> document elsewhere for now from our end. It looks like Greg
> >> has
> >> >> summarized
> >> >> >>>>>>>> the current status and thoughts we've had, so I don't have
> >> much
> >> >> to add at
> >> >> >>>>>>>> this point.
> >> >> >>>>>>>>
> >> >> >>>>>>>> Eric
> >> >> >>>>>>>>
> >> >> >>>>>>>>
> >> >> >>>>>>>>
> >> >> >>>>>>>>
> >> >> >>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
> >> >> >>>>>>>> deathcoderx at gmail.com> wrote:
> >> >> >>>>>>>>
> >> >> >>>>>>>>> Hey Greg,
> >> >> >>>>>>>>> I got the basic idea about what we want to implement this
> >> year.
> >> >> >>>>>>>>> Our first priority is to create a backend for 3rd party
> >> >> fftpacks.
> >> >> >>>>>>>>> We can create API using Python and Flask or any other
> >> suitable
> >> >> framework.
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> I thought this discussion was going on on SciPy Developer
> >> List
> >> >> >>>>>>>>> only. So do I need to document it all and post it somewhere
> >> so
> >> >> that other
> >> >> >>>>>>>>> contributors can see this?
> >> >> >>>>>>>>> Also, I couldn't find any contact info regarding Eric. It
> >> would
> >> >> be
> >> >> >>>>>>>>> very helpful if we include him in this discussion as this
> is
> >> a
> >> >> roadmap for
> >> >> >>>>>>>>> GSoC project and I can also get more insight into the
> project
> >> >> and expected
> >> >> >>>>>>>>> outcomes.
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> Cheers.
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <
> >> grlee77 at gmail.com>
> >> >> >>>>>>>>> wrote:
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
> >> >> >>>>>>>>>> deathcoderx at gmail.com> wrote:
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>> Hey Gregory,
> >> >> >>>>>>>>>>> I went through the idea and I am very much interested in
> >> >> working
> >> >> >>>>>>>>>>> on it. I had Fourier Transforms as a part of my academic
> >> >> course, so I am
> >> >> >>>>>>>>>>> well aware with basic concepts.
> >> >> >>>>>>>>>>> One thing I want to discuss is, its mentioned that we
> have
> >> to
> >> >> >>>>>>>>>>> create a backend system for 3rd party FFTpacks so my
> dobuts
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>> 1. How are we going to create API?
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> This will needed to be decided on in consensus with the
> >> SciPy
> >> >> >>>>>>>>>> developers and user community. I am mentoring for the
> >> project
> >> >> as a
> >> >> >>>>>>>>>> contributor here and a maintainer of the related pyFFTW
> >> >> package, but I am
> >> >> >>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core
> dev
> >> >> here). I have
> >> >> >>>>>>>>>> not discussed the API in any detail with the SciPy team at
> >> >> this stage.
> >> >> >>>>>>>>>> Working out details of what the API should look like and
> >> >> working to
> >> >> >>>>>>>>>> finalize that in collaboration with the community will be
> a
> >> >> primary task
> >> >> >>>>>>>>>> during the early part of the GSOC project.
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> 2. After the creation of backend will user at the time of
> >> >> >>>>>>>>>>> installation of SciPy will decide what all 3rd party
> >> FFTpacks
> >> >> he needs or
> >> >> >>>>>>>>>>> we will include some by default?
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> The idea is to allow users to opt-in to a different FFT
> >> >> backend
> >> >> >>>>>>>>>> at run time, but these alternative libraries will not be
> >> >> distributed with
> >> >> >>>>>>>>>> SciPy itself due to incompatible software licenses (pyFFTW
> >> and
> >> >> mkl-fft) or
> >> >> >>>>>>>>>> a requirement for specific hardware (CuPy requires an
> NVIDIA
> >> >> GPU). SciPy
> >> >> >>>>>>>>>> will continue to offer its own bundled FFT library
> >> (currently
> >> >> fftpack, but
> >> >> >>>>>>>>>> this could be switched to pocketfft as discussed in the
> >> ideas
> >> >> page). The
> >> >> >>>>>>>>>> purpose of the backend interface is to provide a
> convenient
> >> >> way for users
> >> >> >>>>>>>>>> to have third party libraries perform the FFTs instead,
> but
> >> >> under the
> >> >> >>>>>>>>>> existing scipy.fftpack API. This is motivated by a desire
> by
> >> >> end users and
> >> >> >>>>>>>>>> downstream projects to have features such as
> multi-threading
> >> >> (pyFFTW and
> >> >> >>>>>>>>>> mkl-fft) or GPU support (CuPy) that are not implemented in
> >> >> scipy.fftpack.
> >> >> >>>>>>>>>> Ultimately it will be up to users that opt-in to using
> these
> >> >> other
> >> >> >>>>>>>>>> libraries to confirm that the license terms and are
> >> compatible
> >> >> with their
> >> >> >>>>>>>>>> use case.
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev
> mailing
> >> >> >>>>>>>>>> lists prefers replies **below** the email you are replying
> >> to
> >> >> so people can
> >> >> >>>>>>>>>> more easily follow the thread of discussion. There are
> some
> >> >> guidelines at:
> >> >> >>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> I will research more about how to implement a backend
> myself
> >> >> and
> >> >> >>>>>>>>>>> will let you know as soon as I come up with something
> new.
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>> CHeers,
> >> >> >>>>>>>>>>> Greg
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <
> >> >> grlee77 at gmail.com>
> >> >> >>>>>>>>>>> wrote:
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
> >> >> >>>>>>>>>>>> deathcoderx at gmail.com> wrote:
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started fixing
> >> some
> >> >> >>>>>>>>>>>>> bugs, also made some pull request. Can anyone suggest
> me
> >> >> how should I
> >> >> >>>>>>>>>>>>> proceed further?
> >> >> >>>>>>>>>>>>> _______________________________________________
> >> >> >>>>>>>>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>>>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> Hi Gopi,
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> I think you have probably already found it, but the GSOC
> >> >> >>>>>>>>>>>> project we have already identified mentors for in SciPy
> is
> >> >> here:
> >> >> >>>>>>>>>>>>
> >> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> If this is a project you are interested in then I would
> >> start
> >> >> >>>>>>>>>>>> thinking about what the FFT interface would look like
> and
> >> >> reviewing some of
> >> >> >>>>>>>>>>>> the past/present issues related to fftpack / FFT in
> SciPy.
> >> >> Please ask
> >> >> >>>>>>>>>>>> questions you have related to that project here so that
> >> you
> >> >> can clarify
> >> >> >>>>>>>>>>>> what would be involved in writing a successful
> >> application.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> If you have a different idea in mind you can propose it
> >> here,
> >> >> >>>>>>>>>>>> but you should do that soon, because it will be
> necessary
> >> to
> >> >> determine if
> >> >> >>>>>>>>>>>> there is interest from the SciPy team before you spend
> >> time
> >> >> coming up with
> >> >> >>>>>>>>>>>> a detailed proposal. We have to determine if a project
> >> >> sounds feasible to
> >> >> >>>>>>>>>>>> complete for GSOC and if appropriate mentors can be
> >> >> identified.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> Ultimately, you will need to submit an application to
> >> SciPy
> >> >> >>>>>>>>>>>> between March 25th - April 9th.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> Cheers,
> >> >> >>>>>>>>>>>> Greg
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> _______________________________________________
> >> >> >>>>>>>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>> _______________________________________________
> >> >> >>>>>>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>> _______________________________________________
> >> >> >>>>>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>> _______________________________________________
> >> >> >>>>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>>>
> >> >> >>>>>>>> _______________________________________________
> >> >> >>>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>>
> >> >> >>>>>>> _______________________________________________
> >> >> >>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>
> >> >> >>>>>> _______________________________________________
> >> >> >>>>>> SciPy-Dev mailing list
> >> >> >>>>>> SciPy-Dev at python.org
> >> >> >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>
> >> >> >>>>> _______________________________________________
> >> >> >>>>> SciPy-Dev mailing list
> >> >> >>>>> SciPy-Dev at python.org
> >> >> >>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>
> >> >> >>>> _______________________________________________
> >> >> >>>> SciPy-Dev mailing list
> >> >> >>>> SciPy-Dev at python.org
> >> >> >>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>
> >> >> >>> _______________________________________________
> >> >> >>> SciPy-Dev mailing list
> >> >> >>> SciPy-Dev at python.org
> >> >> >>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>
> >> >> >> _______________________________________________
> >> >> >> SciPy-Dev mailing list
> >> >> >> SciPy-Dev at python.org
> >> >> >> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>
> >> >> > _______________________________________________
> >> >> > SciPy-Dev mailing list
> >> >> > SciPy-Dev at python.org
> >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >
> >> >> -------------- next part --------------
> >> >> An HTML attachment was scrubbed...
> >> >> URL: <
> >> >>
> >>
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/54f38250/attachment.html
> >> >> >
> >> >>
> >> >> ------------------------------
> >> >>
> >> >> Subject: Digest Footer
> >> >>
> >> >> _______________________________________________
> >> >> SciPy-Dev mailing list
> >> >> SciPy-Dev at python.org
> >> >> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>
> >> >>
> >> >> ------------------------------
> >> >>
> >> >> End of SciPy-Dev Digest, Vol 185, Issue 18
> >> >> ******************************************
> >> >>
> >> > _______________________________________________
> >> > SciPy-Dev mailing list
> >> > SciPy-Dev at python.org
> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> >> >
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <
> >>
> http://mail.python.org/pipermail/scipy-dev/attachments/20190404/1a670020/attachment.html
> >> >
> >>
> >> ------------------------------
> >>
> >> Subject: Digest Footer
> >>
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at python.org
> >> https://mail.python.org/mailman/listinfo/scipy-dev
> >>
> >>
> >> ------------------------------
> >>
> >> End of SciPy-Dev Digest, Vol 186, Issue 11
> >> ******************************************
> >>
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at python.org
> > https://mail.python.org/mailman/listinfo/scipy-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/scipy-dev/attachments/20190405/cc4019f5/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
>
> ------------------------------
>
> End of SciPy-Dev Digest, Vol 186, Issue 15
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190407/0d37de9c/attachment-0001.html>

From nikolay.mayorov at zoho.com  Sat Apr  6 19:04:24 2019
From: nikolay.mayorov at zoho.com (Nikolay Mayorov)
Date: Sun, 07 Apr 2019 04:04:24 +0500
Subject: [SciPy-Dev] GSoC 2019 Projects
In-Reply-To: <CABL7CQh-wK7FkvFJiRHv=JnXMQTF=EcFE9azfWEKuxUObuGL9Q@mail.gmail.com>
References: <DB6PR04MB32069A19ECEABBA9433E85158E570@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAJR3sXcsQATgJ952UK+Bigqf-L8EVL0hS=XMWahNyZKHVhcs0Q@mail.gmail.com>
 <DB6PR04MB32063F059BECBDD4962BF9698E510@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAJR3sXci50WD3_gvJYSFMSZyT1pQzau-wf0_8ptMw-6jWSYYVA@mail.gmail.com>
 <CABL7CQh-wK7FkvFJiRHv=JnXMQTF=EcFE9azfWEKuxUObuGL9Q@mail.gmail.com>
Message-ID: <169f4e556ae.adae50bb167377.6750662263743187826@zoho.com>

(I can't determine whether my previous reply gone through, I had some connection problems at that time, so I'm repeating it to be sure).



Hi, Peter!



About ODE project. First of all I must admit that it is not very well thought, it's just something I decided would be possible to do if a right student came along.



* How much mathematical background is required? I have done a course covering

? the mathematics of ODE schemes including RK methods and some variable timestep

? methods, but am not familiar with control theory which is mentioned for the

? 3rd task.










It really depends on how you feel about that yourself. We are happy to consider any motivated student who will write a good proposal and make some contributions to scipy (as required by PSF). For the time step selection problem --- my intuition is that this problem is more about empirical tuning and experimenting rather than some rigorous theory.



* Will developing the test set just involve binding existing implementations to

? python for use in a testing framework, or do you expect these to be rewritten

? entirely in python or cython?










I believe it should be made a part of scipy benchmarks (https://github.com/scipy/scipy/tree/master/benchmarks). So the problem definitions are supposed to be coded just in Python.





- Nikolay



Sent using https://www.zoho.com/mail/






---- On Fri, 05 Apr 2019 22:49:35 +0500 Ralf Gommers <ralf.gommers at gmail.com> wrote ----







On Fri, Apr 5, 2019 at 6:30 PM Gregory Lee <mailto:grlee77 at gmail.com> wrote:





On Fri, Apr 5, 2019 at 7:34 AM Peter Bell <mailto:peterbell10 at live.co.uk> wrote:

Hi Greg,

?

Thanks for your response.

?

>Ideally there should also be some way to provide additional arguments specific to those implementations

?

I see that pyFFTW adds additional keyword args to the fftpack functions. In your opinion is it okay to pass backend dependant arguments to SciPy? I think most of the same functionality could be done via global configuration and/or some generally applicable arguments could be incorporated into
 the fftpack API directly in a backwords compatible manner. 

For example, pyFFTW?s ?planner_effort? is quite backend specific so would be global. Whereas ?overwrite_input? option might make sense for other FFT implementations and not just FFTW specifically; so could be added as an argument with a backwards compatible default value.








Peter








I think one possibility on the SciPy side would be to just extend the signature of the scipy functions to add **kwargs. Then any additional keyword arguments would be passed onto the underlying backend's fft routine. I would be curious of the opinion of other scipy dev's opinion on what they would prefer. I think the problem with the **kwargs approach is that if downstream libraries start relying on kwargs specific to a given backend then it may no longer be possible for users of those libraries to override the choice of backend.



A simpler option on the SciPy side would be to not support passing additional keyword arguments to the backends at all.






I think backend-specific keywords are hard to support without making the API uglier, and the value is limited - if your code has become specific to one backend, then you may as well use that backend directly right?

?

The obvious downside of that approach is that it would prevent using some potentially beneficial aspects of the underlying libraries. For pyFFTW you can configure some things like the default number of threads and planner effort without passing in arguments, so arguments for those are not strictly necessary. Similarly, I think MKL respects a MKL_NUM_THREADS environment variable.






There will be a way to set the number of MKL, OpenBLAS and OpenMP threads in NumPy soon probably:?https://github.com/numpy/numpy/pull/13136



Cheers,

Ralf










?

?

From: SciPy-Dev <scipy-dev-bounces+peterbell10=mailto:live.co.uk at python.org> On Behalf Of Gregory Lee
 Sent: 04 April 2019 15:42
 To: SciPy Developers List <mailto:scipy-dev at python.org>
 Subject: Re: [SciPy-Dev] GSoC 2019 Projects
?

Hi Peter,


?


Yes, the application period is still open for GSOC, although the final deadline is the 9th, so time is becoming fairly short to get feedback on proposals.


?


A few other students have expressed interest in the FFT-based backends, but any interested candidates are welcome to apply. Please see some prior posts on this lists for some discussions related to that project. The primary intention is
 to allow 3rd party implementations to override the ones provided by SciPy when requested. Ideally there should also be some way to provide additional arguments specific to those implementations (e.g. specifying number of threads, planner effort, etc in the
 case of PyFFTW). We do not want any breaking changes to the existing scipy.fftpack interfaces as we need to maintain backwards compatibility with a lot of preexisting code in downstream libraries. Ideally downstream libraries should be able to benefit from
 the changes made in SciPy without any substantial refactoring on their end.


?


I am not personally familiar with the specifics of the ODE project and do not know if other candidates are currently pursuing that topic. Hopefully one of the mentors for it can respond here.


?


- Greg


?


?


?



?

On Wed, Apr 3, 2019 at 10:05 AM Peter Bell <mailto:peterbell10 at live.co.uk> wrote:


Hello,

?

I am interested in applying for Google summer of code and was wondering if you

are still looking for students?

?

A bit about myself

-------------------

My name is Peter and I'm in my 4th (penultimate) year of an integrated masters

in computational physics. Programming and numerical methods forms a key part of

this degree and many of my courses make heavy use of python with cython, numpy,

scipy, matplotlib, etc. While my degree is primarily Physics, I have taken a

number of computer science courses covering software engineering, object

oriented design and high performance programming.

?

I also have an interest in open source collaboration and, when time has allowed,

have contributed to a few projects via github (@peterbell10). The majority of

my contributions have been to a minecraft server which I've been contributing to

since summer 2017. You can see my pull requests here:

https://github.com/cuberite/cuberite/pulls?q=is%3Apr+is%3Amerged+author%3Apeterbell10

?

Questions about the projects

-----------------------------

I have some questions regarding both of the proposed projects.

?

Revamp fftpack:

* Is the primary intention to keep the scipy.fftpack interface the same, but add

? some mechanism to inject custom implementations? Or will this require changes

? to the front-facing interface as well? (e.g. for agreement with numpy.fft)

* What should this look like from the user's point of view? e.g.

?

?????? import scipy.fftpack

?????? import pyFFTW.interfaces.scipy_fftpack as fftw_pack

?

?????? scipy.fftpack.set_backend(fftw_pack)

?

? where we just provide a module implementing a well-documented backend

? interface. Alternatively, fftw_pack could be an object, potentially with

? its own instances of caches and settings which might allow for more

? configuration from the user.

?

Improve ODE solvers (mainly the first 3 tasks):

* How much mathematical background is required? I have done a course covering

? the mathematics of ODE schemes including RK methods and some variable timestep

? methods, but am not familiar with control theory which is mentioned for the

? 3rd task.

* Will developing the test set just involve binding existing implementations to

? python for use in a testing framework, or do you expect these to be rewritten

? entirely in python or cython?

?

?

Best regards,

Peter




_______________________________________________

 SciPy-Dev mailing list

 mailto:SciPy-Dev at python.org

 https://mail.python.org/mailman/listinfo/scipy-dev






_______________________________________________

 SciPy-Dev mailing list

 mailto:SciPy-Dev at python.org

 https://mail.python.org/mailman/listinfo/scipy-dev




_______________________________________________

 SciPy-Dev mailing list

 mailto:SciPy-Dev at python.org

 https://mail.python.org/mailman/listinfo/scipy-dev




_______________________________________________

SciPy-Dev mailing list 

mailto:SciPy-Dev at python.org 

https://mail.python.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190407/2415cd68/attachment-0001.html>

From ralf.gommers at gmail.com  Sun Apr  7 14:07:18 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 7 Apr 2019 20:07:18 +0200
Subject: [SciPy-Dev] [ANN] Release of scikit-spatial package
In-Reply-To: <CAD-yzHabNxhEv9i2OtFjsawYO19fhBiGdVpdUw1c64G67Of-ew@mail.gmail.com>
References: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
 <CABL7CQgNV8gu3oFTwN0X-DDAxqXfig65+r--0y=ez+S_H12Lnw@mail.gmail.com>
 <CAD-yzHabNxhEv9i2OtFjsawYO19fhBiGdVpdUw1c64G67Of-ew@mail.gmail.com>
Message-ID: <CABL7CQj5H4ydVB577kFe_7CRnE1_5Q4zJGygrXb7zHx57zsVuA@mail.gmail.com>

On Sat, Apr 6, 2019 at 4:05 PM Andrew Hynes <andrewjhynes at gmail.com> wrote:

> Hi Ralf,
>
> Thanks for getting back to me.
>
> I'd also be interested in the comparison between scikit-spatial and
>> scipy.spatial. It would probably be useful if you added that, as well as
>> the SymPy comparison, to the readme of your repo and/or the first page of
>> your docs.
>>
>
> From what I can see, there is no overlap between scipy.spatial functions
> and those in my package. Do you think my code could be added to
> scipy.spatial?
>

I'm not sure. Features like the intersections between planes seems to be
similar in nature to the scipy.spatial.rotation or
https://docs.scipy.org/doc/scipy-0.19.1/reference/generated/scipy.spatial.HalfspaceIntersection.html.
I'm not an expert though and don't have much of a vision what does and does
not belong in scipy.spatial. So I'll let others answer that question.

Cheers,
Ralf



> I'd be happy to go that route instead of maintaining a scikit.
>
> Thanks,
>
> Andrew
>
> On Fri, Apr 5, 2019 at 4:20 AM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>> Hi Andrew,
>>
>>
>> On Thu, Apr 4, 2019 at 11:29 PM Andrew Hynes <andrewjhynes at gmail.com>
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I'm completing my master's in computer engineering, and it involved
>>> writing several functions for computations in 3D space, such as finding the
>>> line of best fit from multiple points and projecting a point onto a line. I
>>> decided to package my code into 'scikit-spatial', which provides objects
>>> for points, vectors, lines and planes, and computations between them.
>>>
>>
>> Looks interesting.
>>
>>
>>> I know SymPy has similar objects in their geometry package, but my
>>> package is based on NumPy for the objects and computations. The Point and
>>> Vector objects are actually subclasses of the NumPy ndarray.
>>>
>>
>> I'd also be interested in the comparison between scikit-spatial and
>> scipy.spatial. It would probably be useful if you added that, as well as
>> the SymPy comparison, to the readme of your repo and/or the first page of
>> your docs.
>>
>>
>>> It's my first Python package, so any feedback or contributions would be
>>> greatly appreciated. The code is at
>>> https://github.com/ajhynes7/scikit-spatial.
>>>
>>> I apologize if this is the wrong mailing list to post this. The
>>> "Scikits" page (https://www.scipy.org/scikits.html) just says "It can
>>> however be useful to let people know about it by discussing the new project
>>> e.g. on the Scipy mailing lists.", but it doesn't specify which one.
>>> Maybe the website can be edited to specify a mailing list for future
>>> reference?
>>>
>>
>> Yeah, that website needs some maintenance. An announcement and first
>> discussion here is fine. If there's regular discussion happening going
>> forward, then it would be good to set up a dedicated list (very easy with
>> Google Groups for exampple).
>>
>> Cheers,
>> Ralf
>>
>>
>>> Thanks,
>>>
>>> Andrew Hynes
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190407/1d41c795/attachment.html>

From andrewjhynes at gmail.com  Sun Apr  7 20:10:56 2019
From: andrewjhynes at gmail.com (Andrew Hynes)
Date: Sun, 7 Apr 2019 20:10:56 -0400
Subject: [SciPy-Dev] [ANN] Release of scikit-spatial package
In-Reply-To: <CABL7CQj5H4ydVB577kFe_7CRnE1_5Q4zJGygrXb7zHx57zsVuA@mail.gmail.com>
References: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
 <CABL7CQgNV8gu3oFTwN0X-DDAxqXfig65+r--0y=ez+S_H12Lnw@mail.gmail.com>
 <CAD-yzHabNxhEv9i2OtFjsawYO19fhBiGdVpdUw1c64G67Of-ew@mail.gmail.com>
 <CABL7CQj5H4ydVB577kFe_7CRnE1_5Q4zJGygrXb7zHx57zsVuA@mail.gmail.com>
Message-ID: <CAD-yzHbZ+PQ6rMTXJoz-1nfkMcyhrTk0a5RCK_ZUeujz8WUazw@mail.gmail.com>

>
> I'm not sure. Features like the intersections between planes seems to be
> similar in nature to the scipy.spatial.rotation or
> https://docs.scipy.org/doc/scipy-0.19.1/reference/generated/scipy.spatial.HalfspaceIntersection.html.
> I'm not an expert though and don't have much of a vision what does and does
> not belong in scipy.spatial. So I'll let others answer that question.


Ok, I will ask. Should I start a new thread on this mailing list or make a
pull request on github?

Andrew

On Sun, Apr 7, 2019 at 2:07 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Sat, Apr 6, 2019 at 4:05 PM Andrew Hynes <andrewjhynes at gmail.com>
> wrote:
>
>> Hi Ralf,
>>
>> Thanks for getting back to me.
>>
>> I'd also be interested in the comparison between scikit-spatial and
>>> scipy.spatial. It would probably be useful if you added that, as well as
>>> the SymPy comparison, to the readme of your repo and/or the first page of
>>> your docs.
>>>
>>
>> From what I can see, there is no overlap between scipy.spatial functions
>> and those in my package. Do you think my code could be added to
>> scipy.spatial?
>>
>
> I'm not sure. Features like the intersections between planes seems to be
> similar in nature to the scipy.spatial.rotation or
> https://docs.scipy.org/doc/scipy-0.19.1/reference/generated/scipy.spatial.HalfspaceIntersection.html.
> I'm not an expert though and don't have much of a vision what does and does
> not belong in scipy.spatial. So I'll let others answer that question.
>
> Cheers,
> Ralf
>
>
>
>> I'd be happy to go that route instead of maintaining a scikit.
>>
>> Thanks,
>>
>> Andrew
>>
>> On Fri, Apr 5, 2019 at 4:20 AM Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>> Hi Andrew,
>>>
>>>
>>> On Thu, Apr 4, 2019 at 11:29 PM Andrew Hynes <andrewjhynes at gmail.com>
>>> wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> I'm completing my master's in computer engineering, and it involved
>>>> writing several functions for computations in 3D space, such as finding the
>>>> line of best fit from multiple points and projecting a point onto a line. I
>>>> decided to package my code into 'scikit-spatial', which provides objects
>>>> for points, vectors, lines and planes, and computations between them.
>>>>
>>>
>>> Looks interesting.
>>>
>>>
>>>> I know SymPy has similar objects in their geometry package, but my
>>>> package is based on NumPy for the objects and computations. The Point and
>>>> Vector objects are actually subclasses of the NumPy ndarray.
>>>>
>>>
>>> I'd also be interested in the comparison between scikit-spatial and
>>> scipy.spatial. It would probably be useful if you added that, as well as
>>> the SymPy comparison, to the readme of your repo and/or the first page of
>>> your docs.
>>>
>>>
>>>> It's my first Python package, so any feedback or contributions would be
>>>> greatly appreciated. The code is at
>>>> https://github.com/ajhynes7/scikit-spatial.
>>>>
>>>> I apologize if this is the wrong mailing list to post this. The
>>>> "Scikits" page (https://www.scipy.org/scikits.html) just says "It can
>>>> however be useful to let people know about it by discussing the new project
>>>> e.g. on the Scipy mailing lists.", but it doesn't specify which one.
>>>> Maybe the website can be edited to specify a mailing list for future
>>>> reference?
>>>>
>>>
>>> Yeah, that website needs some maintenance. An announcement and first
>>> discussion here is fine. If there's regular discussion happening going
>>> forward, then it would be good to set up a dedicated list (very easy with
>>> Google Groups for exampple).
>>>
>>> Cheers,
>>> Ralf
>>>
>>>
>>>> Thanks,
>>>>
>>>> Andrew Hynes
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190407/4dffdc6c/attachment-0001.html>

From grlee77 at gmail.com  Mon Apr  8 01:54:00 2019
From: grlee77 at gmail.com (Gregory Lee)
Date: Mon, 8 Apr 2019 01:54:00 -0400
Subject: [SciPy-Dev] GSoC 2019: Project Proposal
In-Reply-To: <CAG7Qgjhy-X-vDqxS8sS7SZ8Lv-YdySpwTQKb1QUuXRvXmM4y4w@mail.gmail.com>
References: <mailman.2071.1554480810.2938.scipy-dev@python.org>
 <CAG7Qgjhy-X-vDqxS8sS7SZ8Lv-YdySpwTQKb1QUuXRvXmM4y4w@mail.gmail.com>
Message-ID: <CAJR3sXdxc-3EHBMXHwtT4_5pVM-J2Lb9_FV1y8v1fBs9J3iC3w@mail.gmail.com>

On Sat, Apr 6, 2019 at 5:08 PM Anany Shrey Jain <
f20170920 at goa.bits-pilani.ac.in> wrote:

>
> Hey ,
> Thanks Greg for a detailed reply. I will be working on both
> https://github.com/pyFFTW/pyFFTW/pull/256 and
> https://github.com/cupy/cupy/issues/1936 as a part of this project. I
> have constructed my API implementation based on the `set_backend`  function
> approach, but in comparatively cleaner way. I have written my proposal for
> this project and here is a link to it:
> https://docs.google.com/document/d/1TIiH9j3rPAN--53MwjZz7NFO1GGtxmEH3RiGzvqnEBk/edit?usp=sharing.
> Please go through my proposal and if possible send some feedback on it.
>
> -Anany
>
>
Hi Anany,

I appreciate that you have narrowed down some of the possibilities. The API
will need further refinement to reach consensus, but the general concept as
presented seems reasonable and I don't think we have to reach consensus on
the finer implementation details for purposes of the proposal. I am not
sure it is necessary to have the `set_backend` function return a class that
allows setting additional arguments. Ralf's made a comment earlier that was
in favor of just supporting the arguments currently present in SciPy's
fftpack. I was also thinking something a bit simpler in terms of just
reading the name of the backend from a configuration file or environment
variable as opposed to running a full configuration script, but others may
disagree.

I will comment mainly on the timeline section of the proposal as we did not
discuss that previously:

I think the timeline is a bit overly optimistic and dedicates too much time
to third party libraries. It is probably not realistically going to be
possible to complete changes to SciPy as well as pyFFTW, mkl_fft and CuPy.
I would focus the majority of the timeline on SciPy itself. You can leave
the text about working on the pyFFTW and CuPy issues as goals for weeks
9-12, but I think all work in the early weeks should be in SciPy itself and
not require any changes to the third-party libraries in order for the
backend code to function. Each of the third party libraries already has a
substantial portion of the SciPy API implemented and can usefully be
integrated as backends as-is.

I think you can keep the plan to implement an initial interface and pyFFTW
support in weeks 1-2, but I think week 3-4 should be primarily along the
lines of improving and revising the initial interface based on reviewer
feedback from your first PR. Realistically, it will take a substantial
amount of time to reach agreement among all parties and code will not be
merged right away. I would focus weeks 3-4 on revising based on feedback
rather than proposing to "make CuPy compatible". CuPy already has
compatible interfaces for many of the functions (
https://github.com/cupy/cupy/blob/master/cupyx/scipy/fftpack/fft.py).

Week 5 seems to be missing from the timeline?

I would remove the item about adding changes to mkl_fft (in week 6). Was
there something specific you had in mind for that? There are already
existing wrappers (
https://github.com/IntelPython/mkl_fft/blob/master/mkl_fft/_scipy_fft.py)
and I'm not sure there is much more to do there.  A suitable replacement
for the week 5-6 section of the timeline could be working on the SciPy user
documentation detailing how to use and configure the backends. It could be
considered to potentially make small PRs to third party library
documentation as well, mentioning how scipy can be configured to use them
as its default backend. For instance, the new backend-based approach will
be preferable to the monkey patching currently discussed in the pyFFTW docs.

I proposed above to remove mention of CuPy from weeks 3-4 to reduce the
overall proportion of time in the proposal that is related to CuPy for a
couple of reasons:

1.) There is no existing precedent for interfacing with GPU code from SciPy
so that may be a little controversial among the larger group of SciPy
developers and have a harder time of getting merged. If we assume NumPy
inputs should give NumPy outputs then the required host/device memory
transfers will reduce performance, making the GPU-based approach only
beneficial for large transforms. We could allow GPU-based input/output, but
other functions in SciPy itself do not support GPU-based arrays.

2.) Using CuPy requires access to a relatively recent (~last five years or
so) NVidia GPU that supports CUDA (I think at least CUDA 8.0 is required).
Do you have access to an appropriate GPU? There is no requirement for
applicants to have access to such hardware, but it will difficult to
propose making contributions to CuPy itself without it. We may be able to
work out remote access to a machine that has appropriate hardware, but I
have not looked into specifics of how we would arrange that yet and cannot
guarantee it.




Message: 1
> Date: Fri, 5 Apr 2019 12:13:15 -0400
> From: Gregory Lee <grlee77 at gmail.com>
> To: SciPy Developers List <scipy-dev at python.org>
> Subject: Re: [SciPy-Dev] GSoC 2019
> Message-ID:
>         <
> CAJR3sXeVPAB+jGB_EdxiDg45jbR4wHzLVjjBk7+RiesT0XMrpw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, Apr 5, 2019 at 4:25 AM Anany Shrey Jain <
> f20170920 at goa.bits-pilani.ac.in> wrote:
>
> > Hey Greg,
> > The project "Revamp FFTPACK" also aims at contributing to third party
> > libraries to fill in functionality gaps. For pyFFTW I can see that work
> on
> > adding Real-to-Real transforms has been going on for a long time. So do I
> > need to continue the work going on in
> > https://github.com/pyFFTW/pyFFTW/pull/256 as a part of this project?
> >
>
> It is not a requirement that you work on the pyFFTW wrappers, but that
> would be a good complement to this project. Here are some thoughts.
>
> 1.) I would first have a mechanism to fall back to the existing
> scipy.fftpack implementations for any functions not currently supported by
> a given backend. pyFFTW currently already falls back to scipy's own
> implementation for DCT and DST transforms (
>
> https://github.com/pyFFTW/pyFFTW/blob/e9966e5d215a00f89156bd88e1d42b884f85df78/pyfftw/interfaces/scipy_fftpack.py#L81-L82
> ).
> The PR you referenced would allow it to use FFTW to perform these
> transforms instead and there would be no remaining functions that fall back
> to scipy.fftpack.
>
> 2.) You can work on adding real-to-real support in supporting libraries,
> but this is a secondary goal to pursue once the SciPy side of the project
> has been completed.
>    pyFFTW builds on FFTW which does already have functions providing
> real-to-real transforms. So what you see in the PR referenced above is
> mainly adding the wrappers for those to pyFFTW.
>
>
>
> > What needs to be done for the other two libraries? Do I need to make a
> > similar PR to other two libraries as well?
> >
> >
> You could potentially try that, but I think that is more of a stretch goal.
> The approach for CuPy or mkl-fft would have to be different, because for
> those two cases the underlying libraries DO NOT have dedicated functions
> implementing the real-to-real transforms. Also, the underlying FFT
> libraries are proprietary, so we cannot propose to add new transforms on
> the C/C++ side. However, it is possible in principle to implement
> real-to-real transforms using only the already existing complex-valued
> transforms (albeit at some additional computational/memory cost). Some
> detailed examples of this are given in the following thread on DSP
> StackExchange:
> https://dsp.stackexchange.com/questions/2807/fast-cosine-transform-via-fft
>
> I think that is probably the only feasible route for real-to-real
> transforms using those two backends. I think whether or not this type of
> implementation would give a performance benefit over just reusing the
> existing scipy.fftpack implementations is unknown.
>
> One FFT-related issues that could be improved in CuPy in a more
> straightforward manner than adding real-to-real support, is improving the
> real-to-complex and complex-to-real support.  These transforms are
> supported by the underlying CUFFT library, but support for this within CuPy
> is incomplete.  One issue related to this was opened at (
> https://github.com/cupy/cupy/issues/1936), but no PR implementing it has
> been made.
>
>
> > For all the three libraries there are SciPy-compatable routines already
> > defined. After getting required information using the newly created
> > interface I need to use them at the backend, right?
> >
>
> Yes, you should rely on the already existing interfaces when implementing
> the backends in SciPy. Any additional 3rd party libraries would have to
> provide a scipy-like interface in order to be compatible for use as a
> backend.
>
>
>
> >
> > -Anany
> >
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Thu, 4 Apr 2019 10:58:27 -0400
> >> From: Gregory Lee <grlee77 at gmail.com>
> >> To: SciPy Developers List <scipy-dev at python.org>
> >> Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 185, Issue 18
> >> Message-ID:
> >>         <
> >> CAJR3sXcJuqQJrDboN5zH-pd7NG-wD8EWCdTCAtQ+vJpnZjKsRw at mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> Hi Anany,
> >>
> >> It is nice to see that you have updated with multiple potential APIs.
> Can
> >> some other core SciPy devs also help give feedback on what SciPy would
> >> find
> >> preferable? Out of the four you proposed, I think something along the
> >> lines
> >> of the second method is cleanest in terms of setting the backend at
> >> runtime. I think having some aspect from your 4th variant where the
> >> default
> >> backend can be read from a configuration file and/or environment
> variable
> >> is also desirable so that the user's desired default can always be
> >> automatically set at import time.
> >>
> >> I disagree with the following specific statement, though:
> >> "It is better to use all the above mentioned ideas because every idea
> has
> >> its own benefits besides it gives user the luxury to choose the method
> >> implementation of backend."
> >>
> >> I do not think we want to provide multiple ways to do the same thing. It
> >> can be confusing to users and more work for devs to maintain. I think
> >> there
> >> should be one method of setting the backend that the user can either
> call
> >> at run time or have it be automatically called based on some sort of
> >> configuration file and/or environment variable(s) at import time.
> >>
> >> - Greg
> >>
> >>
> >> On Tue, Apr 2, 2019 at 2:19 PM Anany Shrey Jain <
> >> f20170920 at goa.bits-pilani.ac.in> wrote:
> >>
> >> > Hey,
> >> > I have already sent the link to the page containing the list of ideas
> >> for
> >> > implementation of new API that I propose for this project. Would you
> >> like
> >> > to add something to it or give some comments on it? The Gsoc proposal
> >> > deadline is 9th of April and I am planning to put all of this in my
> >> > proposal to make it effective . So any more ideas or comments will be
> >> > really helpful for me . Here is the link to the page:
> >> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy .
> >> >
> >> > On Sun, Mar 31, 2019 at 5:23 AM <scipy-dev-request at python.org> wrote:
> >> >
> >> >>
> >> >> Message: 1
> >> >> Date: Sat, 30 Mar 2019 13:31:51 -0400
> >> >> From: Eric Larson <larson.eric.d at gmail.com>
> >> >> To: SciPy Developers List <scipy-dev at python.org>
> >> >> Subject: Re: [SciPy-Dev] GSoC 2019
> >> >> Message-ID:
> >> >>         <
> >> >> CAGu2niVWsKrMukfWcAWAtj-1NBm2utCeh3BOnNku7jNoAcx-kw at mail.gmail.com>
> >> >> Content-Type: text/plain; charset="utf-8"
> >> >>
> >> >> It looks like the main ideas are in these bits of code, but not
> >> explicitly
> >> >> stated. In brief it looks like the proposed API is to add a
> >> `fft_object`
> >> >> kwarg to every function in `scipy.fftpack`. It would be good to
> discuss
> >> >> this choice explicitly -- what advantages and disadvantages it has
> >> >> relative
> >> >> to other approaches (e.g., creating new namespaces, or having a
> >> >> `set_backend` function (and/or context manager) that would change
> >> things
> >> >> under the hood).
> >> >>
> >> >> If you make changes and need more feedback, let us know. The more
> >> specific
> >> >> you can be about what you need feedback on (high level ideas, low
> level
> >> >> implementation, etc.), the better.
> >> >>
> >> >> Eric
> >> >>
> >> >>
> >> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
> >> >> f20170920 at goa.bits-pilani.ac.in> wrote:
> >> >>
> >> >> > Hey,
> >> >> > I went through the idea list of Scipy for this years's GSoC and I
> >> intend
> >> >> > to work towards the idea of revamping the Scipy's fftpack. I have
> >> >> already
> >> >> > been contributing to Scipy since the end of last year and I have
> some
> >> >> > knowledge about Fourier transforms as it was the part of my
> >> discipline.
> >> >> I
> >> >> > could not take part in this discussion earlier because my mid
> >> semester
> >> >> > exams were going on, but since they are now over so I can devote as
> >> much
> >> >> > time as required on this project. I have already created a github
> >> page
> >> >> with
> >> >> > some code snippets and functionalities that we can implement, here
> is
> >> >> the
> >> >> > link to it:
> >> >> >
> https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
> >> .
> >> >> >
> >> >> > Cheers,
> >> >> > Anany Jain
> >> >> >
> >> >> > _______________________________________________
> >> >> > SciPy-Dev mailing list
> >> >> > SciPy-Dev at python.org
> >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >
> >> >> -------------- next part --------------
> >> >> An HTML attachment was scrubbed...
> >> >> URL: <
> >> >>
> >>
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/f1755dfb/attachment-0001.html
> >> >> >
> >> >>
> >> >> ------------------------------
> >> >>
> >> >> Message: 2
> >> >> Date: Sat, 30 Mar 2019 19:38:41 -0400
> >> >> From: Gregory Lee <grlee77 at gmail.com>
> >> >> To: SciPy Developers List <scipy-dev at python.org>
> >> >> Subject: Re: [SciPy-Dev] GSoC 2019
> >> >> Message-ID:
> >> >>         <CAJR3sXfnnr-0JO87gLbhh-7b-w=KjaNpac+F+FHTeFt2K=_
> >> >> QMw at mail.gmail.com>
> >> >> Content-Type: text/plain; charset="utf-8"
> >> >>
> >> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
> >> >> f20170920 at goa.bits-pilani.ac.in> wrote:
> >> >>
> >> >> > Hey,
> >> >> > I went through the idea list of Scipy for this years's GSoC and I
> >> intend
> >> >> > to work towards the idea of revamping the Scipy's fftpack. I have
> >> >> already
> >> >> > been contributing to Scipy since the end of last year and I have
> some
> >> >> > knowledge about Fourier transforms as it was the part of my
> >> discipline.
> >> >> I
> >> >> > could not take part in this discussion earlier because my mid
> >> semester
> >> >> > exams were going on, but since they are now over so I can devote as
> >> much
> >> >> > time as required on this project. I have already created a github
> >> page
> >> >> with
> >> >> > some code snippets and functionalities that we can implement, here
> is
> >> >> the
> >> >> > link to it:
> >> >> >
> https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
> >> .
> >> >> >
> >> >> > Cheers,
> >> >> > Anany Jain
> >> >> >
> >> >> > _______________________________________________
> >> >> > SciPy-Dev mailing list
> >> >> > SciPy-Dev at python.org
> >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>
> >> >>
> >> >> Hi Anany,
> >> >>
> >> >> Thank you for your interest in GSOC with SciPy!  It's great to see
> that
> >> >> you
> >> >> are already thinking about a potential API and learning about the 3rd
> >> >> party
> >> >> FFT libraries. Along the lines of Eric's comment, think about what
> this
> >> >> API
> >> >> choice implies for users of libraries built upon SciPy. Would users
> of
> >> 3rd
> >> >> party libraries that rely on SciPy's FFTs be immediately able to take
> >> >> advantage of a differentf FFT backend in this scenario? (in other
> >> words,
> >> >> the case where the user is not calling scipy.fftpack.fft directly but
> >> is
> >> >> using it only indirectly via a function in a downstream library).
> >> >>
> >> >> Matplotlib is an example of an existing Python library supporting
> >> multiple
> >> >> backends that can be considered for comparison (see:
> >> >> https://matplotlib.org/faq/usage_faq.html#what-is-a-backend). Think
> >> about
> >> >> the relative benefits/drawbacks of some of the methods they use for
> >> >> setting
> >> >> a backend there as compared to the approach proposed for FFTs here.
> >> >>
> >> >> Another thing that should be considered: pyFFTW, MKL and CuPy already
> >> have
> >> >> some functions that match the existing scipy.fftpack API, but they
> may
> >> >> have
> >> >> one or more additional arguments particular to features of that
> >> library.
> >> >> How would you propose to deal with supporting additional optional
> >> >> arguments
> >> >> on the SciPy end?
> >> >>
> >> >> One other minor comment: I know that the blog post you made may be
> >> serving
> >> >> partly as personal notes, but please do not directly copy sections of
> >> text
> >> >> (e.g. the description of BLAS/LAPACK libraries) from elsewhere
> without
> >> >> attribution when writing a final proposal. (Also, the FFT functions
> are
> >> >> separate from the BLAS/LAPACK functions in MKL, so you will not need
> to
> >> >> discuss BLAS or LAPACK specifically in your proposal)
> >> >>
> >> >> - Greg
> >> >> -------------- next part --------------
> >> >> An HTML attachment was scrubbed...
> >> >> URL: <
> >> >>
> >>
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/c1351e7e/attachment-0001.html
> >> >> >
> >> >>
> >> >> ------------------------------
> >> >>
> >> >> Message: 3
> >> >> Date: Sat, 30 Mar 2019 19:53:02 -0400
> >> >> From: Gregory Lee <grlee77 at gmail.com>
> >> >> To: SciPy Developers List <scipy-dev at python.org>
> >> >> Subject: Re: [SciPy-Dev] GSoC 2019
> >> >> Message-ID:
> >> >>         <CAJR3sXdcPMAn_DETF8W-=
> >> >> MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw at mail.gmail.com>
> >> >> Content-Type: text/plain; charset="utf-8"
> >> >>
> >> >> Hi Gopi,
> >> >>
> >> >> I am not sure I follow exactly what you are suggesting here. Are you
> >> >> proposing that the `fftpackN` variable in your example would be a
> >> Python
> >> >> module corresponding to a given backend? If so, why is an array of
> >> data,
> >> >> z,
> >> >> being passed into the newAPI function here? I don't see why a data
> >> array
> >> >> should be needed at all to choose a backend.
> >> >>
> >> >> Please also see my response to Anany's recent post on this list for a
> >> >> couple of other suggestions of things to consider in terms of the
> API.
> >> >>
> >> >> - Greg
> >> >>
> >> >>
> >> >> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
> >> >> deathcoderx at gmail.com>
> >> >> wrote:
> >> >>
> >> >> > Hey,
> >> >> > I went through the code and got some ideas.
> >> >> > So what will happen is:
> >> >> > First, we will declare FFTW as we use them normally.
> >> >> >
> >> >> > z = np.random.rand(2, 128, 64)
> >> >> > pyfftw.FFTW(z, axes=(-1, ))
> >> >> > ..
> >> >> > ..
> >> >> > Now after declaring our basic work to shift to another FFTpack,
> what
> >> we
> >> >> > can do is:
> >> >> > fftPackN= newAPI(z, pack = 'PYFFTW');
> >> >> >
> >> >> > Pack will take the name of the 3rd party FFT pack which we want to
> >> use.
> >> >> > Suggestions needed.
> >> >> >
> >> >> > Cheers.
> >> >> >
> >> >> >
> >> >>
> >> >> >
> >> >> > On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <
> larson.eric.d at gmail.com
> >> >
> >> >> > wrote:
> >> >> >
> >> >> >> After reading the related issues and thinking about the problem,
> >> >> perhaps
> >> >> >> the best first step is you come up with some initial API proposal.
> >> >> >>
> >> >> >> One way to work through the process is to think about the use
> cases
> >> >> that
> >> >> >> we want to support. How should users actually write code to use
> the
> >> new
> >> >> >> functionality? You can start with short code snippets that do not
> >> work
> >> >> >> currently, but should work for users at the end of the project.
> Then
> >> >> think
> >> >> >> about what needs to change inside SciPy for these code snippets to
> >> >> work.
> >> >> >> This can become an iterative process as you realize that the SciPy
> >> >> changes
> >> >> >> might be better or easier with changes to the user-facing API,
> etc.
> >> >> >>
> >> >> >> Eric
> >> >> >>
> >> >> >>
> >> >> >> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
> >> >> >> deathcoderx at gmail.com> wrote:
> >> >> >>
> >> >> >>> Hey,
> >> >> >>> As proposal submission period started I want to discuss a bit
> anobt
> >> >> how
> >> >> >>> can we implement the API.
> >> >> >>> I would very much appriciate inputs and guidance.
> >> >> >>>
> >> >> >>> Cheers.
> >> >> >>>
> >> >> >>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <
> >> larson.eric.d at gmail.com>
> >> >> >>> wrote:
> >> >> >>>
> >> >> >>>> The best way to figure that out is probably to take a look at
> >> some of
> >> >> >>>> the existing (minor) SciPy GitHub issues and try to work on one
> or
> >> >> two that
> >> >> >>>> you feel like working on. Actually trying to work out how to
> >> >> contribute
> >> >> >>>> code changes (as independently as possible/reasonable based on
> the
> >> >> existing
> >> >> >>>> guides/docs already discoverable online) will quickly highlight
> >> >> things that
> >> >> >>>> need to be learned. Some of the general things are the SciPy
> >> >> contributing
> >> >> >>>> guidelines, standard GitHub PR workflow, communication with
> >> >> reviewers, and
> >> >> >>>> so forth.
> >> >> >>>>
> >> >> >>>> For this particular project, it's important to understand the
> >> various
> >> >> >>>> flavors and properties of FFT in SciPy (real, complex,
> >> n-dimensional,
> >> >> >>>> caching plans, etc.) as well as other projects like NumPy, CuPy,
> >> and
> >> >> >>>> pyFFTW. Some of this can be learned and improved upon as part of
> >> >> GSoC, but
> >> >> >>>> the more you know and can demonstrate / put into practice
> >> knowledge
> >> >> of
> >> >> >>>> before the applications are reviewed, the better.
> >> >> >>>>
> >> >> >>>> Eric
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
> >> >> >>>> deathcoderx at gmail.com> wrote:
> >> >> >>>>
> >> >> >>>>> Thank you for the detailed reply.
> >> >> >>>>> I will keep these point in mind while preparing my proposal.
> >> Apart
> >> >> >>>>> from proposal, what skills shall I improve so that I can
> >> contribute
> >> >> more
> >> >> >>>>> effectively and efficiently.
> >> >> >>>>>
> >> >> >>>>> Cheers.
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <
> >> larson.eric.d at gmail.com>
> >> >> >>>>> wrote:
> >> >> >>>>>
> >> >> >>>>>> There are a number of considerations that would be good to
> >> address.
> >> >> >>>>>> I'd start by considering the things that are typically
> >> considered
> >> >> >>>>>> when making changes to SciPy
> >> >> >>>>>> <
> >> >>
> >>
> https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy
> >> >> >,
> >> >> >>>>>> but I'd expand it to a longer list since the scope is bigger
> >> than
> >> >> a typical
> >> >> >>>>>> single PR. The list would contain (at least):
> >> >> >>>>>>
> >> >> >>>>>> - what will the user-facing API / contract be?
> >> >> >>>>>> - what in SciPy needs to change to allow it (internals /
> >> >> >>>>>> implementation outline, perhaps skeleton functions/classes)?
> >> >> >>>>>> - what examples should we show users (in general this ends up
> >> being
> >> >> >>>>>> just simple use cases of the API)?
> >> >> >>>>>> - how will we test it for correctness?
> >> >> >>>>>> - how will we benchmark it to prevent performance regressions?
> >> >> >>>>>> - how can we break up the work for these steps (if possible)
> >> into
> >> >> >>>>>> separable, sequential (or -- better but not usually possible
> --
> >> >> >>>>>> independent) PRs?
> >> >> >>>>>>
> >> >> >>>>>> You might notice that none of these points are actually all
> that
> >> >> >>>>>> specific to the FFT project, but can be generally applicable
> to
> >> >> GSoC
> >> >> >>>>>> projects. For the FFT project, I would say "how do we build
> the
> >> >> backend" is
> >> >> >>>>>> indeed implicitly contained / outlined in these bullet points.
> >> And
> >> >> as with
> >> >> >>>>>> most projects, the first two points (and possibly the last)
> will
> >> >> probably
> >> >> >>>>>> be the most challenging to sort out.
> >> >> >>>>>>
> >> >> >>>>>> Eric
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
> >> >> >>>>>> deathcoderx at gmail.com> wrote:
> >> >> >>>>>>
> >> >> >>>>>>> Hey Eric,
> >> >> >>>>>>> So for my proposal, shall I include how can we built a back
> >> end?
> >> >> >>>>>>> What all points shall I include to make it effective?
> >> >> >>>>>>>
> >> >> >>>>>>> Cheers.
> >> >> >>>>>>>
> >> >> >>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <
> >> larson.eric.d at gmail.com
> >> >> >
> >> >> >>>>>>> wrote:
> >> >> >>>>>>>
> >> >> >>>>>>>> That would be me -- don't worry, I'm on this list, as are
> >> >> >>>>>>>> (presumably) other developers interested in the discussion,
> so
> >> >> no need to
> >> >> >>>>>>>> document elsewhere for now from our end. It looks like Greg
> >> has
> >> >> summarized
> >> >> >>>>>>>> the current status and thoughts we've had, so I don't have
> >> much
> >> >> to add at
> >> >> >>>>>>>> this point.
> >> >> >>>>>>>>
> >> >> >>>>>>>> Eric
> >> >> >>>>>>>>
> >> >> >>>>>>>>
> >> >> >>>>>>>>
> >> >> >>>>>>>>
> >> >> >>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
> >> >> >>>>>>>> deathcoderx at gmail.com> wrote:
> >> >> >>>>>>>>
> >> >> >>>>>>>>> Hey Greg,
> >> >> >>>>>>>>> I got the basic idea about what we want to implement this
> >> year.
> >> >> >>>>>>>>> Our first priority is to create a backend for 3rd party
> >> >> fftpacks.
> >> >> >>>>>>>>> We can create API using Python and Flask or any other
> >> suitable
> >> >> framework.
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> I thought this discussion was going on on SciPy Developer
> >> List
> >> >> >>>>>>>>> only. So do I need to document it all and post it somewhere
> >> so
> >> >> that other
> >> >> >>>>>>>>> contributors can see this?
> >> >> >>>>>>>>> Also, I couldn't find any contact info regarding Eric. It
> >> would
> >> >> be
> >> >> >>>>>>>>> very helpful if we include him in this discussion as this
> is
> >> a
> >> >> roadmap for
> >> >> >>>>>>>>> GSoC project and I can also get more insight into the
> project
> >> >> and expected
> >> >> >>>>>>>>> outcomes.
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> Cheers.
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <
> >> grlee77 at gmail.com>
> >> >> >>>>>>>>> wrote:
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
> >> >> >>>>>>>>>> deathcoderx at gmail.com> wrote:
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>> Hey Gregory,
> >> >> >>>>>>>>>>> I went through the idea and I am very much interested in
> >> >> working
> >> >> >>>>>>>>>>> on it. I had Fourier Transforms as a part of my academic
> >> >> course, so I am
> >> >> >>>>>>>>>>> well aware with basic concepts.
> >> >> >>>>>>>>>>> One thing I want to discuss is, its mentioned that we
> have
> >> to
> >> >> >>>>>>>>>>> create a backend system for 3rd party FFTpacks so my
> dobuts
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>> 1. How are we going to create API?
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> This will needed to be decided on in consensus with the
> >> SciPy
> >> >> >>>>>>>>>> developers and user community. I am mentoring for the
> >> project
> >> >> as a
> >> >> >>>>>>>>>> contributor here and a maintainer of the related pyFFTW
> >> >> package, but I am
> >> >> >>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core
> dev
> >> >> here). I have
> >> >> >>>>>>>>>> not discussed the API in any detail with the SciPy team at
> >> >> this stage.
> >> >> >>>>>>>>>> Working out details of what the API should look like and
> >> >> working to
> >> >> >>>>>>>>>> finalize that in collaboration with the community will be
> a
> >> >> primary task
> >> >> >>>>>>>>>> during the early part of the GSOC project.
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> 2. After the creation of backend will user at the time of
> >> >> >>>>>>>>>>> installation of SciPy will decide what all 3rd party
> >> FFTpacks
> >> >> he needs or
> >> >> >>>>>>>>>>> we will include some by default?
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> The idea is to allow users to opt-in to a different FFT
> >> >> backend
> >> >> >>>>>>>>>> at run time, but these alternative libraries will not be
> >> >> distributed with
> >> >> >>>>>>>>>> SciPy itself due to incompatible software licenses (pyFFTW
> >> and
> >> >> mkl-fft) or
> >> >> >>>>>>>>>> a requirement for specific hardware (CuPy requires an
> NVIDIA
> >> >> GPU). SciPy
> >> >> >>>>>>>>>> will continue to offer its own bundled FFT library
> >> (currently
> >> >> fftpack, but
> >> >> >>>>>>>>>> this could be switched to pocketfft as discussed in the
> >> ideas
> >> >> page). The
> >> >> >>>>>>>>>> purpose of the backend interface is to provide a
> convenient
> >> >> way for users
> >> >> >>>>>>>>>> to have third party libraries perform the FFTs instead,
> but
> >> >> under the
> >> >> >>>>>>>>>> existing scipy.fftpack API. This is motivated by a desire
> by
> >> >> end users and
> >> >> >>>>>>>>>> downstream projects to have features such as
> multi-threading
> >> >> (pyFFTW and
> >> >> >>>>>>>>>> mkl-fft) or GPU support (CuPy) that are not implemented in
> >> >> scipy.fftpack.
> >> >> >>>>>>>>>> Ultimately it will be up to users that opt-in to using
> these
> >> >> other
> >> >> >>>>>>>>>> libraries to confirm that the license terms and are
> >> compatible
> >> >> with their
> >> >> >>>>>>>>>> use case.
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev
> mailing
> >> >> >>>>>>>>>> lists prefers replies **below** the email you are replying
> >> to
> >> >> so people can
> >> >> >>>>>>>>>> more easily follow the thread of discussion. There are
> some
> >> >> guidelines at:
> >> >> >>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> I will research more about how to implement a backend
> myself
> >> >> and
> >> >> >>>>>>>>>>> will let you know as soon as I come up with something
> new.
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>> CHeers,
> >> >> >>>>>>>>>>> Greg
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <
> >> >> grlee77 at gmail.com>
> >> >> >>>>>>>>>>> wrote:
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
> >> >> >>>>>>>>>>>> deathcoderx at gmail.com> wrote:
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started fixing
> >> some
> >> >> >>>>>>>>>>>>> bugs, also made some pull request. Can anyone suggest
> me
> >> >> how should I
> >> >> >>>>>>>>>>>>> proceed further?
> >> >> >>>>>>>>>>>>> _______________________________________________
> >> >> >>>>>>>>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>>>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> Hi Gopi,
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> I think you have probably already found it, but the GSOC
> >> >> >>>>>>>>>>>> project we have already identified mentors for in SciPy
> is
> >> >> here:
> >> >> >>>>>>>>>>>>
> >> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> If this is a project you are interested in then I would
> >> start
> >> >> >>>>>>>>>>>> thinking about what the FFT interface would look like
> and
> >> >> reviewing some of
> >> >> >>>>>>>>>>>> the past/present issues related to fftpack / FFT in
> SciPy.
> >> >> Please ask
> >> >> >>>>>>>>>>>> questions you have related to that project here so that
> >> you
> >> >> can clarify
> >> >> >>>>>>>>>>>> what would be involved in writing a successful
> >> application.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> If you have a different idea in mind you can propose it
> >> here,
> >> >> >>>>>>>>>>>> but you should do that soon, because it will be
> necessary
> >> to
> >> >> determine if
> >> >> >>>>>>>>>>>> there is interest from the SciPy team before you spend
> >> time
> >> >> coming up with
> >> >> >>>>>>>>>>>> a detailed proposal. We have to determine if a project
> >> >> sounds feasible to
> >> >> >>>>>>>>>>>> complete for GSOC and if appropriate mentors can be
> >> >> identified.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> Ultimately, you will need to submit an application to
> >> SciPy
> >> >> >>>>>>>>>>>> between March 25th - April 9th.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> Cheers,
> >> >> >>>>>>>>>>>> Greg
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> _______________________________________________
> >> >> >>>>>>>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>> _______________________________________________
> >> >> >>>>>>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>> _______________________________________________
> >> >> >>>>>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>> _______________________________________________
> >> >> >>>>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>>>
> >> >> >>>>>>>> _______________________________________________
> >> >> >>>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>>
> >> >> >>>>>>> _______________________________________________
> >> >> >>>>>>> SciPy-Dev mailing list
> >> >> >>>>>>> SciPy-Dev at python.org
> >> >> >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>>
> >> >> >>>>>> _______________________________________________
> >> >> >>>>>> SciPy-Dev mailing list
> >> >> >>>>>> SciPy-Dev at python.org
> >> >> >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>>
> >> >> >>>>> _______________________________________________
> >> >> >>>>> SciPy-Dev mailing list
> >> >> >>>>> SciPy-Dev at python.org
> >> >> >>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>>
> >> >> >>>> _______________________________________________
> >> >> >>>> SciPy-Dev mailing list
> >> >> >>>> SciPy-Dev at python.org
> >> >> >>>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>>
> >> >> >>> _______________________________________________
> >> >> >>> SciPy-Dev mailing list
> >> >> >>> SciPy-Dev at python.org
> >> >> >>> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>>
> >> >> >> _______________________________________________
> >> >> >> SciPy-Dev mailing list
> >> >> >> SciPy-Dev at python.org
> >> >> >> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >>
> >> >> > _______________________________________________
> >> >> > SciPy-Dev mailing list
> >> >> > SciPy-Dev at python.org
> >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> >> >> >
> >> >> -------------- next part --------------
> >> >> An HTML attachment was scrubbed...
> >> >> URL: <
> >> >>
> >>
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/54f38250/attachment.html
> >> >> >
> >> >>
> >> >> ------------------------------
> >> >>
> >> >> Subject: Digest Footer
> >> >>
> >> >> _______________________________________________
> >> >> SciPy-Dev mailing list
> >> >> SciPy-Dev at python.org
> >> >> https://mail.python.org/mailman/listinfo/scipy-dev
> >> >>
> >> >>
> >> >> ------------------------------
> >> >>
> >> >> End of SciPy-Dev Digest, Vol 185, Issue 18
> >> >> ******************************************
> >> >>
> >> > _______________________________________________
> >> > SciPy-Dev mailing list
> >> > SciPy-Dev at python.org
> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> >> >
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <
> >>
> http://mail.python.org/pipermail/scipy-dev/attachments/20190404/1a670020/attachment.html
> >> >
> >>
> >> ------------------------------
> >>
> >> Subject: Digest Footer
> >>
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at python.org
> >> https://mail.python.org/mailman/listinfo/scipy-dev
> >>
> >>
> >> ------------------------------
> >>
> >> End of SciPy-Dev Digest, Vol 186, Issue 11
> >> ******************************************
> >>
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at python.org
> > https://mail.python.org/mailman/listinfo/scipy-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/scipy-dev/attachments/20190405/cc4019f5/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
>
> ------------------------------
>
> End of SciPy-Dev Digest, Vol 186, Issue 15
> ******************************************
>
_______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190408/a59718a0/attachment-0001.html>

From ralf.gommers at gmail.com  Mon Apr  8 03:33:43 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 8 Apr 2019 09:33:43 +0200
Subject: [SciPy-Dev] [ANN] Release of scikit-spatial package
In-Reply-To: <CAD-yzHbZ+PQ6rMTXJoz-1nfkMcyhrTk0a5RCK_ZUeujz8WUazw@mail.gmail.com>
References: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
 <CABL7CQgNV8gu3oFTwN0X-DDAxqXfig65+r--0y=ez+S_H12Lnw@mail.gmail.com>
 <CAD-yzHabNxhEv9i2OtFjsawYO19fhBiGdVpdUw1c64G67Of-ew@mail.gmail.com>
 <CABL7CQj5H4ydVB577kFe_7CRnE1_5Q4zJGygrXb7zHx57zsVuA@mail.gmail.com>
 <CAD-yzHbZ+PQ6rMTXJoz-1nfkMcyhrTk0a5RCK_ZUeujz8WUazw@mail.gmail.com>
Message-ID: <CABL7CQjrHOCdgkrT3K8uOSceQDbvPUDGq3JZveZ8DrJzQVaB0Q@mail.gmail.com>

On Mon, Apr 8, 2019 at 2:10 AM Andrew Hynes <andrewjhynes at gmail.com> wrote:

> I'm not sure. Features like the intersections between planes seems to be
>> similar in nature to the scipy.spatial.rotation or
>> https://docs.scipy.org/doc/scipy-0.19.1/reference/generated/scipy.spatial.HalfspaceIntersection.html.
>> I'm not an expert though and don't have much of a vision what does and does
>> not belong in scipy.spatial. So I'll let others answer that question.
>
>
> Ok, I will ask. Should I start a new thread on this mailing list or make a
> pull request on github?
>

Neither at this point I think, this conversation will be fine.

Tyler, Nikolay, Pauli, others - any comment?

Cheers,
Ralf


> Andrew
>
> On Sun, Apr 7, 2019 at 2:07 PM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>>
>>
>> On Sat, Apr 6, 2019 at 4:05 PM Andrew Hynes <andrewjhynes at gmail.com>
>> wrote:
>>
>>> Hi Ralf,
>>>
>>> Thanks for getting back to me.
>>>
>>> I'd also be interested in the comparison between scikit-spatial and
>>>> scipy.spatial. It would probably be useful if you added that, as well as
>>>> the SymPy comparison, to the readme of your repo and/or the first page of
>>>> your docs.
>>>>
>>>
>>> From what I can see, there is no overlap between scipy.spatial functions
>>> and those in my package. Do you think my code could be added to
>>> scipy.spatial?
>>>
>>
>> I'm not sure. Features like the intersections between planes seems to be
>> similar in nature to the scipy.spatial.rotation or
>> https://docs.scipy.org/doc/scipy-0.19.1/reference/generated/scipy.spatial.HalfspaceIntersection.html.
>> I'm not an expert though and don't have much of a vision what does and does
>> not belong in scipy.spatial. So I'll let others answer that question.
>>
>> Cheers,
>> Ralf
>>
>>
>>
>>> I'd be happy to go that route instead of maintaining a scikit.
>>>
>>> Thanks,
>>>
>>> Andrew
>>>
>>> On Fri, Apr 5, 2019 at 4:20 AM Ralf Gommers <ralf.gommers at gmail.com>
>>> wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>>
>>>> On Thu, Apr 4, 2019 at 11:29 PM Andrew Hynes <andrewjhynes at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello everyone,
>>>>>
>>>>> I'm completing my master's in computer engineering, and it involved
>>>>> writing several functions for computations in 3D space, such as finding the
>>>>> line of best fit from multiple points and projecting a point onto a line. I
>>>>> decided to package my code into 'scikit-spatial', which provides objects
>>>>> for points, vectors, lines and planes, and computations between them.
>>>>>
>>>>
>>>> Looks interesting.
>>>>
>>>>
>>>>> I know SymPy has similar objects in their geometry package, but my
>>>>> package is based on NumPy for the objects and computations. The Point and
>>>>> Vector objects are actually subclasses of the NumPy ndarray.
>>>>>
>>>>
>>>> I'd also be interested in the comparison between scikit-spatial and
>>>> scipy.spatial. It would probably be useful if you added that, as well as
>>>> the SymPy comparison, to the readme of your repo and/or the first page of
>>>> your docs.
>>>>
>>>>
>>>>> It's my first Python package, so any feedback or contributions would
>>>>> be greatly appreciated. The code is at
>>>>> https://github.com/ajhynes7/scikit-spatial.
>>>>>
>>>>> I apologize if this is the wrong mailing list to post this. The
>>>>> "Scikits" page (https://www.scipy.org/scikits.html) just says "It can
>>>>> however be useful to let people know about it by discussing the new project
>>>>> e.g. on the Scipy mailing lists.", but it doesn't specify which one.
>>>>> Maybe the website can be edited to specify a mailing list for future
>>>>> reference?
>>>>>
>>>>
>>>> Yeah, that website needs some maintenance. An announcement and first
>>>> discussion here is fine. If there's regular discussion happening going
>>>> forward, then it would be good to set up a dedicated list (very easy with
>>>> Google Groups for exampple).
>>>>
>>>> Cheers,
>>>> Ralf
>>>>
>>>>
>>>>> Thanks,
>>>>>
>>>>> Andrew Hynes
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190408/62d0e11f/attachment.html>

From rfezzani at gmail.com  Mon Apr  8 05:36:06 2019
From: rfezzani at gmail.com (Riadh)
Date: Mon, 8 Apr 2019 11:36:06 +0200
Subject: [SciPy-Dev] Fix ndimage.rotate plane check
Message-ID: <f626af9f-dba8-1c20-041d-c83177324eac@gmail.com>

Hello,

I opened the issue #10011 <https://github.com/scipy/scipy/issues/10011> 
about wrong validation of rotation plane axes in the 
ndimage.interpolation.rotate function.

I also made some propositions for refactoring this function. You can see 
my contribution in the pull request #10028 
<https://github.com/scipy/scipy/pull/10028>.

This is my first time filling a pull request for Scipy, so I hope that 
every thing is OK with it.

Thank you for your review and comments,

Riadh.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190408/203dd1f7/attachment.html>

From stefanv at berkeley.edu  Mon Apr  8 17:48:56 2019
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Mon, 08 Apr 2019 17:48:56 -0400
Subject: [SciPy-Dev] [ANN] Release of scikit-spatial package
In-Reply-To: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
References: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
Message-ID: <555a5a21-6a0a-4bf5-ba6f-83361c7f840a@www.fastmail.com>

Hi Andrew,

On Thu, Apr 4, 2019, at 14:30, Andrew Hynes wrote:
> I know SymPy has similar objects in their geometry package, but my package is based on NumPy for the objects and computations. The Point and Vector objects are actually subclasses of the NumPy ndarray.
> 
> It's my first Python package, so any feedback or contributions would be greatly appreciated. The code is at https://github.com/ajhynes7/scikit-spatial.

This looks neat! It reminds me a bit of the following book which I enjoyed:

http://www.geometricalgebra.net/

Can you tell us a bit more about how you see these functions typically being applied in practice?

Best regards,
St?fan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190408/80a0c886/attachment.html>

From andrewjhynes at gmail.com  Mon Apr  8 19:09:15 2019
From: andrewjhynes at gmail.com (Andrew Hynes)
Date: Mon, 8 Apr 2019 19:09:15 -0400
Subject: [SciPy-Dev] [ANN] Release of scikit-spatial package
In-Reply-To: <555a5a21-6a0a-4bf5-ba6f-83361c7f840a@www.fastmail.com>
References: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
 <555a5a21-6a0a-4bf5-ba6f-83361c7f840a@www.fastmail.com>
Message-ID: <CAD-yzHZJSDvJsXQorZtAtqRpgANR35UN9fbE_2gmKKnUm1qkjQ@mail.gmail.com>

Hi St?fan,

> This looks neat!  It reminds me a bit of the following book which I
> enjoyed:
>
> http://www.geometricalgebra.net/
>

Thanks for the link - it looks like a good source for expanding the package.

Can you tell us a bit more about how you see these functions typically
> being applied in practice?
>
Sure, I can give an example from my masters project. It involved clinical
gait analysis with a depth camera, so I used some of these functions to
calculate gait parameters from positions in space.

A basic walking stride consists of three positions: The initial swing foot,
the stance foot, and the final swing foot. The stride length is the
distance from the initial to final swing foot. The stride width is the
length of the projection from the stance foot to the swing path (the line
from the initial swing foot to the final).

Here's a snippet of code using scikit-spatial to calculate gait parameters
from three points: point_a_i (initial swing foot), point_b (stance foot),
and point_a_f (final swing foot).

from skspatial.objects import Vector, Line

vector_a = Vector.from_points(point_a_i, point_a_f)
line_a = Line(point=point_a_i, direction=vector_a)

point_b_proj = line_a.project_point(point_b)

stride_length = vector_a.norm()
absolute_step_length = Vector.from_points(point_b, point_a_f).norm()
step_length = Vector.from_points(point_b_proj, point_a_f).norm()
stride_width = line_a.distance_point(point_b)


Hopefully that gives an idea as to how the package can be used.

Thanks,

Andrew

P. S. Great job on scikit-image!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190408/01852b37/attachment.html>

From f20170920 at goa.bits-pilani.ac.in  Mon Apr  8 21:58:01 2019
From: f20170920 at goa.bits-pilani.ac.in (Anany Shrey Jain)
Date: Tue, 9 Apr 2019 07:28:01 +0530
Subject: [SciPy-Dev] GSoC 2019: Project Proposal
In-Reply-To: <mailman.50.1554702855.2981.scipy-dev@python.org>
References: <mailman.50.1554702855.2981.scipy-dev@python.org>
Message-ID: <CAG7QgjiDixsvV4ePV1NJVf7NGy_SR9Nn5pAp-a8RcrQnimmhWQ@mail.gmail.com>

Hey,
Thanks Greg for going through my proposal. I appreciate the way you went
through every small detail .

It will be very difficult for me to make changes in the implementation
details now. Moreover the API will be changed a lot after the discussions
with other developers, so for now, it will be better to stick with the
current API .

Except the API I have incorporated all the suggestions. The week 5 was left
intentionally as a buffer during the phase 1 evaluations (I admit that I
should have mentioned that in my proposal) .
Nothing special was planned for mkl_fft, I just thought there might be need
of some conversions lsubroutines ike this :
https://github.com/pyFFTW/pyFFTW/blob/e9966e5d215a00f89156bd88e1d42b884f85df78/pyfftw/interfaces/scipy_fftpack.py#L227
. But after seeing the Mkl code base again I don't think it will be
required.

Luckily, I have that kind of GPU (Cuda 9.1) but still it will be very
difficult to reach to a common point and get things merged in CuPy. So I
have removed the text about it, during the mentioned week, from my proposal.

Here is the link to my proposal:
https://docs.google.com/document/d/1TIiH9j3rPAN--53MwjZz7NFO1GGtxmEH3RiGzvqnEBk/edit#

-Anany


Date: Mon, 8 Apr 2019 01:54:00 -0400
> From: Gregory Lee <grlee77 at gmail.com>
> To: SciPy Developers List <scipy-dev at python.org>
> Subject: Re: [SciPy-Dev] GSoC 2019: Project Proposal
> Message-ID:
>         <
> CAJR3sXdxc-3EHBMXHwtT4_5pVM-J2Lb9_FV1y8v1fBs9J3iC3w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Sat, Apr 6, 2019 at 5:08 PM Anany Shrey Jain <
> f20170920 at goa.bits-pilani.ac.in> wrote:
>
> >
> > Hey ,
> > Thanks Greg for a detailed reply. I will be working on both
> > https://github.com/pyFFTW/pyFFTW/pull/256 and
> > https://github.com/cupy/cupy/issues/1936 as a part of this project. I
> > have constructed my API implementation based on the `set_backend`
> function
> > approach, but in comparatively cleaner way. I have written my proposal
> for
> > this project and here is a link to it:
> >
> https://docs.google.com/document/d/1TIiH9j3rPAN--53MwjZz7NFO1GGtxmEH3RiGzvqnEBk/edit?usp=sharing
> .
> > Please go through my proposal and if possible send some feedback on it.
> >
> > -Anany
> >
> >
> Hi Anany,
>
> I appreciate that you have narrowed down some of the possibilities. The API
> will need further refinement to reach consensus, but the general concept as
> presented seems reasonable and I don't think we have to reach consensus on
> the finer implementation details for purposes of the proposal. I am not
> sure it is necessary to have the `set_backend` function return a class that
> allows setting additional arguments. Ralf's made a comment earlier that was
> in favor of just supporting the arguments currently present in SciPy's
> fftpack. I was also thinking something a bit simpler in terms of just
> reading the name of the backend from a configuration file or environment
> variable as opposed to running a full configuration script, but others may
> disagree.
>
> I will comment mainly on the timeline section of the proposal as we did not
> discuss that previously:
>
> I think the timeline is a bit overly optimistic and dedicates too much time
> to third party libraries. It is probably not realistically going to be
> possible to complete changes to SciPy as well as pyFFTW, mkl_fft and CuPy.
> I would focus the majority of the timeline on SciPy itself. You can leave
> the text about working on the pyFFTW and CuPy issues as goals for weeks
> 9-12, but I think all work in the early weeks should be in SciPy itself and
> not require any changes to the third-party libraries in order for the
> backend code to function. Each of the third party libraries already has a
> substantial portion of the SciPy API implemented and can usefully be
> integrated as backends as-is.
>
> I think you can keep the plan to implement an initial interface and pyFFTW
> support in weeks 1-2, but I think week 3-4 should be primarily along the
> lines of improving and revising the initial interface based on reviewer
> feedback from your first PR. Realistically, it will take a substantial
> amount of time to reach agreement among all parties and code will not be
> merged right away. I would focus weeks 3-4 on revising based on feedback
> rather than proposing to "make CuPy compatible". CuPy already has
> compatible interfaces for many of the functions (
> https://github.com/cupy/cupy/blob/master/cupyx/scipy/fftpack/fft.py).
>
> Week 5 seems to be missing from the timeline?
>

The week 5 was left intentionally as a buffer during the phase 1
evaluations (I admit that I should have mentioned that in my proposal) .

>
> I would remove the item about adding changes to mkl_fft (in week 6). Was
> there something specific you had in mind for that?


Nothing special was planned for mkl_fft, I just thought there might be need
of some conversions like this :
https://github.com/pyFFTW/pyFFTW/blob/e9966e5d215a00f89156bd88e1d42b884f85df78/pyfftw/interfaces/scipy_fftpack.py#L227
. But after seeing the Mkl codebase again I don't think it will be
required.

There are already
> existing wrappers (
> https://github.com/IntelPython/mkl_fft/blob/master/mkl_fft/_scipy_fft.py)
> and I'm not sure there is much more to do there.  A suitable replacement
> for the week 5-6 section of the timeline could be working on the SciPy user
> documentation detailing how to use and configure the backends. It could be
> considered to potentially make small PRs to third party library
> documentation as well, mentioning how scipy can be configured to use them
> as its default backend. For instance, the new backend-based approach will
> be preferable to the monkey patching currently discussed in the pyFFTW
> docs.
>
> I proposed above to remove mention of CuPy from weeks 3-4 to reduce the
> overall proportion of time in the proposal that is related to CuPy for a
> couple of reasons:
>
> 1.) There is no existing precedent for interfacing with GPU code from SciPy
> so that may be a little controversial among the larger group of SciPy
> developers and have a harder time of getting merged. If we assume NumPy
> inputs should give NumPy outputs then the required host/device memory
> transfers will reduce performance, making the GPU-based approach only
> beneficial for large transforms. We could allow GPU-based input/output, but
> other functions in SciPy itself do not support GPU-based arrays.
>
> 2.) Using CuPy requires access to a relatively recent (~last five years or
> so) NVidia GPU that supports CUDA (I think at least CUDA 8.0 is required).
> Do you have access to an appropriate GPU?


Luckily I have that kind of GPU (Cuda 9.1) but still it will be very
difficult to reach to a common point and get things merged in CuPy. So I
have removed the text about it from my proposal.

There is no requirement for
> applicants to have access to such hardware, but it will difficult to
> propose making contributions to CuPy itself without it. We may be able to
> work out remote access to a machine that has appropriate hardware, but I
> have not looked into specifics of how we would arrange that yet and cannot
> guarantee it.
>
>
>
>
> Message: 1
> > Date: Fri, 5 Apr 2019 12:13:15 -0400
> > From: Gregory Lee <grlee77 at gmail.com>
> > To: SciPy Developers List <scipy-dev at python.org>
> > Subject: Re: [SciPy-Dev] GSoC 2019
> > Message-ID:
> >         <
> > CAJR3sXeVPAB+jGB_EdxiDg45jbR4wHzLVjjBk7+RiesT0XMrpw at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > On Fri, Apr 5, 2019 at 4:25 AM Anany Shrey Jain <
> > f20170920 at goa.bits-pilani.ac.in> wrote:
> >
> > > Hey Greg,
> > > The project "Revamp FFTPACK" also aims at contributing to third party
> > > libraries to fill in functionality gaps. For pyFFTW I can see that work
> > on
> > > adding Real-to-Real transforms has been going on for a long time. So
> do I
> > > need to continue the work going on in
> > > https://github.com/pyFFTW/pyFFTW/pull/256 as a part of this project?
> > >
> >
> > It is not a requirement that you work on the pyFFTW wrappers, but that
> > would be a good complement to this project. Here are some thoughts.
> >
> > 1.) I would first have a mechanism to fall back to the existing
> > scipy.fftpack implementations for any functions not currently supported
> by
> > a given backend. pyFFTW currently already falls back to scipy's own
> > implementation for DCT and DST transforms (
> >
> >
> https://github.com/pyFFTW/pyFFTW/blob/e9966e5d215a00f89156bd88e1d42b884f85df78/pyfftw/interfaces/scipy_fftpack.py#L81-L82
> > ).
> > The PR you referenced would allow it to use FFTW to perform these
> > transforms instead and there would be no remaining functions that fall
> back
> > to scipy.fftpack.
> >
> > 2.) You can work on adding real-to-real support in supporting libraries,
> > but this is a secondary goal to pursue once the SciPy side of the project
> > has been completed.
> >    pyFFTW builds on FFTW which does already have functions providing
> > real-to-real transforms. So what you see in the PR referenced above is
> > mainly adding the wrappers for those to pyFFTW.
> >
> >
> >
> > > What needs to be done for the other two libraries? Do I need to make a
> > > similar PR to other two libraries as well?
> > >
> > >
> > You could potentially try that, but I think that is more of a stretch
> goal.
> > The approach for CuPy or mkl-fft would have to be different, because for
> > those two cases the underlying libraries DO NOT have dedicated functions
> > implementing the real-to-real transforms. Also, the underlying FFT
> > libraries are proprietary, so we cannot propose to add new transforms on
> > the C/C++ side. However, it is possible in principle to implement
> > real-to-real transforms using only the already existing complex-valued
> > transforms (albeit at some additional computational/memory cost). Some
> > detailed examples of this are given in the following thread on DSP
> > StackExchange:
> >
> https://dsp.stackexchange.com/questions/2807/fast-cosine-transform-via-fft
> >
> > I think that is probably the only feasible route for real-to-real
> > transforms using those two backends. I think whether or not this type of
> > implementation would give a performance benefit over just reusing the
> > existing scipy.fftpack implementations is unknown.
> >
> > One FFT-related issues that could be improved in CuPy in a more
> > straightforward manner than adding real-to-real support, is improving the
> > real-to-complex and complex-to-real support.  These transforms are
> > supported by the underlying CUFFT library, but support for this within
> CuPy
> > is incomplete.  One issue related to this was opened at (
> > https://github.com/cupy/cupy/issues/1936), but no PR implementing it has
> > been made.
> >
> >
> > > For all the three libraries there are SciPy-compatable routines already
> > > defined. After getting required information using the newly created
> > > interface I need to use them at the backend, right?
> > >
> >
> > Yes, you should rely on the already existing interfaces when implementing
> > the backends in SciPy. Any additional 3rd party libraries would have to
> > provide a scipy-like interface in order to be compatible for use as a
> > backend.
> >
> >
> >
> > >
> > > -Anany
> > >
> > >> ----------------------------------------------------------------------
> > >>
> > >> Message: 1
> > >> Date: Thu, 4 Apr 2019 10:58:27 -0400
> > >> From: Gregory Lee <grlee77 at gmail.com>
> > >> To: SciPy Developers List <scipy-dev at python.org>
> > >> Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 185, Issue 18
> > >> Message-ID:
> > >>         <
> > >> CAJR3sXcJuqQJrDboN5zH-pd7NG-wD8EWCdTCAtQ+vJpnZjKsRw at mail.gmail.com>
> > >> Content-Type: text/plain; charset="utf-8"
> > >>
> > >> Hi Anany,
> > >>
> > >> It is nice to see that you have updated with multiple potential APIs.
> > Can
> > >> some other core SciPy devs also help give feedback on what SciPy would
> > >> find
> > >> preferable? Out of the four you proposed, I think something along the
> > >> lines
> > >> of the second method is cleanest in terms of setting the backend at
> > >> runtime. I think having some aspect from your 4th variant where the
> > >> default
> > >> backend can be read from a configuration file and/or environment
> > variable
> > >> is also desirable so that the user's desired default can always be
> > >> automatically set at import time.
> > >>
> > >> I disagree with the following specific statement, though:
> > >> "It is better to use all the above mentioned ideas because every idea
> > has
> > >> its own benefits besides it gives user the luxury to choose the method
> > >> implementation of backend."
> > >>
> > >> I do not think we want to provide multiple ways to do the same thing.
> It
> > >> can be confusing to users and more work for devs to maintain. I think
> > >> there
> > >> should be one method of setting the backend that the user can either
> > call
> > >> at run time or have it be automatically called based on some sort of
> > >> configuration file and/or environment variable(s) at import time.
> > >>
> > >> - Greg
> > >>
> > >>
> > >> On Tue, Apr 2, 2019 at 2:19 PM Anany Shrey Jain <
> > >> f20170920 at goa.bits-pilani.ac.in> wrote:
> > >>
> > >> > Hey,
> > >> > I have already sent the link to the page containing the list of
> ideas
> > >> for
> > >> > implementation of new API that I propose for this project. Would you
> > >> like
> > >> > to add something to it or give some comments on it? The Gsoc
> proposal
> > >> > deadline is 9th of April and I am planning to put all of this in my
> > >> > proposal to make it effective . So any more ideas or comments will
> be
> > >> > really helpful for me . Here is the link to the page:
> > >> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
> .
> > >> >
> > >> > On Sun, Mar 31, 2019 at 5:23 AM <scipy-dev-request at python.org>
> wrote:
> > >> >
> > >> >>
> > >> >> Message: 1
> > >> >> Date: Sat, 30 Mar 2019 13:31:51 -0400
> > >> >> From: Eric Larson <larson.eric.d at gmail.com>
> > >> >> To: SciPy Developers List <scipy-dev at python.org>
> > >> >> Subject: Re: [SciPy-Dev] GSoC 2019
> > >> >> Message-ID:
> > >> >>         <
> > >> >> CAGu2niVWsKrMukfWcAWAtj-1NBm2utCeh3BOnNku7jNoAcx-kw at mail.gmail.com
> >
> > >> >> Content-Type: text/plain; charset="utf-8"
> > >> >>
> > >> >> It looks like the main ideas are in these bits of code, but not
> > >> explicitly
> > >> >> stated. In brief it looks like the proposed API is to add a
> > >> `fft_object`
> > >> >> kwarg to every function in `scipy.fftpack`. It would be good to
> > discuss
> > >> >> this choice explicitly -- what advantages and disadvantages it has
> > >> >> relative
> > >> >> to other approaches (e.g., creating new namespaces, or having a
> > >> >> `set_backend` function (and/or context manager) that would change
> > >> things
> > >> >> under the hood).
> > >> >>
> > >> >> If you make changes and need more feedback, let us know. The more
> > >> specific
> > >> >> you can be about what you need feedback on (high level ideas, low
> > level
> > >> >> implementation, etc.), the better.
> > >> >>
> > >> >> Eric
> > >> >>
> > >> >>
> > >> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
> > >> >> f20170920 at goa.bits-pilani.ac.in> wrote:
> > >> >>
> > >> >> > Hey,
> > >> >> > I went through the idea list of Scipy for this years's GSoC and I
> > >> intend
> > >> >> > to work towards the idea of revamping the Scipy's fftpack. I have
> > >> >> already
> > >> >> > been contributing to Scipy since the end of last year and I have
> > some
> > >> >> > knowledge about Fourier transforms as it was the part of my
> > >> discipline.
> > >> >> I
> > >> >> > could not take part in this discussion earlier because my mid
> > >> semester
> > >> >> > exams were going on, but since they are now over so I can devote
> as
> > >> much
> > >> >> > time as required on this project. I have already created a github
> > >> page
> > >> >> with
> > >> >> > some code snippets and functionalities that we can implement,
> here
> > is
> > >> >> the
> > >> >> > link to it:
> > >> >> >
> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
> > >> .
> > >> >> >
> > >> >> > Cheers,
> > >> >> > Anany Jain
> > >> >> >
> > >> >> > _______________________________________________
> > >> >> > SciPy-Dev mailing list
> > >> >> > SciPy-Dev at python.org
> > >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >
> > >> >> -------------- next part --------------
> > >> >> An HTML attachment was scrubbed...
> > >> >> URL: <
> > >> >>
> > >>
> >
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/f1755dfb/attachment-0001.html
> > >> >> >
> > >> >>
> > >> >> ------------------------------
> > >> >>
> > >> >> Message: 2
> > >> >> Date: Sat, 30 Mar 2019 19:38:41 -0400
> > >> >> From: Gregory Lee <grlee77 at gmail.com>
> > >> >> To: SciPy Developers List <scipy-dev at python.org>
> > >> >> Subject: Re: [SciPy-Dev] GSoC 2019
> > >> >> Message-ID:
> > >> >>         <CAJR3sXfnnr-0JO87gLbhh-7b-w=KjaNpac+F+FHTeFt2K=_
> > >> >> QMw at mail.gmail.com>
> > >> >> Content-Type: text/plain; charset="utf-8"
> > >> >>
> > >> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
> > >> >> f20170920 at goa.bits-pilani.ac.in> wrote:
> > >> >>
> > >> >> > Hey,
> > >> >> > I went through the idea list of Scipy for this years's GSoC and I
> > >> intend
> > >> >> > to work towards the idea of revamping the Scipy's fftpack. I have
> > >> >> already
> > >> >> > been contributing to Scipy since the end of last year and I have
> > some
> > >> >> > knowledge about Fourier transforms as it was the part of my
> > >> discipline.
> > >> >> I
> > >> >> > could not take part in this discussion earlier because my mid
> > >> semester
> > >> >> > exams were going on, but since they are now over so I can devote
> as
> > >> much
> > >> >> > time as required on this project. I have already created a github
> > >> page
> > >> >> with
> > >> >> > some code snippets and functionalities that we can implement,
> here
> > is
> > >> >> the
> > >> >> > link to it:
> > >> >> >
> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
> > >> .
> > >> >> >
> > >> >> > Cheers,
> > >> >> > Anany Jain
> > >> >> >
> > >> >> > _______________________________________________
> > >> >> > SciPy-Dev mailing list
> > >> >> > SciPy-Dev at python.org
> > >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >>
> > >> >>
> > >> >> Hi Anany,
> > >> >>
> > >> >> Thank you for your interest in GSOC with SciPy!  It's great to see
> > that
> > >> >> you
> > >> >> are already thinking about a potential API and learning about the
> 3rd
> > >> >> party
> > >> >> FFT libraries. Along the lines of Eric's comment, think about what
> > this
> > >> >> API
> > >> >> choice implies for users of libraries built upon SciPy. Would users
> > of
> > >> 3rd
> > >> >> party libraries that rely on SciPy's FFTs be immediately able to
> take
> > >> >> advantage of a differentf FFT backend in this scenario? (in other
> > >> words,
> > >> >> the case where the user is not calling scipy.fftpack.fft directly
> but
> > >> is
> > >> >> using it only indirectly via a function in a downstream library).
> > >> >>
> > >> >> Matplotlib is an example of an existing Python library supporting
> > >> multiple
> > >> >> backends that can be considered for comparison (see:
> > >> >> https://matplotlib.org/faq/usage_faq.html#what-is-a-backend).
> Think
> > >> about
> > >> >> the relative benefits/drawbacks of some of the methods they use for
> > >> >> setting
> > >> >> a backend there as compared to the approach proposed for FFTs here.
> > >> >>
> > >> >> Another thing that should be considered: pyFFTW, MKL and CuPy
> already
> > >> have
> > >> >> some functions that match the existing scipy.fftpack API, but they
> > may
> > >> >> have
> > >> >> one or more additional arguments particular to features of that
> > >> library.
> > >> >> How would you propose to deal with supporting additional optional
> > >> >> arguments
> > >> >> on the SciPy end?
> > >> >>
> > >> >> One other minor comment: I know that the blog post you made may be
> > >> serving
> > >> >> partly as personal notes, but please do not directly copy sections
> of
> > >> text
> > >> >> (e.g. the description of BLAS/LAPACK libraries) from elsewhere
> > without
> > >> >> attribution when writing a final proposal. (Also, the FFT functions
> > are
> > >> >> separate from the BLAS/LAPACK functions in MKL, so you will not
> need
> > to
> > >> >> discuss BLAS or LAPACK specifically in your proposal)
> > >> >>
> > >> >> - Greg
> > >> >> -------------- next part --------------
> > >> >> An HTML attachment was scrubbed...
> > >> >> URL: <
> > >> >>
> > >>
> >
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/c1351e7e/attachment-0001.html
> > >> >> >
> > >> >>
> > >> >> ------------------------------
> > >> >>
> > >> >> Message: 3
> > >> >> Date: Sat, 30 Mar 2019 19:53:02 -0400
> > >> >> From: Gregory Lee <grlee77 at gmail.com>
> > >> >> To: SciPy Developers List <scipy-dev at python.org>
> > >> >> Subject: Re: [SciPy-Dev] GSoC 2019
> > >> >> Message-ID:
> > >> >>         <CAJR3sXdcPMAn_DETF8W-=
> > >> >> MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw at mail.gmail.com>
> > >> >> Content-Type: text/plain; charset="utf-8"
> > >> >>
> > >> >> Hi Gopi,
> > >> >>
> > >> >> I am not sure I follow exactly what you are suggesting here. Are
> you
> > >> >> proposing that the `fftpackN` variable in your example would be a
> > >> Python
> > >> >> module corresponding to a given backend? If so, why is an array of
> > >> data,
> > >> >> z,
> > >> >> being passed into the newAPI function here? I don't see why a data
> > >> array
> > >> >> should be needed at all to choose a backend.
> > >> >>
> > >> >> Please also see my response to Anany's recent post on this list
> for a
> > >> >> couple of other suggestions of things to consider in terms of the
> > API.
> > >> >>
> > >> >> - Greg
> > >> >>
> > >> >>
> > >> >> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
> > >> >> deathcoderx at gmail.com>
> > >> >> wrote:
> > >> >>
> > >> >> > Hey,
> > >> >> > I went through the code and got some ideas.
> > >> >> > So what will happen is:
> > >> >> > First, we will declare FFTW as we use them normally.
> > >> >> >
> > >> >> > z = np.random.rand(2, 128, 64)
> > >> >> > pyfftw.FFTW(z, axes=(-1, ))
> > >> >> > ..
> > >> >> > ..
> > >> >> > Now after declaring our basic work to shift to another FFTpack,
> > what
> > >> we
> > >> >> > can do is:
> > >> >> > fftPackN= newAPI(z, pack = 'PYFFTW');
> > >> >> >
> > >> >> > Pack will take the name of the 3rd party FFT pack which we want
> to
> > >> use.
> > >> >> > Suggestions needed.
> > >> >> >
> > >> >> > Cheers.
> > >> >> >
> > >> >> >
> > >> >>
> > >> >> >
> > >> >> > On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <
> > larson.eric.d at gmail.com
> > >> >
> > >> >> > wrote:
> > >> >> >
> > >> >> >> After reading the related issues and thinking about the problem,
> > >> >> perhaps
> > >> >> >> the best first step is you come up with some initial API
> proposal.
> > >> >> >>
> > >> >> >> One way to work through the process is to think about the use
> > cases
> > >> >> that
> > >> >> >> we want to support. How should users actually write code to use
> > the
> > >> new
> > >> >> >> functionality? You can start with short code snippets that do
> not
> > >> work
> > >> >> >> currently, but should work for users at the end of the project.
> > Then
> > >> >> think
> > >> >> >> about what needs to change inside SciPy for these code snippets
> to
> > >> >> work.
> > >> >> >> This can become an iterative process as you realize that the
> SciPy
> > >> >> changes
> > >> >> >> might be better or easier with changes to the user-facing API,
> > etc.
> > >> >> >>
> > >> >> >> Eric
> > >> >> >>
> > >> >> >>
> > >> >> >> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
> > >> >> >> deathcoderx at gmail.com> wrote:
> > >> >> >>
> > >> >> >>> Hey,
> > >> >> >>> As proposal submission period started I want to discuss a bit
> > anobt
> > >> >> how
> > >> >> >>> can we implement the API.
> > >> >> >>> I would very much appriciate inputs and guidance.
> > >> >> >>>
> > >> >> >>> Cheers.
> > >> >> >>>
> > >> >> >>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <
> > >> larson.eric.d at gmail.com>
> > >> >> >>> wrote:
> > >> >> >>>
> > >> >> >>>> The best way to figure that out is probably to take a look at
> > >> some of
> > >> >> >>>> the existing (minor) SciPy GitHub issues and try to work on
> one
> > or
> > >> >> two that
> > >> >> >>>> you feel like working on. Actually trying to work out how to
> > >> >> contribute
> > >> >> >>>> code changes (as independently as possible/reasonable based on
> > the
> > >> >> existing
> > >> >> >>>> guides/docs already discoverable online) will quickly
> highlight
> > >> >> things that
> > >> >> >>>> need to be learned. Some of the general things are the SciPy
> > >> >> contributing
> > >> >> >>>> guidelines, standard GitHub PR workflow, communication with
> > >> >> reviewers, and
> > >> >> >>>> so forth.
> > >> >> >>>>
> > >> >> >>>> For this particular project, it's important to understand the
> > >> various
> > >> >> >>>> flavors and properties of FFT in SciPy (real, complex,
> > >> n-dimensional,
> > >> >> >>>> caching plans, etc.) as well as other projects like NumPy,
> CuPy,
> > >> and
> > >> >> >>>> pyFFTW. Some of this can be learned and improved upon as part
> of
> > >> >> GSoC, but
> > >> >> >>>> the more you know and can demonstrate / put into practice
> > >> knowledge
> > >> >> of
> > >> >> >>>> before the applications are reviewed, the better.
> > >> >> >>>>
> > >> >> >>>> Eric
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
> > >> >> >>>> deathcoderx at gmail.com> wrote:
> > >> >> >>>>
> > >> >> >>>>> Thank you for the detailed reply.
> > >> >> >>>>> I will keep these point in mind while preparing my proposal.
> > >> Apart
> > >> >> >>>>> from proposal, what skills shall I improve so that I can
> > >> contribute
> > >> >> more
> > >> >> >>>>> effectively and efficiently.
> > >> >> >>>>>
> > >> >> >>>>> Cheers.
> > >> >> >>>>>
> > >> >> >>>>>
> > >> >> >>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <
> > >> larson.eric.d at gmail.com>
> > >> >> >>>>> wrote:
> > >> >> >>>>>
> > >> >> >>>>>> There are a number of considerations that would be good to
> > >> address.
> > >> >> >>>>>> I'd start by considering the things that are typically
> > >> considered
> > >> >> >>>>>> when making changes to SciPy
> > >> >> >>>>>> <
> > >> >>
> > >>
> >
> https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy
> > >> >> >,
> > >> >> >>>>>> but I'd expand it to a longer list since the scope is bigger
> > >> than
> > >> >> a typical
> > >> >> >>>>>> single PR. The list would contain (at least):
> > >> >> >>>>>>
> > >> >> >>>>>> - what will the user-facing API / contract be?
> > >> >> >>>>>> - what in SciPy needs to change to allow it (internals /
> > >> >> >>>>>> implementation outline, perhaps skeleton functions/classes)?
> > >> >> >>>>>> - what examples should we show users (in general this ends
> up
> > >> being
> > >> >> >>>>>> just simple use cases of the API)?
> > >> >> >>>>>> - how will we test it for correctness?
> > >> >> >>>>>> - how will we benchmark it to prevent performance
> regressions?
> > >> >> >>>>>> - how can we break up the work for these steps (if possible)
> > >> into
> > >> >> >>>>>> separable, sequential (or -- better but not usually possible
> > --
> > >> >> >>>>>> independent) PRs?
> > >> >> >>>>>>
> > >> >> >>>>>> You might notice that none of these points are actually all
> > that
> > >> >> >>>>>> specific to the FFT project, but can be generally applicable
> > to
> > >> >> GSoC
> > >> >> >>>>>> projects. For the FFT project, I would say "how do we build
> > the
> > >> >> backend" is
> > >> >> >>>>>> indeed implicitly contained / outlined in these bullet
> points.
> > >> And
> > >> >> as with
> > >> >> >>>>>> most projects, the first two points (and possibly the last)
> > will
> > >> >> probably
> > >> >> >>>>>> be the most challenging to sort out.
> > >> >> >>>>>>
> > >> >> >>>>>> Eric
> > >> >> >>>>>>
> > >> >> >>>>>>
> > >> >> >>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
> > >> >> >>>>>> deathcoderx at gmail.com> wrote:
> > >> >> >>>>>>
> > >> >> >>>>>>> Hey Eric,
> > >> >> >>>>>>> So for my proposal, shall I include how can we built a back
> > >> end?
> > >> >> >>>>>>> What all points shall I include to make it effective?
> > >> >> >>>>>>>
> > >> >> >>>>>>> Cheers.
> > >> >> >>>>>>>
> > >> >> >>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <
> > >> larson.eric.d at gmail.com
> > >> >> >
> > >> >> >>>>>>> wrote:
> > >> >> >>>>>>>
> > >> >> >>>>>>>> That would be me -- don't worry, I'm on this list, as are
> > >> >> >>>>>>>> (presumably) other developers interested in the
> discussion,
> > so
> > >> >> no need to
> > >> >> >>>>>>>> document elsewhere for now from our end. It looks like
> Greg
> > >> has
> > >> >> summarized
> > >> >> >>>>>>>> the current status and thoughts we've had, so I don't have
> > >> much
> > >> >> to add at
> > >> >> >>>>>>>> this point.
> > >> >> >>>>>>>>
> > >> >> >>>>>>>> Eric
> > >> >> >>>>>>>>
> > >> >> >>>>>>>>
> > >> >> >>>>>>>>
> > >> >> >>>>>>>>
> > >> >> >>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
> > >> >> >>>>>>>> deathcoderx at gmail.com> wrote:
> > >> >> >>>>>>>>
> > >> >> >>>>>>>>> Hey Greg,
> > >> >> >>>>>>>>> I got the basic idea about what we want to implement this
> > >> year.
> > >> >> >>>>>>>>> Our first priority is to create a backend for 3rd party
> > >> >> fftpacks.
> > >> >> >>>>>>>>> We can create API using Python and Flask or any other
> > >> suitable
> > >> >> framework.
> > >> >> >>>>>>>>>
> > >> >> >>>>>>>>> I thought this discussion was going on on SciPy Developer
> > >> List
> > >> >> >>>>>>>>> only. So do I need to document it all and post it
> somewhere
> > >> so
> > >> >> that other
> > >> >> >>>>>>>>> contributors can see this?
> > >> >> >>>>>>>>> Also, I couldn't find any contact info regarding Eric. It
> > >> would
> > >> >> be
> > >> >> >>>>>>>>> very helpful if we include him in this discussion as this
> > is
> > >> a
> > >> >> roadmap for
> > >> >> >>>>>>>>> GSoC project and I can also get more insight into the
> > project
> > >> >> and expected
> > >> >> >>>>>>>>> outcomes.
> > >> >> >>>>>>>>>
> > >> >> >>>>>>>>> Cheers.
> > >> >> >>>>>>>>>
> > >> >> >>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <
> > >> grlee77 at gmail.com>
> > >> >> >>>>>>>>> wrote:
> > >> >> >>>>>>>>>
> > >> >> >>>>>>>>>>
> > >> >> >>>>>>>>>>
> > >> >> >>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
> > >> >> >>>>>>>>>> deathcoderx at gmail.com> wrote:
> > >> >> >>>>>>>>>>
> > >> >> >>>>>>>>>>> Hey Gregory,
> > >> >> >>>>>>>>>>> I went through the idea and I am very much interested
> in
> > >> >> working
> > >> >> >>>>>>>>>>> on it. I had Fourier Transforms as a part of my
> academic
> > >> >> course, so I am
> > >> >> >>>>>>>>>>> well aware with basic concepts.
> > >> >> >>>>>>>>>>> One thing I want to discuss is, its mentioned that we
> > have
> > >> to
> > >> >> >>>>>>>>>>> create a backend system for 3rd party FFTpacks so my
> > dobuts
> > >> >> >>>>>>>>>>>
> > >> >> >>>>>>>>>>
> > >> >> >>>>>>>>>>
> > >> >> >>>>>>>>>>> 1. How are we going to create API?
> > >> >> >>>>>>>>>>>
> > >> >> >>>>>>>>>>
> > >> >> >>>>>>>>>> This will needed to be decided on in consensus with the
> > >> SciPy
> > >> >> >>>>>>>>>> developers and user community. I am mentoring for the
> > >> project
> > >> >> as a
> > >> >> >>>>>>>>>> contributor here and a maintainer of the related pyFFTW
> > >> >> package, but I am
> > >> >> >>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core
> > dev
> > >> >> here). I have
> > >> >> >>>>>>>>>> not discussed the API in any detail with the SciPy team
> at
> > >> >> this stage.
> > >> >> >>>>>>>>>> Working out details of what the API should look like and
> > >> >> working to
> > >> >> >>>>>>>>>> finalize that in collaboration with the community will
> be
> > a
> > >> >> primary task
> > >> >> >>>>>>>>>> during the early part of the GSOC project.
> > >> >> >>>>>>>>>>
> > >> >> >>>>>>>>>> 2. After the creation of backend will user at the time
> of
> > >> >> >>>>>>>>>>> installation of SciPy will decide what all 3rd party
> > >> FFTpacks
> > >> >> he needs or
> > >> >> >>>>>>>>>>> we will include some by default?
> > >> >> >>>>>>>>>>>
> > >> >> >>>>>>>>>>> The idea is to allow users to opt-in to a different FFT
> > >> >> backend
> > >> >> >>>>>>>>>> at run time, but these alternative libraries will not be
> > >> >> distributed with
> > >> >> >>>>>>>>>> SciPy itself due to incompatible software licenses
> (pyFFTW
> > >> and
> > >> >> mkl-fft) or
> > >> >> >>>>>>>>>> a requirement for specific hardware (CuPy requires an
> > NVIDIA
> > >> >> GPU). SciPy
> > >> >> >>>>>>>>>> will continue to offer its own bundled FFT library
> > >> (currently
> > >> >> fftpack, but
> > >> >> >>>>>>>>>> this could be switched to pocketfft as discussed in the
> > >> ideas
> > >> >> page). The
> > >> >> >>>>>>>>>> purpose of the backend interface is to provide a
> > convenient
> > >> >> way for users
> > >> >> >>>>>>>>>> to have third party libraries perform the FFTs instead,
> > but
> > >> >> under the
> > >> >> >>>>>>>>>> existing scipy.fftpack API. This is motivated by a
> desire
> > by
> > >> >> end users and
> > >> >> >>>>>>>>>> downstream projects to have features such as
> > multi-threading
> > >> >> (pyFFTW and
> > >> >> >>>>>>>>>> mkl-fft) or GPU support (CuPy) that are not implemented
> in
> > >> >> scipy.fftpack.
> > >> >> >>>>>>>>>> Ultimately it will be up to users that opt-in to using
> > these
> > >> >> other
> > >> >> >>>>>>>>>> libraries to confirm that the license terms and are
> > >> compatible
> > >> >> with their
> > >> >> >>>>>>>>>> use case.
> > >> >> >>>>>>>>>>
> > >> >> >>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev
> > mailing
> > >> >> >>>>>>>>>> lists prefers replies **below** the email you are
> replying
> > >> to
> > >> >> so people can
> > >> >> >>>>>>>>>> more easily follow the thread of discussion. There are
> > some
> > >> >> guidelines at:
> > >> >> >>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
> > >> >> >>>>>>>>>>
> > >> >> >>>>>>>>>>
> > >> >> >>>>>>>>>>
> > >> >> >>>>>>>>>> I will research more about how to implement a backend
> > myself
> > >> >> and
> > >> >> >>>>>>>>>>> will let you know as soon as I come up with something
> > new.
> > >> >> >>>>>>>>>>>
> > >> >> >>>>>>>>>>>
> > >> >> >>>>>>>>>> CHeers,
> > >> >> >>>>>>>>>>> Greg
> > >> >> >>>>>>>>>>>
> > >> >> >>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <
> > >> >> grlee77 at gmail.com>
> > >> >> >>>>>>>>>>> wrote:
> > >> >> >>>>>>>>>>>
> > >> >> >>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
> > >> >> >>>>>>>>>>>> deathcoderx at gmail.com> wrote:
> > >> >> >>>>>>>>>>>>
> > >> >> >>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started
> fixing
> > >> some
> > >> >> >>>>>>>>>>>>> bugs, also made some pull request. Can anyone suggest
> > me
> > >> >> how should I
> > >> >> >>>>>>>>>>>>> proceed further?
> > >> >> >>>>>>>>>>>>> _______________________________________________
> > >> >> >>>>>>>>>>>>> SciPy-Dev mailing list
> > >> >> >>>>>>>>>>>>> SciPy-Dev at python.org
> > >> >> >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >>>>>>>>>>>>
> > >> >> >>>>>>>>>>>>
> > >> >> >>>>>>>>>>>> Hi Gopi,
> > >> >> >>>>>>>>>>>>
> > >> >> >>>>>>>>>>>> I think you have probably already found it, but the
> GSOC
> > >> >> >>>>>>>>>>>> project we have already identified mentors for in
> SciPy
> > is
> > >> >> here:
> > >> >> >>>>>>>>>>>>
> > >> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
> > >> >> >>>>>>>>>>>>
> > >> >> >>>>>>>>>>>> If this is a project you are interested in then I
> would
> > >> start
> > >> >> >>>>>>>>>>>> thinking about what the FFT interface would look like
> > and
> > >> >> reviewing some of
> > >> >> >>>>>>>>>>>> the past/present issues related to fftpack / FFT in
> > SciPy.
> > >> >> Please ask
> > >> >> >>>>>>>>>>>> questions you have related to that project here so
> that
> > >> you
> > >> >> can clarify
> > >> >> >>>>>>>>>>>> what would be involved in writing a successful
> > >> application.
> > >> >> >>>>>>>>>>>>
> > >> >> >>>>>>>>>>>> If you have a different idea in mind you can propose
> it
> > >> here,
> > >> >> >>>>>>>>>>>> but you should do that soon, because it will be
> > necessary
> > >> to
> > >> >> determine if
> > >> >> >>>>>>>>>>>> there is interest from the SciPy team before you spend
> > >> time
> > >> >> coming up with
> > >> >> >>>>>>>>>>>> a detailed proposal. We have to determine if a project
> > >> >> sounds feasible to
> > >> >> >>>>>>>>>>>> complete for GSOC and if appropriate mentors can be
> > >> >> identified.
> > >> >> >>>>>>>>>>>>
> > >> >> >>>>>>>>>>>> Ultimately, you will need to submit an application to
> > >> SciPy
> > >> >> >>>>>>>>>>>> between March 25th - April 9th.
> > >> >> >>>>>>>>>>>>
> > >> >> >>>>>>>>>>>> Cheers,
> > >> >> >>>>>>>>>>>> Greg
> > >> >> >>>>>>>>>>>>
> > >> >> >>>>>>>>>>>>
> > >> >> >>>>>>>>>>>> _______________________________________________
> > >> >> >>>>>>>>>>>> SciPy-Dev mailing list
> > >> >> >>>>>>>>>>>> SciPy-Dev at python.org
> > >> >> >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >>>>>>>>>>>>
> > >> >> >>>>>>>>>>> _______________________________________________
> > >> >> >>>>>>>>>>> SciPy-Dev mailing list
> > >> >> >>>>>>>>>>> SciPy-Dev at python.org
> > >> >> >>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >>>>>>>>>>>
> > >> >> >>>>>>>>>> _______________________________________________
> > >> >> >>>>>>>>>> SciPy-Dev mailing list
> > >> >> >>>>>>>>>> SciPy-Dev at python.org
> > >> >> >>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >>>>>>>>>>
> > >> >> >>>>>>>>> _______________________________________________
> > >> >> >>>>>>>>> SciPy-Dev mailing list
> > >> >> >>>>>>>>> SciPy-Dev at python.org
> > >> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >>>>>>>>>
> > >> >> >>>>>>>> _______________________________________________
> > >> >> >>>>>>>> SciPy-Dev mailing list
> > >> >> >>>>>>>> SciPy-Dev at python.org
> > >> >> >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >>>>>>>>
> > >> >> >>>>>>> _______________________________________________
> > >> >> >>>>>>> SciPy-Dev mailing list
> > >> >> >>>>>>> SciPy-Dev at python.org
> > >> >> >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >>>>>>>
> > >> >> >>>>>> _______________________________________________
> > >> >> >>>>>> SciPy-Dev mailing list
> > >> >> >>>>>> SciPy-Dev at python.org
> > >> >> >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >>>>>>
> > >> >> >>>>> _______________________________________________
> > >> >> >>>>> SciPy-Dev mailing list
> > >> >> >>>>> SciPy-Dev at python.org
> > >> >> >>>>> https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >>>>>
> > >> >> >>>> _______________________________________________
> > >> >> >>>> SciPy-Dev mailing list
> > >> >> >>>> SciPy-Dev at python.org
> > >> >> >>>> https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >>>>
> > >> >> >>> _______________________________________________
> > >> >> >>> SciPy-Dev mailing list
> > >> >> >>> SciPy-Dev at python.org
> > >> >> >>> https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >>>
> > >> >> >> _______________________________________________
> > >> >> >> SciPy-Dev mailing list
> > >> >> >> SciPy-Dev at python.org
> > >> >> >> https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >>
> > >> >> > _______________________________________________
> > >> >> > SciPy-Dev mailing list
> > >> >> > SciPy-Dev at python.org
> > >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >> >
> > >> >> -------------- next part --------------
> > >> >> An HTML attachment was scrubbed...
> > >> >> URL: <
> > >> >>
> > >>
> >
> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/54f38250/attachment.html
> > >> >> >
> > >> >>
> > >> >> ------------------------------
> > >> >>
> > >> >> Subject: Digest Footer
> > >> >>
> > >> >> _______________________________________________
> > >> >> SciPy-Dev mailing list
> > >> >> SciPy-Dev at python.org
> > >> >> https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >>
> > >> >>
> > >> >> ------------------------------
> > >> >>
> > >> >> End of SciPy-Dev Digest, Vol 185, Issue 18
> > >> >> ******************************************
> > >> >>
> > >> > _______________________________________________
> > >> > SciPy-Dev mailing list
> > >> > SciPy-Dev at python.org
> > >> > https://mail.python.org/mailman/listinfo/scipy-dev
> > >> >
> > >> -------------- next part --------------
> > >> An HTML attachment was scrubbed...
> > >> URL: <
> > >>
> >
> http://mail.python.org/pipermail/scipy-dev/attachments/20190404/1a670020/attachment.html
> > >> >
> > >>
> > >> ------------------------------
> > >>
> > >> Subject: Digest Footer
> > >>
> > >> _______________________________________________
> > >> SciPy-Dev mailing list
> > >> SciPy-Dev at python.org
> > >> https://mail.python.org/mailman/listinfo/scipy-dev
> > >>
> > >>
> > >> ------------------------------
> > >>
> > >> End of SciPy-Dev Digest, Vol 186, Issue 11
> > >> ******************************************
> > >>
> > > _______________________________________________
> > > SciPy-Dev mailing list
> > > SciPy-Dev at python.org
> > > https://mail.python.org/mailman/listinfo/scipy-dev
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> >
> http://mail.python.org/pipermail/scipy-dev/attachments/20190405/cc4019f5/attachment.html
> > >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at python.org
> > https://mail.python.org/mailman/listinfo/scipy-dev
> >
> >
> > ------------------------------
> >
> > End of SciPy-Dev Digest, Vol 186, Issue 15
> > ******************************************
> >
> _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at python.org
> > https://mail.python.org/mailman/listinfo/scipy-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/scipy-dev/attachments/20190408/a59718a0/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
>
> ------------------------------
>
> End of SciPy-Dev Digest, Vol 186, Issue 22
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190409/79b4e894/attachment-0001.html>

From ralf.gommers at gmail.com  Tue Apr  9 00:59:40 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 9 Apr 2019 06:59:40 +0200
Subject: [SciPy-Dev] Fix ndimage.rotate plane check
In-Reply-To: <f626af9f-dba8-1c20-041d-c83177324eac@gmail.com>
References: <f626af9f-dba8-1c20-041d-c83177324eac@gmail.com>
Message-ID: <CABL7CQiTN6bZEOxdaw341EjUT7ixv-L13x=gquu1naAakw8PwA@mail.gmail.com>

On Mon, Apr 8, 2019 at 11:36 AM Riadh <rfezzani at gmail.com> wrote:

> Hello,
>
> I opened the issue #10011 <https://github.com/scipy/scipy/issues/10011>
> about wrong validation of rotation plane axes in the
> ndimage.interpolation.rotate function.
>
> I also made some propositions for refactoring this function. You can see
> my contribution in the pull request #10028
> <https://github.com/scipy/scipy/pull/10028>.
>
> This is my first time filling a pull request for Scipy, so I hope that
> every thing is OK with it.
>
This all looked really good, thanks Riadh

Cheers,
Ralf


> Thank you for your review and comments,
>
> Riadh.
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190409/c815a519/attachment.html>

From ralf.gommers at gmail.com  Tue Apr  9 01:24:16 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 9 Apr 2019 07:24:16 +0200
Subject: [SciPy-Dev] GSoC 2019: Project Proposal
In-Reply-To: <CAJR3sXdxc-3EHBMXHwtT4_5pVM-J2Lb9_FV1y8v1fBs9J3iC3w@mail.gmail.com>
References: <mailman.2071.1554480810.2938.scipy-dev@python.org>
 <CAG7Qgjhy-X-vDqxS8sS7SZ8Lv-YdySpwTQKb1QUuXRvXmM4y4w@mail.gmail.com>
 <CAJR3sXdxc-3EHBMXHwtT4_5pVM-J2Lb9_FV1y8v1fBs9J3iC3w@mail.gmail.com>
Message-ID: <CABL7CQiTHY8PQTnrTXj9p=yJbpA_FV7X-OT9ExLPfJVu98hsgw@mail.gmail.com>

On Mon, Apr 8, 2019 at 7:54 AM Gregory Lee <grlee77 at gmail.com> wrote:

>
>
> On Sat, Apr 6, 2019 at 5:08 PM Anany Shrey Jain <
> f20170920 at goa.bits-pilani.ac.in> wrote:
>
>>
>> Hey ,
>> Thanks Greg for a detailed reply. I will be working on both
>> https://github.com/pyFFTW/pyFFTW/pull/256 and
>> https://github.com/cupy/cupy/issues/1936 as a part of this project. I
>> have constructed my API implementation based on the `set_backend`  function
>> approach, but in comparatively cleaner way. I have written my proposal for
>> this project and here is a link to it:
>> https://docs.google.com/document/d/1TIiH9j3rPAN--53MwjZz7NFO1GGtxmEH3RiGzvqnEBk/edit?usp=sharing.
>> Please go through my proposal and if possible send some feedback on it.
>>
>> -Anany
>>
>>
> Hi Anany,
>
> I appreciate that you have narrowed down some of the possibilities. The
> API will need further refinement to reach consensus, but the general
> concept as presented seems reasonable and I don't think we have to reach
> consensus on the finer implementation details for purposes of the proposal.
> I am not sure it is necessary to have the `set_backend` function return a
> class that allows setting additional arguments. Ralf's made a comment
> earlier that was in favor of just supporting the arguments currently
> present in SciPy's fftpack. I was also thinking something a bit simpler in
> terms of just reading the name of the backend from a configuration file or
> environment variable as opposed to running a full configuration script, but
> others may disagree.
>

The google doc proposal right now seems to say environment variable. I
think that's fine, better than a config file/script (which I'd really like
to avoid). The name should be scipy-specific though, right now it says
"BACKENDPATH". Perhaps something like "SCIPY_FFT_BACKEND".

As for setting it in code, a context manager would be nice in addition to a
regular function. API something like:

1. set_backend(name)
2. get_backend()
3. with fftpack.backend(name):



> I will comment mainly on the timeline section of the proposal as we did
> not discuss that previously:
>
> I think the timeline is a bit overly optimistic and dedicates too much
> time to third party libraries. It is probably not realistically going to be
> possible to complete changes to SciPy as well as pyFFTW, mkl_fft and CuPy.
> I would focus the majority of the timeline on SciPy itself. You can leave
> the text about working on the pyFFTW and CuPy issues as goals for weeks
> 9-12, but I think all work in the early weeks should be in SciPy itself and
> not require any changes to the third-party libraries in order for the
> backend code to function. Each of the third party libraries already has a
> substantial portion of the SciPy API implemented and can usefully be
> integrated as backends as-is.
>
> I think you can keep the plan to implement an initial interface and pyFFTW
> support in weeks 1-2, but I think week 3-4 should be primarily along the
> lines of improving and revising the initial interface based on reviewer
> feedback from your first PR. Realistically, it will take a substantial
> amount of time to reach agreement among all parties and code will not be
> merged right away. I would focus weeks 3-4 on revising based on feedback
> rather than proposing to "make CuPy compatible". CuPy already has
> compatible interfaces for many of the functions (
> https://github.com/cupy/cupy/blob/master/cupyx/scipy/fftpack/fft.py).
>
> Week 5 seems to be missing from the timeline?
>
> I would remove the item about adding changes to mkl_fft (in week 6). Was
> there something specific you had in mind for that? There are already
> existing wrappers (
> https://github.com/IntelPython/mkl_fft/blob/master/mkl_fft/_scipy_fft.py)
> and I'm not sure there is much more to do there.  A suitable replacement
> for the week 5-6 section of the timeline could be working on the SciPy user
> documentation detailing how to use and configure the backends. It could be
> considered to potentially make small PRs to third party library
> documentation as well, mentioning how scipy can be configured to use them
> as its default backend. For instance, the new backend-based approach will
> be preferable to the monkey patching currently discussed in the pyFFTW docs.
>
> I proposed above to remove mention of CuPy from weeks 3-4 to reduce the
> overall proportion of time in the proposal that is related to CuPy for a
> couple of reasons:
>
> 1.) There is no existing precedent for interfacing with GPU code from
> SciPy so that may be a little controversial among the larger group of SciPy
> developers and have a harder time of getting merged. If we assume NumPy
> inputs should give NumPy outputs then the required host/device memory
> transfers will reduce performance, making the GPU-based approach only
> beneficial for large transforms. We could allow GPU-based input/output, but
> other functions in SciPy itself do not support GPU-based arrays.
>

None of the code in SciPy should directly rely on GPUs, however some code
in SciPy may already work if you pass in a CuPy array (due to
__array_ufunc__ and __array_function__). When you think about a CuPy
backend, it should work by passing in CuPy arrays instead of NumPy arrays,
and having things work transparently via those array protocols. It doesn't
really make sense to put in code to convert array types imho, that will be
inefficient and hard to maintain.

http://scipy.github.io/devdocs/roadmap.html#support-for-distributed-arrays-and-gpu-arrays
is
the relevant item on our roadmap here.

Cheers,
Ralf



>
> 2.) Using CuPy requires access to a relatively recent (~last five years or
> so) NVidia GPU that supports CUDA (I think at least CUDA 8.0 is required).
> Do you have access to an appropriate GPU? There is no requirement for
> applicants to have access to such hardware, but it will difficult to
> propose making contributions to CuPy itself without it. We may be able to
> work out remote access to a machine that has appropriate hardware, but I
> have not looked into specifics of how we would arrange that yet and cannot
> guarantee it.
>
>
>
>
> Message: 1
>> Date: Fri, 5 Apr 2019 12:13:15 -0400
>> From: Gregory Lee <grlee77 at gmail.com>
>> To: SciPy Developers List <scipy-dev at python.org>
>> Subject: Re: [SciPy-Dev] GSoC 2019
>> Message-ID:
>>         <
>> CAJR3sXeVPAB+jGB_EdxiDg45jbR4wHzLVjjBk7+RiesT0XMrpw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Fri, Apr 5, 2019 at 4:25 AM Anany Shrey Jain <
>> f20170920 at goa.bits-pilani.ac.in> wrote:
>>
>> > Hey Greg,
>> > The project "Revamp FFTPACK" also aims at contributing to third party
>> > libraries to fill in functionality gaps. For pyFFTW I can see that work
>> on
>> > adding Real-to-Real transforms has been going on for a long time. So do
>> I
>> > need to continue the work going on in
>> > https://github.com/pyFFTW/pyFFTW/pull/256 as a part of this project?
>> >
>>
>> It is not a requirement that you work on the pyFFTW wrappers, but that
>> would be a good complement to this project. Here are some thoughts.
>>
>> 1.) I would first have a mechanism to fall back to the existing
>> scipy.fftpack implementations for any functions not currently supported by
>> a given backend. pyFFTW currently already falls back to scipy's own
>> implementation for DCT and DST transforms (
>>
>> https://github.com/pyFFTW/pyFFTW/blob/e9966e5d215a00f89156bd88e1d42b884f85df78/pyfftw/interfaces/scipy_fftpack.py#L81-L82
>> ).
>> The PR you referenced would allow it to use FFTW to perform these
>> transforms instead and there would be no remaining functions that fall
>> back
>> to scipy.fftpack.
>>
>> 2.) You can work on adding real-to-real support in supporting libraries,
>> but this is a secondary goal to pursue once the SciPy side of the project
>> has been completed.
>>    pyFFTW builds on FFTW which does already have functions providing
>> real-to-real transforms. So what you see in the PR referenced above is
>> mainly adding the wrappers for those to pyFFTW.
>>
>>
>>
>> > What needs to be done for the other two libraries? Do I need to make a
>> > similar PR to other two libraries as well?
>> >
>> >
>> You could potentially try that, but I think that is more of a stretch
>> goal.
>> The approach for CuPy or mkl-fft would have to be different, because for
>> those two cases the underlying libraries DO NOT have dedicated functions
>> implementing the real-to-real transforms. Also, the underlying FFT
>> libraries are proprietary, so we cannot propose to add new transforms on
>> the C/C++ side. However, it is possible in principle to implement
>> real-to-real transforms using only the already existing complex-valued
>> transforms (albeit at some additional computational/memory cost). Some
>> detailed examples of this are given in the following thread on DSP
>> StackExchange:
>> https://dsp.stackexchange.com/questions/2807/fast-cosine-transform-via-fft
>>
>> I think that is probably the only feasible route for real-to-real
>> transforms using those two backends. I think whether or not this type of
>> implementation would give a performance benefit over just reusing the
>> existing scipy.fftpack implementations is unknown.
>>
>> One FFT-related issues that could be improved in CuPy in a more
>> straightforward manner than adding real-to-real support, is improving the
>> real-to-complex and complex-to-real support.  These transforms are
>> supported by the underlying CUFFT library, but support for this within
>> CuPy
>> is incomplete.  One issue related to this was opened at (
>> https://github.com/cupy/cupy/issues/1936), but no PR implementing it has
>> been made.
>>
>>
>> > For all the three libraries there are SciPy-compatable routines already
>> > defined. After getting required information using the newly created
>> > interface I need to use them at the backend, right?
>> >
>>
>> Yes, you should rely on the already existing interfaces when implementing
>> the backends in SciPy. Any additional 3rd party libraries would have to
>> provide a scipy-like interface in order to be compatible for use as a
>> backend.
>>
>>
>>
>> >
>> > -Anany
>> >
>> >> ----------------------------------------------------------------------
>> >>
>> >> Message: 1
>> >> Date: Thu, 4 Apr 2019 10:58:27 -0400
>> >> From: Gregory Lee <grlee77 at gmail.com>
>> >> To: SciPy Developers List <scipy-dev at python.org>
>> >> Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 185, Issue 18
>> >> Message-ID:
>> >>         <
>> >> CAJR3sXcJuqQJrDboN5zH-pd7NG-wD8EWCdTCAtQ+vJpnZjKsRw at mail.gmail.com>
>> >> Content-Type: text/plain; charset="utf-8"
>> >>
>> >> Hi Anany,
>> >>
>> >> It is nice to see that you have updated with multiple potential APIs.
>> Can
>> >> some other core SciPy devs also help give feedback on what SciPy would
>> >> find
>> >> preferable? Out of the four you proposed, I think something along the
>> >> lines
>> >> of the second method is cleanest in terms of setting the backend at
>> >> runtime. I think having some aspect from your 4th variant where the
>> >> default
>> >> backend can be read from a configuration file and/or environment
>> variable
>> >> is also desirable so that the user's desired default can always be
>> >> automatically set at import time.
>> >>
>> >> I disagree with the following specific statement, though:
>> >> "It is better to use all the above mentioned ideas because every idea
>> has
>> >> its own benefits besides it gives user the luxury to choose the method
>> >> implementation of backend."
>> >>
>> >> I do not think we want to provide multiple ways to do the same thing.
>> It
>> >> can be confusing to users and more work for devs to maintain. I think
>> >> there
>> >> should be one method of setting the backend that the user can either
>> call
>> >> at run time or have it be automatically called based on some sort of
>> >> configuration file and/or environment variable(s) at import time.
>> >>
>> >> - Greg
>> >>
>> >>
>> >> On Tue, Apr 2, 2019 at 2:19 PM Anany Shrey Jain <
>> >> f20170920 at goa.bits-pilani.ac.in> wrote:
>> >>
>> >> > Hey,
>> >> > I have already sent the link to the page containing the list of ideas
>> >> for
>> >> > implementation of new API that I propose for this project. Would you
>> >> like
>> >> > to add something to it or give some comments on it? The Gsoc proposal
>> >> > deadline is 9th of April and I am planning to put all of this in my
>> >> > proposal to make it effective . So any more ideas or comments will be
>> >> > really helpful for me . Here is the link to the page:
>> >> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
>> .
>> >> >
>> >> > On Sun, Mar 31, 2019 at 5:23 AM <scipy-dev-request at python.org>
>> wrote:
>> >> >
>> >> >>
>> >> >> Message: 1
>> >> >> Date: Sat, 30 Mar 2019 13:31:51 -0400
>> >> >> From: Eric Larson <larson.eric.d at gmail.com>
>> >> >> To: SciPy Developers List <scipy-dev at python.org>
>> >> >> Subject: Re: [SciPy-Dev] GSoC 2019
>> >> >> Message-ID:
>> >> >>         <
>> >> >> CAGu2niVWsKrMukfWcAWAtj-1NBm2utCeh3BOnNku7jNoAcx-kw at mail.gmail.com>
>> >> >> Content-Type: text/plain; charset="utf-8"
>> >> >>
>> >> >> It looks like the main ideas are in these bits of code, but not
>> >> explicitly
>> >> >> stated. In brief it looks like the proposed API is to add a
>> >> `fft_object`
>> >> >> kwarg to every function in `scipy.fftpack`. It would be good to
>> discuss
>> >> >> this choice explicitly -- what advantages and disadvantages it has
>> >> >> relative
>> >> >> to other approaches (e.g., creating new namespaces, or having a
>> >> >> `set_backend` function (and/or context manager) that would change
>> >> things
>> >> >> under the hood).
>> >> >>
>> >> >> If you make changes and need more feedback, let us know. The more
>> >> specific
>> >> >> you can be about what you need feedback on (high level ideas, low
>> level
>> >> >> implementation, etc.), the better.
>> >> >>
>> >> >> Eric
>> >> >>
>> >> >>
>> >> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
>> >> >> f20170920 at goa.bits-pilani.ac.in> wrote:
>> >> >>
>> >> >> > Hey,
>> >> >> > I went through the idea list of Scipy for this years's GSoC and I
>> >> intend
>> >> >> > to work towards the idea of revamping the Scipy's fftpack. I have
>> >> >> already
>> >> >> > been contributing to Scipy since the end of last year and I have
>> some
>> >> >> > knowledge about Fourier transforms as it was the part of my
>> >> discipline.
>> >> >> I
>> >> >> > could not take part in this discussion earlier because my mid
>> >> semester
>> >> >> > exams were going on, but since they are now over so I can devote
>> as
>> >> much
>> >> >> > time as required on this project. I have already created a github
>> >> page
>> >> >> with
>> >> >> > some code snippets and functionalities that we can implement,
>> here is
>> >> >> the
>> >> >> > link to it:
>> >> >> >
>> https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
>> >> .
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Anany Jain
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > SciPy-Dev mailing list
>> >> >> > SciPy-Dev at python.org
>> >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >
>> >> >> -------------- next part --------------
>> >> >> An HTML attachment was scrubbed...
>> >> >> URL: <
>> >> >>
>> >>
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/f1755dfb/attachment-0001.html
>> >> >> >
>> >> >>
>> >> >> ------------------------------
>> >> >>
>> >> >> Message: 2
>> >> >> Date: Sat, 30 Mar 2019 19:38:41 -0400
>> >> >> From: Gregory Lee <grlee77 at gmail.com>
>> >> >> To: SciPy Developers List <scipy-dev at python.org>
>> >> >> Subject: Re: [SciPy-Dev] GSoC 2019
>> >> >> Message-ID:
>> >> >>         <CAJR3sXfnnr-0JO87gLbhh-7b-w=KjaNpac+F+FHTeFt2K=_
>> >> >> QMw at mail.gmail.com>
>> >> >> Content-Type: text/plain; charset="utf-8"
>> >> >>
>> >> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
>> >> >> f20170920 at goa.bits-pilani.ac.in> wrote:
>> >> >>
>> >> >> > Hey,
>> >> >> > I went through the idea list of Scipy for this years's GSoC and I
>> >> intend
>> >> >> > to work towards the idea of revamping the Scipy's fftpack. I have
>> >> >> already
>> >> >> > been contributing to Scipy since the end of last year and I have
>> some
>> >> >> > knowledge about Fourier transforms as it was the part of my
>> >> discipline.
>> >> >> I
>> >> >> > could not take part in this discussion earlier because my mid
>> >> semester
>> >> >> > exams were going on, but since they are now over so I can devote
>> as
>> >> much
>> >> >> > time as required on this project. I have already created a github
>> >> page
>> >> >> with
>> >> >> > some code snippets and functionalities that we can implement,
>> here is
>> >> >> the
>> >> >> > link to it:
>> >> >> >
>> https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
>> >> .
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Anany Jain
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > SciPy-Dev mailing list
>> >> >> > SciPy-Dev at python.org
>> >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>
>> >> >>
>> >> >> Hi Anany,
>> >> >>
>> >> >> Thank you for your interest in GSOC with SciPy!  It's great to see
>> that
>> >> >> you
>> >> >> are already thinking about a potential API and learning about the
>> 3rd
>> >> >> party
>> >> >> FFT libraries. Along the lines of Eric's comment, think about what
>> this
>> >> >> API
>> >> >> choice implies for users of libraries built upon SciPy. Would users
>> of
>> >> 3rd
>> >> >> party libraries that rely on SciPy's FFTs be immediately able to
>> take
>> >> >> advantage of a differentf FFT backend in this scenario? (in other
>> >> words,
>> >> >> the case where the user is not calling scipy.fftpack.fft directly
>> but
>> >> is
>> >> >> using it only indirectly via a function in a downstream library).
>> >> >>
>> >> >> Matplotlib is an example of an existing Python library supporting
>> >> multiple
>> >> >> backends that can be considered for comparison (see:
>> >> >> https://matplotlib.org/faq/usage_faq.html#what-is-a-backend). Think
>> >> about
>> >> >> the relative benefits/drawbacks of some of the methods they use for
>> >> >> setting
>> >> >> a backend there as compared to the approach proposed for FFTs here.
>> >> >>
>> >> >> Another thing that should be considered: pyFFTW, MKL and CuPy
>> already
>> >> have
>> >> >> some functions that match the existing scipy.fftpack API, but they
>> may
>> >> >> have
>> >> >> one or more additional arguments particular to features of that
>> >> library.
>> >> >> How would you propose to deal with supporting additional optional
>> >> >> arguments
>> >> >> on the SciPy end?
>> >> >>
>> >> >> One other minor comment: I know that the blog post you made may be
>> >> serving
>> >> >> partly as personal notes, but please do not directly copy sections
>> of
>> >> text
>> >> >> (e.g. the description of BLAS/LAPACK libraries) from elsewhere
>> without
>> >> >> attribution when writing a final proposal. (Also, the FFT functions
>> are
>> >> >> separate from the BLAS/LAPACK functions in MKL, so you will not
>> need to
>> >> >> discuss BLAS or LAPACK specifically in your proposal)
>> >> >>
>> >> >> - Greg
>> >> >> -------------- next part --------------
>> >> >> An HTML attachment was scrubbed...
>> >> >> URL: <
>> >> >>
>> >>
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/c1351e7e/attachment-0001.html
>> >> >> >
>> >> >>
>> >> >> ------------------------------
>> >> >>
>> >> >> Message: 3
>> >> >> Date: Sat, 30 Mar 2019 19:53:02 -0400
>> >> >> From: Gregory Lee <grlee77 at gmail.com>
>> >> >> To: SciPy Developers List <scipy-dev at python.org>
>> >> >> Subject: Re: [SciPy-Dev] GSoC 2019
>> >> >> Message-ID:
>> >> >>         <CAJR3sXdcPMAn_DETF8W-=
>> >> >> MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw at mail.gmail.com>
>> >> >> Content-Type: text/plain; charset="utf-8"
>> >> >>
>> >> >> Hi Gopi,
>> >> >>
>> >> >> I am not sure I follow exactly what you are suggesting here. Are you
>> >> >> proposing that the `fftpackN` variable in your example would be a
>> >> Python
>> >> >> module corresponding to a given backend? If so, why is an array of
>> >> data,
>> >> >> z,
>> >> >> being passed into the newAPI function here? I don't see why a data
>> >> array
>> >> >> should be needed at all to choose a backend.
>> >> >>
>> >> >> Please also see my response to Anany's recent post on this list for
>> a
>> >> >> couple of other suggestions of things to consider in terms of the
>> API.
>> >> >>
>> >> >> - Greg
>> >> >>
>> >> >>
>> >> >> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
>> >> >> deathcoderx at gmail.com>
>> >> >> wrote:
>> >> >>
>> >> >> > Hey,
>> >> >> > I went through the code and got some ideas.
>> >> >> > So what will happen is:
>> >> >> > First, we will declare FFTW as we use them normally.
>> >> >> >
>> >> >> > z = np.random.rand(2, 128, 64)
>> >> >> > pyfftw.FFTW(z, axes=(-1, ))
>> >> >> > ..
>> >> >> > ..
>> >> >> > Now after declaring our basic work to shift to another FFTpack,
>> what
>> >> we
>> >> >> > can do is:
>> >> >> > fftPackN= newAPI(z, pack = 'PYFFTW');
>> >> >> >
>> >> >> > Pack will take the name of the 3rd party FFT pack which we want to
>> >> use.
>> >> >> > Suggestions needed.
>> >> >> >
>> >> >> > Cheers.
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> >
>> >> >> > On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <
>> larson.eric.d at gmail.com
>> >> >
>> >> >> > wrote:
>> >> >> >
>> >> >> >> After reading the related issues and thinking about the problem,
>> >> >> perhaps
>> >> >> >> the best first step is you come up with some initial API
>> proposal.
>> >> >> >>
>> >> >> >> One way to work through the process is to think about the use
>> cases
>> >> >> that
>> >> >> >> we want to support. How should users actually write code to use
>> the
>> >> new
>> >> >> >> functionality? You can start with short code snippets that do not
>> >> work
>> >> >> >> currently, but should work for users at the end of the project.
>> Then
>> >> >> think
>> >> >> >> about what needs to change inside SciPy for these code snippets
>> to
>> >> >> work.
>> >> >> >> This can become an iterative process as you realize that the
>> SciPy
>> >> >> changes
>> >> >> >> might be better or easier with changes to the user-facing API,
>> etc.
>> >> >> >>
>> >> >> >> Eric
>> >> >> >>
>> >> >> >>
>> >> >> >> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
>> >> >> >> deathcoderx at gmail.com> wrote:
>> >> >> >>
>> >> >> >>> Hey,
>> >> >> >>> As proposal submission period started I want to discuss a bit
>> anobt
>> >> >> how
>> >> >> >>> can we implement the API.
>> >> >> >>> I would very much appriciate inputs and guidance.
>> >> >> >>>
>> >> >> >>> Cheers.
>> >> >> >>>
>> >> >> >>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <
>> >> larson.eric.d at gmail.com>
>> >> >> >>> wrote:
>> >> >> >>>
>> >> >> >>>> The best way to figure that out is probably to take a look at
>> >> some of
>> >> >> >>>> the existing (minor) SciPy GitHub issues and try to work on
>> one or
>> >> >> two that
>> >> >> >>>> you feel like working on. Actually trying to work out how to
>> >> >> contribute
>> >> >> >>>> code changes (as independently as possible/reasonable based on
>> the
>> >> >> existing
>> >> >> >>>> guides/docs already discoverable online) will quickly highlight
>> >> >> things that
>> >> >> >>>> need to be learned. Some of the general things are the SciPy
>> >> >> contributing
>> >> >> >>>> guidelines, standard GitHub PR workflow, communication with
>> >> >> reviewers, and
>> >> >> >>>> so forth.
>> >> >> >>>>
>> >> >> >>>> For this particular project, it's important to understand the
>> >> various
>> >> >> >>>> flavors and properties of FFT in SciPy (real, complex,
>> >> n-dimensional,
>> >> >> >>>> caching plans, etc.) as well as other projects like NumPy,
>> CuPy,
>> >> and
>> >> >> >>>> pyFFTW. Some of this can be learned and improved upon as part
>> of
>> >> >> GSoC, but
>> >> >> >>>> the more you know and can demonstrate / put into practice
>> >> knowledge
>> >> >> of
>> >> >> >>>> before the applications are reviewed, the better.
>> >> >> >>>>
>> >> >> >>>> Eric
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
>> >> >> >>>> deathcoderx at gmail.com> wrote:
>> >> >> >>>>
>> >> >> >>>>> Thank you for the detailed reply.
>> >> >> >>>>> I will keep these point in mind while preparing my proposal.
>> >> Apart
>> >> >> >>>>> from proposal, what skills shall I improve so that I can
>> >> contribute
>> >> >> more
>> >> >> >>>>> effectively and efficiently.
>> >> >> >>>>>
>> >> >> >>>>> Cheers.
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <
>> >> larson.eric.d at gmail.com>
>> >> >> >>>>> wrote:
>> >> >> >>>>>
>> >> >> >>>>>> There are a number of considerations that would be good to
>> >> address.
>> >> >> >>>>>> I'd start by considering the things that are typically
>> >> considered
>> >> >> >>>>>> when making changes to SciPy
>> >> >> >>>>>> <
>> >> >>
>> >>
>> https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy
>> >> >> >,
>> >> >> >>>>>> but I'd expand it to a longer list since the scope is bigger
>> >> than
>> >> >> a typical
>> >> >> >>>>>> single PR. The list would contain (at least):
>> >> >> >>>>>>
>> >> >> >>>>>> - what will the user-facing API / contract be?
>> >> >> >>>>>> - what in SciPy needs to change to allow it (internals /
>> >> >> >>>>>> implementation outline, perhaps skeleton functions/classes)?
>> >> >> >>>>>> - what examples should we show users (in general this ends up
>> >> being
>> >> >> >>>>>> just simple use cases of the API)?
>> >> >> >>>>>> - how will we test it for correctness?
>> >> >> >>>>>> - how will we benchmark it to prevent performance
>> regressions?
>> >> >> >>>>>> - how can we break up the work for these steps (if possible)
>> >> into
>> >> >> >>>>>> separable, sequential (or -- better but not usually possible
>> --
>> >> >> >>>>>> independent) PRs?
>> >> >> >>>>>>
>> >> >> >>>>>> You might notice that none of these points are actually all
>> that
>> >> >> >>>>>> specific to the FFT project, but can be generally applicable
>> to
>> >> >> GSoC
>> >> >> >>>>>> projects. For the FFT project, I would say "how do we build
>> the
>> >> >> backend" is
>> >> >> >>>>>> indeed implicitly contained / outlined in these bullet
>> points.
>> >> And
>> >> >> as with
>> >> >> >>>>>> most projects, the first two points (and possibly the last)
>> will
>> >> >> probably
>> >> >> >>>>>> be the most challenging to sort out.
>> >> >> >>>>>>
>> >> >> >>>>>> Eric
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
>> >> >> >>>>>> deathcoderx at gmail.com> wrote:
>> >> >> >>>>>>
>> >> >> >>>>>>> Hey Eric,
>> >> >> >>>>>>> So for my proposal, shall I include how can we built a back
>> >> end?
>> >> >> >>>>>>> What all points shall I include to make it effective?
>> >> >> >>>>>>>
>> >> >> >>>>>>> Cheers.
>> >> >> >>>>>>>
>> >> >> >>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <
>> >> larson.eric.d at gmail.com
>> >> >> >
>> >> >> >>>>>>> wrote:
>> >> >> >>>>>>>
>> >> >> >>>>>>>> That would be me -- don't worry, I'm on this list, as are
>> >> >> >>>>>>>> (presumably) other developers interested in the
>> discussion, so
>> >> >> no need to
>> >> >> >>>>>>>> document elsewhere for now from our end. It looks like Greg
>> >> has
>> >> >> summarized
>> >> >> >>>>>>>> the current status and thoughts we've had, so I don't have
>> >> much
>> >> >> to add at
>> >> >> >>>>>>>> this point.
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> Eric
>> >> >> >>>>>>>>
>> >> >> >>>>>>>>
>> >> >> >>>>>>>>
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
>> >> >> >>>>>>>> deathcoderx at gmail.com> wrote:
>> >> >> >>>>>>>>
>> >> >> >>>>>>>>> Hey Greg,
>> >> >> >>>>>>>>> I got the basic idea about what we want to implement this
>> >> year.
>> >> >> >>>>>>>>> Our first priority is to create a backend for 3rd party
>> >> >> fftpacks.
>> >> >> >>>>>>>>> We can create API using Python and Flask or any other
>> >> suitable
>> >> >> framework.
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>> I thought this discussion was going on on SciPy Developer
>> >> List
>> >> >> >>>>>>>>> only. So do I need to document it all and post it
>> somewhere
>> >> so
>> >> >> that other
>> >> >> >>>>>>>>> contributors can see this?
>> >> >> >>>>>>>>> Also, I couldn't find any contact info regarding Eric. It
>> >> would
>> >> >> be
>> >> >> >>>>>>>>> very helpful if we include him in this discussion as this
>> is
>> >> a
>> >> >> roadmap for
>> >> >> >>>>>>>>> GSoC project and I can also get more insight into the
>> project
>> >> >> and expected
>> >> >> >>>>>>>>> outcomes.
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>> Cheers.
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <
>> >> grlee77 at gmail.com>
>> >> >> >>>>>>>>> wrote:
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
>> >> >> >>>>>>>>>> deathcoderx at gmail.com> wrote:
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>>> Hey Gregory,
>> >> >> >>>>>>>>>>> I went through the idea and I am very much interested in
>> >> >> working
>> >> >> >>>>>>>>>>> on it. I had Fourier Transforms as a part of my academic
>> >> >> course, so I am
>> >> >> >>>>>>>>>>> well aware with basic concepts.
>> >> >> >>>>>>>>>>> One thing I want to discuss is, its mentioned that we
>> have
>> >> to
>> >> >> >>>>>>>>>>> create a backend system for 3rd party FFTpacks so my
>> dobuts
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>>> 1. How are we going to create API?
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>> This will needed to be decided on in consensus with the
>> >> SciPy
>> >> >> >>>>>>>>>> developers and user community. I am mentoring for the
>> >> project
>> >> >> as a
>> >> >> >>>>>>>>>> contributor here and a maintainer of the related pyFFTW
>> >> >> package, but I am
>> >> >> >>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core
>> dev
>> >> >> here). I have
>> >> >> >>>>>>>>>> not discussed the API in any detail with the SciPy team
>> at
>> >> >> this stage.
>> >> >> >>>>>>>>>> Working out details of what the API should look like and
>> >> >> working to
>> >> >> >>>>>>>>>> finalize that in collaboration with the community will
>> be a
>> >> >> primary task
>> >> >> >>>>>>>>>> during the early part of the GSOC project.
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>> 2. After the creation of backend will user at the time of
>> >> >> >>>>>>>>>>> installation of SciPy will decide what all 3rd party
>> >> FFTpacks
>> >> >> he needs or
>> >> >> >>>>>>>>>>> we will include some by default?
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> The idea is to allow users to opt-in to a different FFT
>> >> >> backend
>> >> >> >>>>>>>>>> at run time, but these alternative libraries will not be
>> >> >> distributed with
>> >> >> >>>>>>>>>> SciPy itself due to incompatible software licenses
>> (pyFFTW
>> >> and
>> >> >> mkl-fft) or
>> >> >> >>>>>>>>>> a requirement for specific hardware (CuPy requires an
>> NVIDIA
>> >> >> GPU). SciPy
>> >> >> >>>>>>>>>> will continue to offer its own bundled FFT library
>> >> (currently
>> >> >> fftpack, but
>> >> >> >>>>>>>>>> this could be switched to pocketfft as discussed in the
>> >> ideas
>> >> >> page). The
>> >> >> >>>>>>>>>> purpose of the backend interface is to provide a
>> convenient
>> >> >> way for users
>> >> >> >>>>>>>>>> to have third party libraries perform the FFTs instead,
>> but
>> >> >> under the
>> >> >> >>>>>>>>>> existing scipy.fftpack API. This is motivated by a
>> desire by
>> >> >> end users and
>> >> >> >>>>>>>>>> downstream projects to have features such as
>> multi-threading
>> >> >> (pyFFTW and
>> >> >> >>>>>>>>>> mkl-fft) or GPU support (CuPy) that are not implemented
>> in
>> >> >> scipy.fftpack.
>> >> >> >>>>>>>>>> Ultimately it will be up to users that opt-in to using
>> these
>> >> >> other
>> >> >> >>>>>>>>>> libraries to confirm that the license terms and are
>> >> compatible
>> >> >> with their
>> >> >> >>>>>>>>>> use case.
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev
>> mailing
>> >> >> >>>>>>>>>> lists prefers replies **below** the email you are
>> replying
>> >> to
>> >> >> so people can
>> >> >> >>>>>>>>>> more easily follow the thread of discussion. There are
>> some
>> >> >> guidelines at:
>> >> >> >>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>> I will research more about how to implement a backend
>> myself
>> >> >> and
>> >> >> >>>>>>>>>>> will let you know as soon as I come up with something
>> new.
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>> CHeers,
>> >> >> >>>>>>>>>>> Greg
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <
>> >> >> grlee77 at gmail.com>
>> >> >> >>>>>>>>>>> wrote:
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
>> >> >> >>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started fixing
>> >> some
>> >> >> >>>>>>>>>>>>> bugs, also made some pull request. Can anyone suggest
>> me
>> >> >> how should I
>> >> >> >>>>>>>>>>>>> proceed further?
>> >> >> >>>>>>>>>>>>> _______________________________________________
>> >> >> >>>>>>>>>>>>> SciPy-Dev mailing list
>> >> >> >>>>>>>>>>>>> SciPy-Dev at python.org
>> >> >> >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> Hi Gopi,
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> I think you have probably already found it, but the
>> GSOC
>> >> >> >>>>>>>>>>>> project we have already identified mentors for in
>> SciPy is
>> >> >> here:
>> >> >> >>>>>>>>>>>>
>> >> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> If this is a project you are interested in then I would
>> >> start
>> >> >> >>>>>>>>>>>> thinking about what the FFT interface would look like
>> and
>> >> >> reviewing some of
>> >> >> >>>>>>>>>>>> the past/present issues related to fftpack / FFT in
>> SciPy.
>> >> >> Please ask
>> >> >> >>>>>>>>>>>> questions you have related to that project here so that
>> >> you
>> >> >> can clarify
>> >> >> >>>>>>>>>>>> what would be involved in writing a successful
>> >> application.
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> If you have a different idea in mind you can propose it
>> >> here,
>> >> >> >>>>>>>>>>>> but you should do that soon, because it will be
>> necessary
>> >> to
>> >> >> determine if
>> >> >> >>>>>>>>>>>> there is interest from the SciPy team before you spend
>> >> time
>> >> >> coming up with
>> >> >> >>>>>>>>>>>> a detailed proposal. We have to determine if a project
>> >> >> sounds feasible to
>> >> >> >>>>>>>>>>>> complete for GSOC and if appropriate mentors can be
>> >> >> identified.
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> Ultimately, you will need to submit an application to
>> >> SciPy
>> >> >> >>>>>>>>>>>> between March 25th - April 9th.
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> Cheers,
>> >> >> >>>>>>>>>>>> Greg
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> _______________________________________________
>> >> >> >>>>>>>>>>>> SciPy-Dev mailing list
>> >> >> >>>>>>>>>>>> SciPy-Dev at python.org
>> >> >> >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>> _______________________________________________
>> >> >> >>>>>>>>>>> SciPy-Dev mailing list
>> >> >> >>>>>>>>>>> SciPy-Dev at python.org
>> >> >> >>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>> _______________________________________________
>> >> >> >>>>>>>>>> SciPy-Dev mailing list
>> >> >> >>>>>>>>>> SciPy-Dev at python.org
>> >> >> >>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>> _______________________________________________
>> >> >> >>>>>>>>> SciPy-Dev mailing list
>> >> >> >>>>>>>>> SciPy-Dev at python.org
>> >> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>> _______________________________________________
>> >> >> >>>>>>>> SciPy-Dev mailing list
>> >> >> >>>>>>>> SciPy-Dev at python.org
>> >> >> >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >>>>>>>>
>> >> >> >>>>>>> _______________________________________________
>> >> >> >>>>>>> SciPy-Dev mailing list
>> >> >> >>>>>>> SciPy-Dev at python.org
>> >> >> >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >>>>>>>
>> >> >> >>>>>> _______________________________________________
>> >> >> >>>>>> SciPy-Dev mailing list
>> >> >> >>>>>> SciPy-Dev at python.org
>> >> >> >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >>>>>>
>> >> >> >>>>> _______________________________________________
>> >> >> >>>>> SciPy-Dev mailing list
>> >> >> >>>>> SciPy-Dev at python.org
>> >> >> >>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >>>>>
>> >> >> >>>> _______________________________________________
>> >> >> >>>> SciPy-Dev mailing list
>> >> >> >>>> SciPy-Dev at python.org
>> >> >> >>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >>>>
>> >> >> >>> _______________________________________________
>> >> >> >>> SciPy-Dev mailing list
>> >> >> >>> SciPy-Dev at python.org
>> >> >> >>> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >>>
>> >> >> >> _______________________________________________
>> >> >> >> SciPy-Dev mailing list
>> >> >> >> SciPy-Dev at python.org
>> >> >> >> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >>
>> >> >> > _______________________________________________
>> >> >> > SciPy-Dev mailing list
>> >> >> > SciPy-Dev at python.org
>> >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >> >
>> >> >> -------------- next part --------------
>> >> >> An HTML attachment was scrubbed...
>> >> >> URL: <
>> >> >>
>> >>
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/54f38250/attachment.html
>> >> >> >
>> >> >>
>> >> >> ------------------------------
>> >> >>
>> >> >> Subject: Digest Footer
>> >> >>
>> >> >> _______________________________________________
>> >> >> SciPy-Dev mailing list
>> >> >> SciPy-Dev at python.org
>> >> >> https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >>
>> >> >>
>> >> >> ------------------------------
>> >> >>
>> >> >> End of SciPy-Dev Digest, Vol 185, Issue 18
>> >> >> ******************************************
>> >> >>
>> >> > _______________________________________________
>> >> > SciPy-Dev mailing list
>> >> > SciPy-Dev at python.org
>> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >> >
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >> URL: <
>> >>
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190404/1a670020/attachment.html
>> >> >
>> >>
>> >> ------------------------------
>> >>
>> >> Subject: Digest Footer
>> >>
>> >> _______________________________________________
>> >> SciPy-Dev mailing list
>> >> SciPy-Dev at python.org
>> >> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>
>> >>
>> >> ------------------------------
>> >>
>> >> End of SciPy-Dev Digest, Vol 186, Issue 11
>> >> ******************************************
>> >>
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190405/cc4019f5/attachment.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>>
>> ------------------------------
>>
>> End of SciPy-Dev Digest, Vol 186, Issue 15
>> ******************************************
>>
> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190409/0214c149/attachment-0001.html>

From deathcoderx at gmail.com  Tue Apr  9 05:32:41 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Tue, 9 Apr 2019 15:02:41 +0530
Subject: [SciPy-Dev] GSoC 2019: Project Proposal
In-Reply-To: <CABL7CQiTHY8PQTnrTXj9p=yJbpA_FV7X-OT9ExLPfJVu98hsgw@mail.gmail.com>
References: <mailman.2071.1554480810.2938.scipy-dev@python.org>
 <CAG7Qgjhy-X-vDqxS8sS7SZ8Lv-YdySpwTQKb1QUuXRvXmM4y4w@mail.gmail.com>
 <CAJR3sXdxc-3EHBMXHwtT4_5pVM-J2Lb9_FV1y8v1fBs9J3iC3w@mail.gmail.com>
 <CABL7CQiTHY8PQTnrTXj9p=yJbpA_FV7X-OT9ExLPfJVu98hsgw@mail.gmail.com>
Message-ID: <CADYNDziCd6zq2eOpP_E4wuq=PaWbDCVbdA41qNSfSM2sZwWAgw@mail.gmail.com>

I have shared draft proposal on GSoC's website. Can I get some
comments/suggestions?
I know its a bit late but actually my end semester exams will commence in
2 days so I am quite busy with them.

Cheers.

On Tue, Apr 9, 2019 at 10:55 AM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Mon, Apr 8, 2019 at 7:54 AM Gregory Lee <grlee77 at gmail.com> wrote:
>
>>
>>
>> On Sat, Apr 6, 2019 at 5:08 PM Anany Shrey Jain <
>> f20170920 at goa.bits-pilani.ac.in> wrote:
>>
>>>
>>> Hey ,
>>> Thanks Greg for a detailed reply. I will be working on both
>>> https://github.com/pyFFTW/pyFFTW/pull/256 and
>>> https://github.com/cupy/cupy/issues/1936 as a part of this project. I
>>> have constructed my API implementation based on the `set_backend`  function
>>> approach, but in comparatively cleaner way. I have written my proposal for
>>> this project and here is a link to it:
>>> https://docs.google.com/document/d/1TIiH9j3rPAN--53MwjZz7NFO1GGtxmEH3RiGzvqnEBk/edit?usp=sharing.
>>> Please go through my proposal and if possible send some feedback on it.
>>>
>>> -Anany
>>>
>>>
>> Hi Anany,
>>
>> I appreciate that you have narrowed down some of the possibilities. The
>> API will need further refinement to reach consensus, but the general
>> concept as presented seems reasonable and I don't think we have to reach
>> consensus on the finer implementation details for purposes of the proposal.
>> I am not sure it is necessary to have the `set_backend` function return a
>> class that allows setting additional arguments. Ralf's made a comment
>> earlier that was in favor of just supporting the arguments currently
>> present in SciPy's fftpack. I was also thinking something a bit simpler in
>> terms of just reading the name of the backend from a configuration file or
>> environment variable as opposed to running a full configuration script, but
>> others may disagree.
>>
>
> The google doc proposal right now seems to say environment variable. I
> think that's fine, better than a config file/script (which I'd really like
> to avoid). The name should be scipy-specific though, right now it says
> "BACKENDPATH". Perhaps something like "SCIPY_FFT_BACKEND".
>
> As for setting it in code, a context manager would be nice in addition to
> a regular function. API something like:
>
> 1. set_backend(name)
> 2. get_backend()
> 3. with fftpack.backend(name):
>
>
>
>> I will comment mainly on the timeline section of the proposal as we did
>> not discuss that previously:
>>
>> I think the timeline is a bit overly optimistic and dedicates too much
>> time to third party libraries. It is probably not realistically going to be
>> possible to complete changes to SciPy as well as pyFFTW, mkl_fft and CuPy.
>> I would focus the majority of the timeline on SciPy itself. You can leave
>> the text about working on the pyFFTW and CuPy issues as goals for weeks
>> 9-12, but I think all work in the early weeks should be in SciPy itself and
>> not require any changes to the third-party libraries in order for the
>> backend code to function. Each of the third party libraries already has a
>> substantial portion of the SciPy API implemented and can usefully be
>> integrated as backends as-is.
>>
>> I think you can keep the plan to implement an initial interface and
>> pyFFTW support in weeks 1-2, but I think week 3-4 should be primarily along
>> the lines of improving and revising the initial interface based on reviewer
>> feedback from your first PR. Realistically, it will take a substantial
>> amount of time to reach agreement among all parties and code will not be
>> merged right away. I would focus weeks 3-4 on revising based on feedback
>> rather than proposing to "make CuPy compatible". CuPy already has
>> compatible interfaces for many of the functions (
>> https://github.com/cupy/cupy/blob/master/cupyx/scipy/fftpack/fft.py).
>>
>> Week 5 seems to be missing from the timeline?
>>
>> I would remove the item about adding changes to mkl_fft (in week 6). Was
>> there something specific you had in mind for that? There are already
>> existing wrappers (
>> https://github.com/IntelPython/mkl_fft/blob/master/mkl_fft/_scipy_fft.py)
>> and I'm not sure there is much more to do there.  A suitable replacement
>> for the week 5-6 section of the timeline could be working on the SciPy user
>> documentation detailing how to use and configure the backends. It could be
>> considered to potentially make small PRs to third party library
>> documentation as well, mentioning how scipy can be configured to use them
>> as its default backend. For instance, the new backend-based approach will
>> be preferable to the monkey patching currently discussed in the pyFFTW docs.
>>
>> I proposed above to remove mention of CuPy from weeks 3-4 to reduce the
>> overall proportion of time in the proposal that is related to CuPy for a
>> couple of reasons:
>>
>> 1.) There is no existing precedent for interfacing with GPU code from
>> SciPy so that may be a little controversial among the larger group of SciPy
>> developers and have a harder time of getting merged. If we assume NumPy
>> inputs should give NumPy outputs then the required host/device memory
>> transfers will reduce performance, making the GPU-based approach only
>> beneficial for large transforms. We could allow GPU-based input/output, but
>> other functions in SciPy itself do not support GPU-based arrays.
>>
>
> None of the code in SciPy should directly rely on GPUs, however some code
> in SciPy may already work if you pass in a CuPy array (due to
> __array_ufunc__ and __array_function__). When you think about a CuPy
> backend, it should work by passing in CuPy arrays instead of NumPy arrays,
> and having things work transparently via those array protocols. It doesn't
> really make sense to put in code to convert array types imho, that will be
> inefficient and hard to maintain.
>
>
> http://scipy.github.io/devdocs/roadmap.html#support-for-distributed-arrays-and-gpu-arrays is
> the relevant item on our roadmap here.
>
> Cheers,
> Ralf
>
>
>
>>
>> 2.) Using CuPy requires access to a relatively recent (~last five years
>> or so) NVidia GPU that supports CUDA (I think at least CUDA 8.0 is
>> required). Do you have access to an appropriate GPU? There is no
>> requirement for applicants to have access to such hardware, but it will
>> difficult to propose making contributions to CuPy itself without it. We may
>> be able to work out remote access to a machine that has appropriate
>> hardware, but I have not looked into specifics of how we would arrange that
>> yet and cannot guarantee it.
>>
>>
>>
>>
>> Message: 1
>>> Date: Fri, 5 Apr 2019 12:13:15 -0400
>>> From: Gregory Lee <grlee77 at gmail.com>
>>> To: SciPy Developers List <scipy-dev at python.org>
>>> Subject: Re: [SciPy-Dev] GSoC 2019
>>> Message-ID:
>>>         <
>>> CAJR3sXeVPAB+jGB_EdxiDg45jbR4wHzLVjjBk7+RiesT0XMrpw at mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> On Fri, Apr 5, 2019 at 4:25 AM Anany Shrey Jain <
>>> f20170920 at goa.bits-pilani.ac.in> wrote:
>>>
>>> > Hey Greg,
>>> > The project "Revamp FFTPACK" also aims at contributing to third party
>>> > libraries to fill in functionality gaps. For pyFFTW I can see that
>>> work on
>>> > adding Real-to-Real transforms has been going on for a long time. So
>>> do I
>>> > need to continue the work going on in
>>> > https://github.com/pyFFTW/pyFFTW/pull/256 as a part of this project?
>>> >
>>>
>>> It is not a requirement that you work on the pyFFTW wrappers, but that
>>> would be a good complement to this project. Here are some thoughts.
>>>
>>> 1.) I would first have a mechanism to fall back to the existing
>>> scipy.fftpack implementations for any functions not currently supported
>>> by
>>> a given backend. pyFFTW currently already falls back to scipy's own
>>> implementation for DCT and DST transforms (
>>>
>>> https://github.com/pyFFTW/pyFFTW/blob/e9966e5d215a00f89156bd88e1d42b884f85df78/pyfftw/interfaces/scipy_fftpack.py#L81-L82
>>> ).
>>> The PR you referenced would allow it to use FFTW to perform these
>>> transforms instead and there would be no remaining functions that fall
>>> back
>>> to scipy.fftpack.
>>>
>>> 2.) You can work on adding real-to-real support in supporting libraries,
>>> but this is a secondary goal to pursue once the SciPy side of the project
>>> has been completed.
>>>    pyFFTW builds on FFTW which does already have functions providing
>>> real-to-real transforms. So what you see in the PR referenced above is
>>> mainly adding the wrappers for those to pyFFTW.
>>>
>>>
>>>
>>> > What needs to be done for the other two libraries? Do I need to make a
>>> > similar PR to other two libraries as well?
>>> >
>>> >
>>> You could potentially try that, but I think that is more of a stretch
>>> goal.
>>> The approach for CuPy or mkl-fft would have to be different, because for
>>> those two cases the underlying libraries DO NOT have dedicated functions
>>> implementing the real-to-real transforms. Also, the underlying FFT
>>> libraries are proprietary, so we cannot propose to add new transforms on
>>> the C/C++ side. However, it is possible in principle to implement
>>> real-to-real transforms using only the already existing complex-valued
>>> transforms (albeit at some additional computational/memory cost). Some
>>> detailed examples of this are given in the following thread on DSP
>>> StackExchange:
>>>
>>> https://dsp.stackexchange.com/questions/2807/fast-cosine-transform-via-fft
>>>
>>> I think that is probably the only feasible route for real-to-real
>>> transforms using those two backends. I think whether or not this type of
>>> implementation would give a performance benefit over just reusing the
>>> existing scipy.fftpack implementations is unknown.
>>>
>>> One FFT-related issues that could be improved in CuPy in a more
>>> straightforward manner than adding real-to-real support, is improving the
>>> real-to-complex and complex-to-real support.  These transforms are
>>> supported by the underlying CUFFT library, but support for this within
>>> CuPy
>>> is incomplete.  One issue related to this was opened at (
>>> https://github.com/cupy/cupy/issues/1936), but no PR implementing it has
>>> been made.
>>>
>>>
>>> > For all the three libraries there are SciPy-compatable routines already
>>> > defined. After getting required information using the newly created
>>> > interface I need to use them at the backend, right?
>>> >
>>>
>>> Yes, you should rely on the already existing interfaces when implementing
>>> the backends in SciPy. Any additional 3rd party libraries would have to
>>> provide a scipy-like interface in order to be compatible for use as a
>>> backend.
>>>
>>>
>>>
>>> >
>>> > -Anany
>>> >
>>> >> ----------------------------------------------------------------------
>>> >>
>>> >> Message: 1
>>> >> Date: Thu, 4 Apr 2019 10:58:27 -0400
>>> >> From: Gregory Lee <grlee77 at gmail.com>
>>> >> To: SciPy Developers List <scipy-dev at python.org>
>>> >> Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 185, Issue 18
>>> >> Message-ID:
>>> >>         <
>>> >> CAJR3sXcJuqQJrDboN5zH-pd7NG-wD8EWCdTCAtQ+vJpnZjKsRw at mail.gmail.com>
>>> >> Content-Type: text/plain; charset="utf-8"
>>> >>
>>> >> Hi Anany,
>>> >>
>>> >> It is nice to see that you have updated with multiple potential APIs.
>>> Can
>>> >> some other core SciPy devs also help give feedback on what SciPy would
>>> >> find
>>> >> preferable? Out of the four you proposed, I think something along the
>>> >> lines
>>> >> of the second method is cleanest in terms of setting the backend at
>>> >> runtime. I think having some aspect from your 4th variant where the
>>> >> default
>>> >> backend can be read from a configuration file and/or environment
>>> variable
>>> >> is also desirable so that the user's desired default can always be
>>> >> automatically set at import time.
>>> >>
>>> >> I disagree with the following specific statement, though:
>>> >> "It is better to use all the above mentioned ideas because every idea
>>> has
>>> >> its own benefits besides it gives user the luxury to choose the method
>>> >> implementation of backend."
>>> >>
>>> >> I do not think we want to provide multiple ways to do the same thing.
>>> It
>>> >> can be confusing to users and more work for devs to maintain. I think
>>> >> there
>>> >> should be one method of setting the backend that the user can either
>>> call
>>> >> at run time or have it be automatically called based on some sort of
>>> >> configuration file and/or environment variable(s) at import time.
>>> >>
>>> >> - Greg
>>> >>
>>> >>
>>> >> On Tue, Apr 2, 2019 at 2:19 PM Anany Shrey Jain <
>>> >> f20170920 at goa.bits-pilani.ac.in> wrote:
>>> >>
>>> >> > Hey,
>>> >> > I have already sent the link to the page containing the list of
>>> ideas
>>> >> for
>>> >> > implementation of new API that I propose for this project. Would you
>>> >> like
>>> >> > to add something to it or give some comments on it? The Gsoc
>>> proposal
>>> >> > deadline is 9th of April and I am planning to put all of this in my
>>> >> > proposal to make it effective . So any more ideas or comments will
>>> be
>>> >> > really helpful for me . Here is the link to the page:
>>> >> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
>>> .
>>> >> >
>>> >> > On Sun, Mar 31, 2019 at 5:23 AM <scipy-dev-request at python.org>
>>> wrote:
>>> >> >
>>> >> >>
>>> >> >> Message: 1
>>> >> >> Date: Sat, 30 Mar 2019 13:31:51 -0400
>>> >> >> From: Eric Larson <larson.eric.d at gmail.com>
>>> >> >> To: SciPy Developers List <scipy-dev at python.org>
>>> >> >> Subject: Re: [SciPy-Dev] GSoC 2019
>>> >> >> Message-ID:
>>> >> >>         <
>>> >> >> CAGu2niVWsKrMukfWcAWAtj-1NBm2utCeh3BOnNku7jNoAcx-kw at mail.gmail.com
>>> >
>>> >> >> Content-Type: text/plain; charset="utf-8"
>>> >> >>
>>> >> >> It looks like the main ideas are in these bits of code, but not
>>> >> explicitly
>>> >> >> stated. In brief it looks like the proposed API is to add a
>>> >> `fft_object`
>>> >> >> kwarg to every function in `scipy.fftpack`. It would be good to
>>> discuss
>>> >> >> this choice explicitly -- what advantages and disadvantages it has
>>> >> >> relative
>>> >> >> to other approaches (e.g., creating new namespaces, or having a
>>> >> >> `set_backend` function (and/or context manager) that would change
>>> >> things
>>> >> >> under the hood).
>>> >> >>
>>> >> >> If you make changes and need more feedback, let us know. The more
>>> >> specific
>>> >> >> you can be about what you need feedback on (high level ideas, low
>>> level
>>> >> >> implementation, etc.), the better.
>>> >> >>
>>> >> >> Eric
>>> >> >>
>>> >> >>
>>> >> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
>>> >> >> f20170920 at goa.bits-pilani.ac.in> wrote:
>>> >> >>
>>> >> >> > Hey,
>>> >> >> > I went through the idea list of Scipy for this years's GSoC and I
>>> >> intend
>>> >> >> > to work towards the idea of revamping the Scipy's fftpack. I have
>>> >> >> already
>>> >> >> > been contributing to Scipy since the end of last year and I have
>>> some
>>> >> >> > knowledge about Fourier transforms as it was the part of my
>>> >> discipline.
>>> >> >> I
>>> >> >> > could not take part in this discussion earlier because my mid
>>> >> semester
>>> >> >> > exams were going on, but since they are now over so I can devote
>>> as
>>> >> much
>>> >> >> > time as required on this project. I have already created a github
>>> >> page
>>> >> >> with
>>> >> >> > some code snippets and functionalities that we can implement,
>>> here is
>>> >> >> the
>>> >> >> > link to it:
>>> >> >> >
>>> https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
>>> >> .
>>> >> >> >
>>> >> >> > Cheers,
>>> >> >> > Anany Jain
>>> >> >> >
>>> >> >> > _______________________________________________
>>> >> >> > SciPy-Dev mailing list
>>> >> >> > SciPy-Dev at python.org
>>> >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >
>>> >> >> -------------- next part --------------
>>> >> >> An HTML attachment was scrubbed...
>>> >> >> URL: <
>>> >> >>
>>> >>
>>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/f1755dfb/attachment-0001.html
>>> >> >> >
>>> >> >>
>>> >> >> ------------------------------
>>> >> >>
>>> >> >> Message: 2
>>> >> >> Date: Sat, 30 Mar 2019 19:38:41 -0400
>>> >> >> From: Gregory Lee <grlee77 at gmail.com>
>>> >> >> To: SciPy Developers List <scipy-dev at python.org>
>>> >> >> Subject: Re: [SciPy-Dev] GSoC 2019
>>> >> >> Message-ID:
>>> >> >>         <CAJR3sXfnnr-0JO87gLbhh-7b-w=KjaNpac+F+FHTeFt2K=_
>>> >> >> QMw at mail.gmail.com>
>>> >> >> Content-Type: text/plain; charset="utf-8"
>>> >> >>
>>> >> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
>>> >> >> f20170920 at goa.bits-pilani.ac.in> wrote:
>>> >> >>
>>> >> >> > Hey,
>>> >> >> > I went through the idea list of Scipy for this years's GSoC and I
>>> >> intend
>>> >> >> > to work towards the idea of revamping the Scipy's fftpack. I have
>>> >> >> already
>>> >> >> > been contributing to Scipy since the end of last year and I have
>>> some
>>> >> >> > knowledge about Fourier transforms as it was the part of my
>>> >> discipline.
>>> >> >> I
>>> >> >> > could not take part in this discussion earlier because my mid
>>> >> semester
>>> >> >> > exams were going on, but since they are now over so I can devote
>>> as
>>> >> much
>>> >> >> > time as required on this project. I have already created a github
>>> >> page
>>> >> >> with
>>> >> >> > some code snippets and functionalities that we can implement,
>>> here is
>>> >> >> the
>>> >> >> > link to it:
>>> >> >> >
>>> https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
>>> >> .
>>> >> >> >
>>> >> >> > Cheers,
>>> >> >> > Anany Jain
>>> >> >> >
>>> >> >> > _______________________________________________
>>> >> >> > SciPy-Dev mailing list
>>> >> >> > SciPy-Dev at python.org
>>> >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >>
>>> >> >>
>>> >> >> Hi Anany,
>>> >> >>
>>> >> >> Thank you for your interest in GSOC with SciPy!  It's great to see
>>> that
>>> >> >> you
>>> >> >> are already thinking about a potential API and learning about the
>>> 3rd
>>> >> >> party
>>> >> >> FFT libraries. Along the lines of Eric's comment, think about what
>>> this
>>> >> >> API
>>> >> >> choice implies for users of libraries built upon SciPy. Would
>>> users of
>>> >> 3rd
>>> >> >> party libraries that rely on SciPy's FFTs be immediately able to
>>> take
>>> >> >> advantage of a differentf FFT backend in this scenario? (in other
>>> >> words,
>>> >> >> the case where the user is not calling scipy.fftpack.fft directly
>>> but
>>> >> is
>>> >> >> using it only indirectly via a function in a downstream library).
>>> >> >>
>>> >> >> Matplotlib is an example of an existing Python library supporting
>>> >> multiple
>>> >> >> backends that can be considered for comparison (see:
>>> >> >> https://matplotlib.org/faq/usage_faq.html#what-is-a-backend).
>>> Think
>>> >> about
>>> >> >> the relative benefits/drawbacks of some of the methods they use for
>>> >> >> setting
>>> >> >> a backend there as compared to the approach proposed for FFTs here.
>>> >> >>
>>> >> >> Another thing that should be considered: pyFFTW, MKL and CuPy
>>> already
>>> >> have
>>> >> >> some functions that match the existing scipy.fftpack API, but they
>>> may
>>> >> >> have
>>> >> >> one or more additional arguments particular to features of that
>>> >> library.
>>> >> >> How would you propose to deal with supporting additional optional
>>> >> >> arguments
>>> >> >> on the SciPy end?
>>> >> >>
>>> >> >> One other minor comment: I know that the blog post you made may be
>>> >> serving
>>> >> >> partly as personal notes, but please do not directly copy sections
>>> of
>>> >> text
>>> >> >> (e.g. the description of BLAS/LAPACK libraries) from elsewhere
>>> without
>>> >> >> attribution when writing a final proposal. (Also, the FFT
>>> functions are
>>> >> >> separate from the BLAS/LAPACK functions in MKL, so you will not
>>> need to
>>> >> >> discuss BLAS or LAPACK specifically in your proposal)
>>> >> >>
>>> >> >> - Greg
>>> >> >> -------------- next part --------------
>>> >> >> An HTML attachment was scrubbed...
>>> >> >> URL: <
>>> >> >>
>>> >>
>>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/c1351e7e/attachment-0001.html
>>> >> >> >
>>> >> >>
>>> >> >> ------------------------------
>>> >> >>
>>> >> >> Message: 3
>>> >> >> Date: Sat, 30 Mar 2019 19:53:02 -0400
>>> >> >> From: Gregory Lee <grlee77 at gmail.com>
>>> >> >> To: SciPy Developers List <scipy-dev at python.org>
>>> >> >> Subject: Re: [SciPy-Dev] GSoC 2019
>>> >> >> Message-ID:
>>> >> >>         <CAJR3sXdcPMAn_DETF8W-=
>>> >> >> MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw at mail.gmail.com>
>>> >> >> Content-Type: text/plain; charset="utf-8"
>>> >> >>
>>> >> >> Hi Gopi,
>>> >> >>
>>> >> >> I am not sure I follow exactly what you are suggesting here. Are
>>> you
>>> >> >> proposing that the `fftpackN` variable in your example would be a
>>> >> Python
>>> >> >> module corresponding to a given backend? If so, why is an array of
>>> >> data,
>>> >> >> z,
>>> >> >> being passed into the newAPI function here? I don't see why a data
>>> >> array
>>> >> >> should be needed at all to choose a backend.
>>> >> >>
>>> >> >> Please also see my response to Anany's recent post on this list
>>> for a
>>> >> >> couple of other suggestions of things to consider in terms of the
>>> API.
>>> >> >>
>>> >> >> - Greg
>>> >> >>
>>> >> >>
>>> >> >> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
>>> >> >> deathcoderx at gmail.com>
>>> >> >> wrote:
>>> >> >>
>>> >> >> > Hey,
>>> >> >> > I went through the code and got some ideas.
>>> >> >> > So what will happen is:
>>> >> >> > First, we will declare FFTW as we use them normally.
>>> >> >> >
>>> >> >> > z = np.random.rand(2, 128, 64)
>>> >> >> > pyfftw.FFTW(z, axes=(-1, ))
>>> >> >> > ..
>>> >> >> > ..
>>> >> >> > Now after declaring our basic work to shift to another FFTpack,
>>> what
>>> >> we
>>> >> >> > can do is:
>>> >> >> > fftPackN= newAPI(z, pack = 'PYFFTW');
>>> >> >> >
>>> >> >> > Pack will take the name of the 3rd party FFT pack which we want
>>> to
>>> >> use.
>>> >> >> > Suggestions needed.
>>> >> >> >
>>> >> >> > Cheers.
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >> >
>>> >> >> > On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <
>>> larson.eric.d at gmail.com
>>> >> >
>>> >> >> > wrote:
>>> >> >> >
>>> >> >> >> After reading the related issues and thinking about the problem,
>>> >> >> perhaps
>>> >> >> >> the best first step is you come up with some initial API
>>> proposal.
>>> >> >> >>
>>> >> >> >> One way to work through the process is to think about the use
>>> cases
>>> >> >> that
>>> >> >> >> we want to support. How should users actually write code to use
>>> the
>>> >> new
>>> >> >> >> functionality? You can start with short code snippets that do
>>> not
>>> >> work
>>> >> >> >> currently, but should work for users at the end of the project.
>>> Then
>>> >> >> think
>>> >> >> >> about what needs to change inside SciPy for these code snippets
>>> to
>>> >> >> work.
>>> >> >> >> This can become an iterative process as you realize that the
>>> SciPy
>>> >> >> changes
>>> >> >> >> might be better or easier with changes to the user-facing API,
>>> etc.
>>> >> >> >>
>>> >> >> >> Eric
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
>>> >> >> >> deathcoderx at gmail.com> wrote:
>>> >> >> >>
>>> >> >> >>> Hey,
>>> >> >> >>> As proposal submission period started I want to discuss a bit
>>> anobt
>>> >> >> how
>>> >> >> >>> can we implement the API.
>>> >> >> >>> I would very much appriciate inputs and guidance.
>>> >> >> >>>
>>> >> >> >>> Cheers.
>>> >> >> >>>
>>> >> >> >>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <
>>> >> larson.eric.d at gmail.com>
>>> >> >> >>> wrote:
>>> >> >> >>>
>>> >> >> >>>> The best way to figure that out is probably to take a look at
>>> >> some of
>>> >> >> >>>> the existing (minor) SciPy GitHub issues and try to work on
>>> one or
>>> >> >> two that
>>> >> >> >>>> you feel like working on. Actually trying to work out how to
>>> >> >> contribute
>>> >> >> >>>> code changes (as independently as possible/reasonable based
>>> on the
>>> >> >> existing
>>> >> >> >>>> guides/docs already discoverable online) will quickly
>>> highlight
>>> >> >> things that
>>> >> >> >>>> need to be learned. Some of the general things are the SciPy
>>> >> >> contributing
>>> >> >> >>>> guidelines, standard GitHub PR workflow, communication with
>>> >> >> reviewers, and
>>> >> >> >>>> so forth.
>>> >> >> >>>>
>>> >> >> >>>> For this particular project, it's important to understand the
>>> >> various
>>> >> >> >>>> flavors and properties of FFT in SciPy (real, complex,
>>> >> n-dimensional,
>>> >> >> >>>> caching plans, etc.) as well as other projects like NumPy,
>>> CuPy,
>>> >> and
>>> >> >> >>>> pyFFTW. Some of this can be learned and improved upon as part
>>> of
>>> >> >> GSoC, but
>>> >> >> >>>> the more you know and can demonstrate / put into practice
>>> >> knowledge
>>> >> >> of
>>> >> >> >>>> before the applications are reviewed, the better.
>>> >> >> >>>>
>>> >> >> >>>> Eric
>>> >> >> >>>>
>>> >> >> >>>>
>>> >> >> >>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
>>> >> >> >>>> deathcoderx at gmail.com> wrote:
>>> >> >> >>>>
>>> >> >> >>>>> Thank you for the detailed reply.
>>> >> >> >>>>> I will keep these point in mind while preparing my proposal.
>>> >> Apart
>>> >> >> >>>>> from proposal, what skills shall I improve so that I can
>>> >> contribute
>>> >> >> more
>>> >> >> >>>>> effectively and efficiently.
>>> >> >> >>>>>
>>> >> >> >>>>> Cheers.
>>> >> >> >>>>>
>>> >> >> >>>>>
>>> >> >> >>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <
>>> >> larson.eric.d at gmail.com>
>>> >> >> >>>>> wrote:
>>> >> >> >>>>>
>>> >> >> >>>>>> There are a number of considerations that would be good to
>>> >> address.
>>> >> >> >>>>>> I'd start by considering the things that are typically
>>> >> considered
>>> >> >> >>>>>> when making changes to SciPy
>>> >> >> >>>>>> <
>>> >> >>
>>> >>
>>> https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy
>>> >> >> >,
>>> >> >> >>>>>> but I'd expand it to a longer list since the scope is bigger
>>> >> than
>>> >> >> a typical
>>> >> >> >>>>>> single PR. The list would contain (at least):
>>> >> >> >>>>>>
>>> >> >> >>>>>> - what will the user-facing API / contract be?
>>> >> >> >>>>>> - what in SciPy needs to change to allow it (internals /
>>> >> >> >>>>>> implementation outline, perhaps skeleton functions/classes)?
>>> >> >> >>>>>> - what examples should we show users (in general this ends
>>> up
>>> >> being
>>> >> >> >>>>>> just simple use cases of the API)?
>>> >> >> >>>>>> - how will we test it for correctness?
>>> >> >> >>>>>> - how will we benchmark it to prevent performance
>>> regressions?
>>> >> >> >>>>>> - how can we break up the work for these steps (if possible)
>>> >> into
>>> >> >> >>>>>> separable, sequential (or -- better but not usually
>>> possible --
>>> >> >> >>>>>> independent) PRs?
>>> >> >> >>>>>>
>>> >> >> >>>>>> You might notice that none of these points are actually all
>>> that
>>> >> >> >>>>>> specific to the FFT project, but can be generally
>>> applicable to
>>> >> >> GSoC
>>> >> >> >>>>>> projects. For the FFT project, I would say "how do we build
>>> the
>>> >> >> backend" is
>>> >> >> >>>>>> indeed implicitly contained / outlined in these bullet
>>> points.
>>> >> And
>>> >> >> as with
>>> >> >> >>>>>> most projects, the first two points (and possibly the last)
>>> will
>>> >> >> probably
>>> >> >> >>>>>> be the most challenging to sort out.
>>> >> >> >>>>>>
>>> >> >> >>>>>> Eric
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
>>> >> >> >>>>>> deathcoderx at gmail.com> wrote:
>>> >> >> >>>>>>
>>> >> >> >>>>>>> Hey Eric,
>>> >> >> >>>>>>> So for my proposal, shall I include how can we built a back
>>> >> end?
>>> >> >> >>>>>>> What all points shall I include to make it effective?
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> Cheers.
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <
>>> >> larson.eric.d at gmail.com
>>> >> >> >
>>> >> >> >>>>>>> wrote:
>>> >> >> >>>>>>>
>>> >> >> >>>>>>>> That would be me -- don't worry, I'm on this list, as are
>>> >> >> >>>>>>>> (presumably) other developers interested in the
>>> discussion, so
>>> >> >> no need to
>>> >> >> >>>>>>>> document elsewhere for now from our end. It looks like
>>> Greg
>>> >> has
>>> >> >> summarized
>>> >> >> >>>>>>>> the current status and thoughts we've had, so I don't have
>>> >> much
>>> >> >> to add at
>>> >> >> >>>>>>>> this point.
>>> >> >> >>>>>>>>
>>> >> >> >>>>>>>> Eric
>>> >> >> >>>>>>>>
>>> >> >> >>>>>>>>
>>> >> >> >>>>>>>>
>>> >> >> >>>>>>>>
>>> >> >> >>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
>>> >> >> >>>>>>>> deathcoderx at gmail.com> wrote:
>>> >> >> >>>>>>>>
>>> >> >> >>>>>>>>> Hey Greg,
>>> >> >> >>>>>>>>> I got the basic idea about what we want to implement this
>>> >> year.
>>> >> >> >>>>>>>>> Our first priority is to create a backend for 3rd party
>>> >> >> fftpacks.
>>> >> >> >>>>>>>>> We can create API using Python and Flask or any other
>>> >> suitable
>>> >> >> framework.
>>> >> >> >>>>>>>>>
>>> >> >> >>>>>>>>> I thought this discussion was going on on SciPy Developer
>>> >> List
>>> >> >> >>>>>>>>> only. So do I need to document it all and post it
>>> somewhere
>>> >> so
>>> >> >> that other
>>> >> >> >>>>>>>>> contributors can see this?
>>> >> >> >>>>>>>>> Also, I couldn't find any contact info regarding Eric. It
>>> >> would
>>> >> >> be
>>> >> >> >>>>>>>>> very helpful if we include him in this discussion as
>>> this is
>>> >> a
>>> >> >> roadmap for
>>> >> >> >>>>>>>>> GSoC project and I can also get more insight into the
>>> project
>>> >> >> and expected
>>> >> >> >>>>>>>>> outcomes.
>>> >> >> >>>>>>>>>
>>> >> >> >>>>>>>>> Cheers.
>>> >> >> >>>>>>>>>
>>> >> >> >>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <
>>> >> grlee77 at gmail.com>
>>> >> >> >>>>>>>>> wrote:
>>> >> >> >>>>>>>>>
>>> >> >> >>>>>>>>>>
>>> >> >> >>>>>>>>>>
>>> >> >> >>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
>>> >> >> >>>>>>>>>> deathcoderx at gmail.com> wrote:
>>> >> >> >>>>>>>>>>
>>> >> >> >>>>>>>>>>> Hey Gregory,
>>> >> >> >>>>>>>>>>> I went through the idea and I am very much interested
>>> in
>>> >> >> working
>>> >> >> >>>>>>>>>>> on it. I had Fourier Transforms as a part of my
>>> academic
>>> >> >> course, so I am
>>> >> >> >>>>>>>>>>> well aware with basic concepts.
>>> >> >> >>>>>>>>>>> One thing I want to discuss is, its mentioned that we
>>> have
>>> >> to
>>> >> >> >>>>>>>>>>> create a backend system for 3rd party FFTpacks so my
>>> dobuts
>>> >> >> >>>>>>>>>>>
>>> >> >> >>>>>>>>>>
>>> >> >> >>>>>>>>>>
>>> >> >> >>>>>>>>>>> 1. How are we going to create API?
>>> >> >> >>>>>>>>>>>
>>> >> >> >>>>>>>>>>
>>> >> >> >>>>>>>>>> This will needed to be decided on in consensus with the
>>> >> SciPy
>>> >> >> >>>>>>>>>> developers and user community. I am mentoring for the
>>> >> project
>>> >> >> as a
>>> >> >> >>>>>>>>>> contributor here and a maintainer of the related pyFFTW
>>> >> >> package, but I am
>>> >> >> >>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core
>>> dev
>>> >> >> here). I have
>>> >> >> >>>>>>>>>> not discussed the API in any detail with the SciPy team
>>> at
>>> >> >> this stage.
>>> >> >> >>>>>>>>>> Working out details of what the API should look like and
>>> >> >> working to
>>> >> >> >>>>>>>>>> finalize that in collaboration with the community will
>>> be a
>>> >> >> primary task
>>> >> >> >>>>>>>>>> during the early part of the GSOC project.
>>> >> >> >>>>>>>>>>
>>> >> >> >>>>>>>>>> 2. After the creation of backend will user at the time
>>> of
>>> >> >> >>>>>>>>>>> installation of SciPy will decide what all 3rd party
>>> >> FFTpacks
>>> >> >> he needs or
>>> >> >> >>>>>>>>>>> we will include some by default?
>>> >> >> >>>>>>>>>>>
>>> >> >> >>>>>>>>>>> The idea is to allow users to opt-in to a different FFT
>>> >> >> backend
>>> >> >> >>>>>>>>>> at run time, but these alternative libraries will not be
>>> >> >> distributed with
>>> >> >> >>>>>>>>>> SciPy itself due to incompatible software licenses
>>> (pyFFTW
>>> >> and
>>> >> >> mkl-fft) or
>>> >> >> >>>>>>>>>> a requirement for specific hardware (CuPy requires an
>>> NVIDIA
>>> >> >> GPU). SciPy
>>> >> >> >>>>>>>>>> will continue to offer its own bundled FFT library
>>> >> (currently
>>> >> >> fftpack, but
>>> >> >> >>>>>>>>>> this could be switched to pocketfft as discussed in the
>>> >> ideas
>>> >> >> page). The
>>> >> >> >>>>>>>>>> purpose of the backend interface is to provide a
>>> convenient
>>> >> >> way for users
>>> >> >> >>>>>>>>>> to have third party libraries perform the FFTs instead,
>>> but
>>> >> >> under the
>>> >> >> >>>>>>>>>> existing scipy.fftpack API. This is motivated by a
>>> desire by
>>> >> >> end users and
>>> >> >> >>>>>>>>>> downstream projects to have features such as
>>> multi-threading
>>> >> >> (pyFFTW and
>>> >> >> >>>>>>>>>> mkl-fft) or GPU support (CuPy) that are not implemented
>>> in
>>> >> >> scipy.fftpack.
>>> >> >> >>>>>>>>>> Ultimately it will be up to users that opt-in to using
>>> these
>>> >> >> other
>>> >> >> >>>>>>>>>> libraries to confirm that the license terms and are
>>> >> compatible
>>> >> >> with their
>>> >> >> >>>>>>>>>> use case.
>>> >> >> >>>>>>>>>>
>>> >> >> >>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev
>>> mailing
>>> >> >> >>>>>>>>>> lists prefers replies **below** the email you are
>>> replying
>>> >> to
>>> >> >> so people can
>>> >> >> >>>>>>>>>> more easily follow the thread of discussion. There are
>>> some
>>> >> >> guidelines at:
>>> >> >> >>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
>>> >> >> >>>>>>>>>>
>>> >> >> >>>>>>>>>>
>>> >> >> >>>>>>>>>>
>>> >> >> >>>>>>>>>> I will research more about how to implement a backend
>>> myself
>>> >> >> and
>>> >> >> >>>>>>>>>>> will let you know as soon as I come up with something
>>> new.
>>> >> >> >>>>>>>>>>>
>>> >> >> >>>>>>>>>>>
>>> >> >> >>>>>>>>>> CHeers,
>>> >> >> >>>>>>>>>>> Greg
>>> >> >> >>>>>>>>>>>
>>> >> >> >>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <
>>> >> >> grlee77 at gmail.com>
>>> >> >> >>>>>>>>>>> wrote:
>>> >> >> >>>>>>>>>>>
>>> >> >> >>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju <
>>> >> >> >>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>>> >> >> >>>>>>>>>>>>
>>> >> >> >>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started
>>> fixing
>>> >> some
>>> >> >> >>>>>>>>>>>>> bugs, also made some pull request. Can anyone
>>> suggest me
>>> >> >> how should I
>>> >> >> >>>>>>>>>>>>> proceed further?
>>> >> >> >>>>>>>>>>>>> _______________________________________________
>>> >> >> >>>>>>>>>>>>> SciPy-Dev mailing list
>>> >> >> >>>>>>>>>>>>> SciPy-Dev at python.org
>>> >> >> >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >>>>>>>>>>>>
>>> >> >> >>>>>>>>>>>>
>>> >> >> >>>>>>>>>>>> Hi Gopi,
>>> >> >> >>>>>>>>>>>>
>>> >> >> >>>>>>>>>>>> I think you have probably already found it, but the
>>> GSOC
>>> >> >> >>>>>>>>>>>> project we have already identified mentors for in
>>> SciPy is
>>> >> >> here:
>>> >> >> >>>>>>>>>>>>
>>> >> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
>>> >> >> >>>>>>>>>>>>
>>> >> >> >>>>>>>>>>>> If this is a project you are interested in then I
>>> would
>>> >> start
>>> >> >> >>>>>>>>>>>> thinking about what the FFT interface would look like
>>> and
>>> >> >> reviewing some of
>>> >> >> >>>>>>>>>>>> the past/present issues related to fftpack / FFT in
>>> SciPy.
>>> >> >> Please ask
>>> >> >> >>>>>>>>>>>> questions you have related to that project here so
>>> that
>>> >> you
>>> >> >> can clarify
>>> >> >> >>>>>>>>>>>> what would be involved in writing a successful
>>> >> application.
>>> >> >> >>>>>>>>>>>>
>>> >> >> >>>>>>>>>>>> If you have a different idea in mind you can propose
>>> it
>>> >> here,
>>> >> >> >>>>>>>>>>>> but you should do that soon, because it will be
>>> necessary
>>> >> to
>>> >> >> determine if
>>> >> >> >>>>>>>>>>>> there is interest from the SciPy team before you spend
>>> >> time
>>> >> >> coming up with
>>> >> >> >>>>>>>>>>>> a detailed proposal. We have to determine if a project
>>> >> >> sounds feasible to
>>> >> >> >>>>>>>>>>>> complete for GSOC and if appropriate mentors can be
>>> >> >> identified.
>>> >> >> >>>>>>>>>>>>
>>> >> >> >>>>>>>>>>>> Ultimately, you will need to submit an application to
>>> >> SciPy
>>> >> >> >>>>>>>>>>>> between March 25th - April 9th.
>>> >> >> >>>>>>>>>>>>
>>> >> >> >>>>>>>>>>>> Cheers,
>>> >> >> >>>>>>>>>>>> Greg
>>> >> >> >>>>>>>>>>>>
>>> >> >> >>>>>>>>>>>>
>>> >> >> >>>>>>>>>>>> _______________________________________________
>>> >> >> >>>>>>>>>>>> SciPy-Dev mailing list
>>> >> >> >>>>>>>>>>>> SciPy-Dev at python.org
>>> >> >> >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >>>>>>>>>>>>
>>> >> >> >>>>>>>>>>> _______________________________________________
>>> >> >> >>>>>>>>>>> SciPy-Dev mailing list
>>> >> >> >>>>>>>>>>> SciPy-Dev at python.org
>>> >> >> >>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >>>>>>>>>>>
>>> >> >> >>>>>>>>>> _______________________________________________
>>> >> >> >>>>>>>>>> SciPy-Dev mailing list
>>> >> >> >>>>>>>>>> SciPy-Dev at python.org
>>> >> >> >>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >>>>>>>>>>
>>> >> >> >>>>>>>>> _______________________________________________
>>> >> >> >>>>>>>>> SciPy-Dev mailing list
>>> >> >> >>>>>>>>> SciPy-Dev at python.org
>>> >> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >>>>>>>>>
>>> >> >> >>>>>>>> _______________________________________________
>>> >> >> >>>>>>>> SciPy-Dev mailing list
>>> >> >> >>>>>>>> SciPy-Dev at python.org
>>> >> >> >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >>>>>>>>
>>> >> >> >>>>>>> _______________________________________________
>>> >> >> >>>>>>> SciPy-Dev mailing list
>>> >> >> >>>>>>> SciPy-Dev at python.org
>>> >> >> >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >>>>>>>
>>> >> >> >>>>>> _______________________________________________
>>> >> >> >>>>>> SciPy-Dev mailing list
>>> >> >> >>>>>> SciPy-Dev at python.org
>>> >> >> >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >>>>>>
>>> >> >> >>>>> _______________________________________________
>>> >> >> >>>>> SciPy-Dev mailing list
>>> >> >> >>>>> SciPy-Dev at python.org
>>> >> >> >>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >>>>>
>>> >> >> >>>> _______________________________________________
>>> >> >> >>>> SciPy-Dev mailing list
>>> >> >> >>>> SciPy-Dev at python.org
>>> >> >> >>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >>>>
>>> >> >> >>> _______________________________________________
>>> >> >> >>> SciPy-Dev mailing list
>>> >> >> >>> SciPy-Dev at python.org
>>> >> >> >>> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >>>
>>> >> >> >> _______________________________________________
>>> >> >> >> SciPy-Dev mailing list
>>> >> >> >> SciPy-Dev at python.org
>>> >> >> >> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >>
>>> >> >> > _______________________________________________
>>> >> >> > SciPy-Dev mailing list
>>> >> >> > SciPy-Dev at python.org
>>> >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >> >
>>> >> >> -------------- next part --------------
>>> >> >> An HTML attachment was scrubbed...
>>> >> >> URL: <
>>> >> >>
>>> >>
>>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/54f38250/attachment.html
>>> >> >> >
>>> >> >>
>>> >> >> ------------------------------
>>> >> >>
>>> >> >> Subject: Digest Footer
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> SciPy-Dev mailing list
>>> >> >> SciPy-Dev at python.org
>>> >> >> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >>
>>> >> >>
>>> >> >> ------------------------------
>>> >> >>
>>> >> >> End of SciPy-Dev Digest, Vol 185, Issue 18
>>> >> >> ******************************************
>>> >> >>
>>> >> > _______________________________________________
>>> >> > SciPy-Dev mailing list
>>> >> > SciPy-Dev at python.org
>>> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>>> >> >
>>> >> -------------- next part --------------
>>> >> An HTML attachment was scrubbed...
>>> >> URL: <
>>> >>
>>> http://mail.python.org/pipermail/scipy-dev/attachments/20190404/1a670020/attachment.html
>>> >> >
>>> >>
>>> >> ------------------------------
>>> >>
>>> >> Subject: Digest Footer
>>> >>
>>> >> _______________________________________________
>>> >> SciPy-Dev mailing list
>>> >> SciPy-Dev at python.org
>>> >> https://mail.python.org/mailman/listinfo/scipy-dev
>>> >>
>>> >>
>>> >> ------------------------------
>>> >>
>>> >> End of SciPy-Dev Digest, Vol 186, Issue 11
>>> >> ******************************************
>>> >>
>>> > _______________________________________________
>>> > SciPy-Dev mailing list
>>> > SciPy-Dev at python.org
>>> > https://mail.python.org/mailman/listinfo/scipy-dev
>>> >
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: <
>>> http://mail.python.org/pipermail/scipy-dev/attachments/20190405/cc4019f5/attachment.html
>>> >
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>>>
>>> ------------------------------
>>>
>>> End of SciPy-Dev Digest, Vol 186, Issue 15
>>> ******************************************
>>>
>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190409/efa68352/attachment-0001.html>

From ralf.gommers at gmail.com  Tue Apr  9 14:02:44 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 9 Apr 2019 20:02:44 +0200
Subject: [SciPy-Dev] plan for SciPy 1.3.0 release
Message-ID: <CABL7CQgtG01tHJwLuQCafDAQAixYoNQQ5DhUHkG2yz-Su1x3mA@mail.gmail.com>

Hi all,

It's about time to start thinking about the next release. We should
probably be aiming for around mid May. Is anyone interested to be the
release manager for this release?

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190409/e0ef276f/attachment.html>

From tyler.je.reddy at gmail.com  Tue Apr  9 14:04:23 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Tue, 9 Apr 2019 11:04:23 -0700
Subject: [SciPy-Dev] [ANN] Release of scikit-spatial package
In-Reply-To: <CAD-yzHZJSDvJsXQorZtAtqRpgANR35UN9fbE_2gmKKnUm1qkjQ@mail.gmail.com>
References: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
 <555a5a21-6a0a-4bf5-ba6f-83361c7f840a@www.fastmail.com>
 <CAD-yzHZJSDvJsXQorZtAtqRpgANR35UN9fbE_2gmKKnUm1qkjQ@mail.gmail.com>
Message-ID: <CAHPuU_aCzr+t1vgP_JaBYLP1gQQLMkBReS-1pvrHoKwdZykoYA@mail.gmail.com>

Some of the algorithms might be suitable for inclusion. Probably easier if
there's a nice paper / source for algorithm citation and it is clear that
we don't already have the functionality somewhere in SciPy.

To give one example, just browsing through, I see a collinearity algorithm.
Since collinearity is often used in the assessment of general position
prior to embarking on an algorithm in computational geometry,
it may be sensible to check if the low-level library we vendor for many
comp geo routines (Qhull) has a routine for this. Even if it does, it might
not be easy to expose directly, but it is a consideration I think.

Some of the operations, if ultimately suitable for inclusion, may fit in
the scipy.spatial.transform namespace, but probably case-by-case basis is
best in terms of assessing broad interest in the algorithm
and its suitability for inclusion.

On Mon, 8 Apr 2019 at 16:08, Andrew Hynes <andrewjhynes at gmail.com> wrote:

> Hi St?fan,
>
>> This looks neat!  It reminds me a bit of the following book which I
>> enjoyed:
>>
>> http://www.geometricalgebra.net/
>>
>
> Thanks for the link - it looks like a good source for expanding the
> package.
>
> Can you tell us a bit more about how you see these functions typically
>> being applied in practice?
>>
> Sure, I can give an example from my masters project. It involved clinical
> gait analysis with a depth camera, so I used some of these functions to
> calculate gait parameters from positions in space.
>
> A basic walking stride consists of three positions: The initial swing
> foot, the stance foot, and the final swing foot. The stride length is the
> distance from the initial to final swing foot. The stride width is the
> length of the projection from the stance foot to the swing path (the line
> from the initial swing foot to the final).
>
> Here's a snippet of code using scikit-spatial to calculate gait parameters
> from three points: point_a_i (initial swing foot), point_b (stance foot),
> and point_a_f (final swing foot).
>
> from skspatial.objects import Vector, Line
>
> vector_a = Vector.from_points(point_a_i, point_a_f)
> line_a = Line(point=point_a_i, direction=vector_a)
>
> point_b_proj = line_a.project_point(point_b)
>
> stride_length = vector_a.norm()
> absolute_step_length = Vector.from_points(point_b, point_a_f).norm()
> step_length = Vector.from_points(point_b_proj, point_a_f).norm()
> stride_width = line_a.distance_point(point_b)
>
>
> Hopefully that gives an idea as to how the package can be used.
>
> Thanks,
>
> Andrew
>
> P. S. Great job on scikit-image!
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190409/a8ee5bf3/attachment.html>

From deathcoderx at gmail.com  Wed Apr 10 06:38:34 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Wed, 10 Apr 2019 16:08:34 +0530
Subject: [SciPy-Dev] plan for SciPy 1.3.0 release
In-Reply-To: <CABL7CQgtG01tHJwLuQCafDAQAixYoNQQ5DhUHkG2yz-Su1x3mA@mail.gmail.com>
References: <CABL7CQgtG01tHJwLuQCafDAQAixYoNQQ5DhUHkG2yz-Su1x3mA@mail.gmail.com>
Message-ID: <CADYNDzibKKPGp4pOUP3Y96wxyRAQZq-pd6R4LUB9WwOELRHHiw@mail.gmail.com>

Hey,
What are roles and responsibilities of a release manager?
Any specific qualifications?

Cheers,
Gopi

On Tue, Apr 9, 2019 at 11:33 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

> Hi all,
>
> It's about time to start thinking about the next release. We should
> probably be aiming for around mid May. Is anyone interested to be the
> release manager for this release?
>
> Cheers,
> Ralf
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190410/d98c3b94/attachment.html>

From ralf.gommers at gmail.com  Wed Apr 10 07:06:33 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 10 Apr 2019 13:06:33 +0200
Subject: [SciPy-Dev] plan for SciPy 1.3.0 release
In-Reply-To: <CADYNDzibKKPGp4pOUP3Y96wxyRAQZq-pd6R4LUB9WwOELRHHiw@mail.gmail.com>
References: <CABL7CQgtG01tHJwLuQCafDAQAixYoNQQ5DhUHkG2yz-Su1x3mA@mail.gmail.com>
 <CADYNDzibKKPGp4pOUP3Y96wxyRAQZq-pd6R4LUB9WwOELRHHiw@mail.gmail.com>
Message-ID: <CABL7CQiFR5srtrDuq2LHqy6MSfhet6hgdZHiSHeb=YzHCLw3yA@mail.gmail.com>

On Wed, Apr 10, 2019 at 12:38 PM Gopi Manohar Tatiraju <
deathcoderx at gmail.com> wrote:

> Hey,
> What are roles and responsibilities of a release manager?
>

That's documented at
http://scipy.github.io/devdocs/dev/index.html#making-a-scipy-release.
Additionally, some decisions need to be made about backports etc (mostly
documented as well, search for "release manager" in that same page).

Any specific qualifications?
>

You should at least already be a project maintainer.

Cheers,
Ralf


> Cheers,
> Gopi
>
> On Tue, Apr 9, 2019 at 11:33 PM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>> Hi all,
>>
>> It's about time to start thinking about the next release. We should
>> probably be aiming for around mid May. Is anyone interested to be the
>> release manager for this release?
>>
>> Cheers,
>> Ralf
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190410/d9fc1964/attachment-0001.html>

From deathcoderx at gmail.com  Wed Apr 10 07:09:15 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Wed, 10 Apr 2019 16:39:15 +0530
Subject: [SciPy-Dev] plan for SciPy 1.3.0 release
In-Reply-To: <CABL7CQiFR5srtrDuq2LHqy6MSfhet6hgdZHiSHeb=YzHCLw3yA@mail.gmail.com>
References: <CABL7CQgtG01tHJwLuQCafDAQAixYoNQQ5DhUHkG2yz-Su1x3mA@mail.gmail.com>
 <CADYNDzibKKPGp4pOUP3Y96wxyRAQZq-pd6R4LUB9WwOELRHHiw@mail.gmail.com>
 <CABL7CQiFR5srtrDuq2LHqy6MSfhet6hgdZHiSHeb=YzHCLw3yA@mail.gmail.com>
Message-ID: <CADYNDzjhC7pZAMrMJQ_jN68zK0-6suFyxWGnK=b7isE9hOpdCg@mail.gmail.com>

I am not a project manager already, so that puts me out of options, right?

On Wed, Apr 10, 2019, 4:37 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Wed, Apr 10, 2019 at 12:38 PM Gopi Manohar Tatiraju <
> deathcoderx at gmail.com> wrote:
>
>> Hey,
>> What are roles and responsibilities of a release manager?
>>
>
> That's documented at
> http://scipy.github.io/devdocs/dev/index.html#making-a-scipy-release.
> Additionally, some decisions need to be made about backports etc (mostly
> documented as well, search for "release manager" in that same page).
>
> Any specific qualifications?
>>
>
> You should at least already be a project maintainer.
>
> Cheers,
> Ralf
>
>
>> Cheers,
>> Gopi
>>
>> On Tue, Apr 9, 2019 at 11:33 PM Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> It's about time to start thinking about the next release. We should
>>> probably be aiming for around mid May. Is anyone interested to be the
>>> release manager for this release?
>>>
>>> Cheers,
>>> Ralf
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190410/62d55b6a/attachment.html>

From ralf.gommers at gmail.com  Wed Apr 10 07:38:05 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 10 Apr 2019 13:38:05 +0200
Subject: [SciPy-Dev] plan for SciPy 1.3.0 release
In-Reply-To: <CADYNDzjhC7pZAMrMJQ_jN68zK0-6suFyxWGnK=b7isE9hOpdCg@mail.gmail.com>
References: <CABL7CQgtG01tHJwLuQCafDAQAixYoNQQ5DhUHkG2yz-Su1x3mA@mail.gmail.com>
 <CADYNDzibKKPGp4pOUP3Y96wxyRAQZq-pd6R4LUB9WwOELRHHiw@mail.gmail.com>
 <CABL7CQiFR5srtrDuq2LHqy6MSfhet6hgdZHiSHeb=YzHCLw3yA@mail.gmail.com>
 <CADYNDzjhC7pZAMrMJQ_jN68zK0-6suFyxWGnK=b7isE9hOpdCg@mail.gmail.com>
Message-ID: <CABL7CQjJiedxUa0c5U4W52ydFHnV0pSd07A3EFy32VSEc1c-OQ@mail.gmail.com>

On Wed, Apr 10, 2019 at 1:09 PM Gopi Manohar Tatiraju <deathcoderx at gmail.com>
wrote:

> I am not a project manager already, so that puts me out of options, right?
>

Yes:) Release manager is one of the more complex things to do in a project.
You're new to the community, so it would be better to start simple, like
with a few more pull requests:) I believe I have reviewed one from you
before.

Cheers,
Ralf


> On Wed, Apr 10, 2019, 4:37 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>>
>>
>> On Wed, Apr 10, 2019 at 12:38 PM Gopi Manohar Tatiraju <
>> deathcoderx at gmail.com> wrote:
>>
>>> Hey,
>>> What are roles and responsibilities of a release manager?
>>>
>>
>> That's documented at
>> http://scipy.github.io/devdocs/dev/index.html#making-a-scipy-release.
>> Additionally, some decisions need to be made about backports etc (mostly
>> documented as well, search for "release manager" in that same page).
>>
>> Any specific qualifications?
>>>
>>
>> You should at least already be a project maintainer.
>>
>> Cheers,
>> Ralf
>>
>>
>>> Cheers,
>>> Gopi
>>>
>>> On Tue, Apr 9, 2019 at 11:33 PM Ralf Gommers <ralf.gommers at gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> It's about time to start thinking about the next release. We should
>>>> probably be aiming for around mid May. Is anyone interested to be the
>>>> release manager for this release?
>>>>
>>>> Cheers,
>>>> Ralf
>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190410/edbf1348/attachment.html>

From deathcoderx at gmail.com  Wed Apr 10 07:46:13 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Wed, 10 Apr 2019 17:16:13 +0530
Subject: [SciPy-Dev] plan for SciPy 1.3.0 release
In-Reply-To: <CABL7CQjJiedxUa0c5U4W52ydFHnV0pSd07A3EFy32VSEc1c-OQ@mail.gmail.com>
References: <CABL7CQgtG01tHJwLuQCafDAQAixYoNQQ5DhUHkG2yz-Su1x3mA@mail.gmail.com>
 <CADYNDzibKKPGp4pOUP3Y96wxyRAQZq-pd6R4LUB9WwOELRHHiw@mail.gmail.com>
 <CABL7CQiFR5srtrDuq2LHqy6MSfhet6hgdZHiSHeb=YzHCLw3yA@mail.gmail.com>
 <CADYNDzjhC7pZAMrMJQ_jN68zK0-6suFyxWGnK=b7isE9hOpdCg@mail.gmail.com>
 <CABL7CQjJiedxUa0c5U4W52ydFHnV0pSd07A3EFy32VSEc1c-OQ@mail.gmail.com>
Message-ID: <CADYNDzii3Pn4Ko1b7ekUhf7P9hchnc9-+K7z-5rnfiGfx=Ex+w@mail.gmail.com>

Yea, you did.
And I will keep contributing to this community.

Cheers.

On Wed, Apr 10, 2019, 5:09 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Wed, Apr 10, 2019 at 1:09 PM Gopi Manohar Tatiraju <
> deathcoderx at gmail.com> wrote:
>
>> I am not a project manager already, so that puts me out of options, right?
>>
>
> Yes:) Release manager is one of the more complex things to do in a
> project. You're new to the community, so it would be better to start
> simple, like with a few more pull requests:) I believe I have reviewed one
> from you before.
>
> Cheers,
> Ralf
>
>
>> On Wed, Apr 10, 2019, 4:37 PM Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 10, 2019 at 12:38 PM Gopi Manohar Tatiraju <
>>> deathcoderx at gmail.com> wrote:
>>>
>>>> Hey,
>>>> What are roles and responsibilities of a release manager?
>>>>
>>>
>>> That's documented at
>>> http://scipy.github.io/devdocs/dev/index.html#making-a-scipy-release.
>>> Additionally, some decisions need to be made about backports etc (mostly
>>> documented as well, search for "release manager" in that same page).
>>>
>>> Any specific qualifications?
>>>>
>>>
>>> You should at least already be a project maintainer.
>>>
>>> Cheers,
>>> Ralf
>>>
>>>
>>>> Cheers,
>>>> Gopi
>>>>
>>>> On Tue, Apr 9, 2019 at 11:33 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> It's about time to start thinking about the next release. We should
>>>>> probably be aiming for around mid May. Is anyone interested to be the
>>>>> release manager for this release?
>>>>>
>>>>> Cheers,
>>>>> Ralf
>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190410/858bd605/attachment-0001.html>

From tyler.je.reddy at gmail.com  Wed Apr 10 13:07:37 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Wed, 10 Apr 2019 10:07:37 -0700
Subject: [SciPy-Dev] plan for SciPy 1.3.0 release
In-Reply-To: <CADYNDzii3Pn4Ko1b7ekUhf7P9hchnc9-+K7z-5rnfiGfx=Ex+w@mail.gmail.com>
References: <CABL7CQgtG01tHJwLuQCafDAQAixYoNQQ5DhUHkG2yz-Su1x3mA@mail.gmail.com>
 <CADYNDzibKKPGp4pOUP3Y96wxyRAQZq-pd6R4LUB9WwOELRHHiw@mail.gmail.com>
 <CABL7CQiFR5srtrDuq2LHqy6MSfhet6hgdZHiSHeb=YzHCLw3yA@mail.gmail.com>
 <CADYNDzjhC7pZAMrMJQ_jN68zK0-6suFyxWGnK=b7isE9hOpdCg@mail.gmail.com>
 <CABL7CQjJiedxUa0c5U4W52ydFHnV0pSd07A3EFy32VSEc1c-OQ@mail.gmail.com>
 <CADYNDzii3Pn4Ko1b7ekUhf7P9hchnc9-+K7z-5rnfiGfx=Ex+w@mail.gmail.com>
Message-ID: <CAHPuU_aR2kOk5cy9ESjRhCcz4PjZpBMm2gtKdFuN=aQ9C6+Q8g@mail.gmail.com>

I can do this again if I'm not depriving another maintainer that wants to
try.

On Wed, 10 Apr 2019 at 04:46, Gopi Manohar Tatiraju <deathcoderx at gmail.com>
wrote:

> Yea, you did.
> And I will keep contributing to this community.
>
> Cheers.
>
> On Wed, Apr 10, 2019, 5:09 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>>
>>
>> On Wed, Apr 10, 2019 at 1:09 PM Gopi Manohar Tatiraju <
>> deathcoderx at gmail.com> wrote:
>>
>>> I am not a project manager already, so that puts me out of options,
>>> right?
>>>
>>
>> Yes:) Release manager is one of the more complex things to do in a
>> project. You're new to the community, so it would be better to start
>> simple, like with a few more pull requests:) I believe I have reviewed one
>> from you before.
>>
>> Cheers,
>> Ralf
>>
>>
>>> On Wed, Apr 10, 2019, 4:37 PM Ralf Gommers <ralf.gommers at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Apr 10, 2019 at 12:38 PM Gopi Manohar Tatiraju <
>>>> deathcoderx at gmail.com> wrote:
>>>>
>>>>> Hey,
>>>>> What are roles and responsibilities of a release manager?
>>>>>
>>>>
>>>> That's documented at
>>>> http://scipy.github.io/devdocs/dev/index.html#making-a-scipy-release.
>>>> Additionally, some decisions need to be made about backports etc (mostly
>>>> documented as well, search for "release manager" in that same page).
>>>>
>>>> Any specific qualifications?
>>>>>
>>>>
>>>> You should at least already be a project maintainer.
>>>>
>>>> Cheers,
>>>> Ralf
>>>>
>>>>
>>>>> Cheers,
>>>>> Gopi
>>>>>
>>>>> On Tue, Apr 9, 2019 at 11:33 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> It's about time to start thinking about the next release. We should
>>>>>> probably be aiming for around mid May. Is anyone interested to be the
>>>>>> release manager for this release?
>>>>>>
>>>>>> Cheers,
>>>>>> Ralf
>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190410/de4354f7/attachment.html>

From ilhanpolat at gmail.com  Wed Apr 10 14:38:14 2019
From: ilhanpolat at gmail.com (Ilhan Polat)
Date: Wed, 10 Apr 2019 20:38:14 +0200
Subject: [SciPy-Dev] plan for SciPy 1.3.0 release
In-Reply-To: <CAHPuU_aR2kOk5cy9ESjRhCcz4PjZpBMm2gtKdFuN=aQ9C6+Q8g@mail.gmail.com>
References: <CABL7CQgtG01tHJwLuQCafDAQAixYoNQQ5DhUHkG2yz-Su1x3mA@mail.gmail.com>
 <CADYNDzibKKPGp4pOUP3Y96wxyRAQZq-pd6R4LUB9WwOELRHHiw@mail.gmail.com>
 <CABL7CQiFR5srtrDuq2LHqy6MSfhet6hgdZHiSHeb=YzHCLw3yA@mail.gmail.com>
 <CADYNDzjhC7pZAMrMJQ_jN68zK0-6suFyxWGnK=b7isE9hOpdCg@mail.gmail.com>
 <CABL7CQjJiedxUa0c5U4W52ydFHnV0pSd07A3EFy32VSEc1c-OQ@mail.gmail.com>
 <CADYNDzii3Pn4Ko1b7ekUhf7P9hchnc9-+K7z-5rnfiGfx=Ex+w@mail.gmail.com>
 <CAHPuU_aR2kOk5cy9ESjRhCcz4PjZpBMm2gtKdFuN=aQ9C6+Q8g@mail.gmail.com>
Message-ID: <CAEBuzr8CFKMf2OSaAKfx=DD-6f0=zCPoCmKKFJf_oow0=QxLYQ@mail.gmail.com>

I would prefer Tyler do it but if he is already healing the previous 1.2.1
wounds I can be the backup. Though OSX wheels are really really frightening
me

/* Bohemian Rhapsody starts to play */

On Wed, Apr 10, 2019 at 7:08 PM Tyler Reddy <tyler.je.reddy at gmail.com>
wrote:

> I can do this again if I'm not depriving another maintainer that wants to
> try.
>
> On Wed, 10 Apr 2019 at 04:46, Gopi Manohar Tatiraju <deathcoderx at gmail.com>
> wrote:
>
>> Yea, you did.
>> And I will keep contributing to this community.
>>
>> Cheers.
>>
>> On Wed, Apr 10, 2019, 5:09 PM Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 10, 2019 at 1:09 PM Gopi Manohar Tatiraju <
>>> deathcoderx at gmail.com> wrote:
>>>
>>>> I am not a project manager already, so that puts me out of options,
>>>> right?
>>>>
>>>
>>> Yes:) Release manager is one of the more complex things to do in a
>>> project. You're new to the community, so it would be better to start
>>> simple, like with a few more pull requests:) I believe I have reviewed one
>>> from you before.
>>>
>>> Cheers,
>>> Ralf
>>>
>>>
>>>> On Wed, Apr 10, 2019, 4:37 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 10, 2019 at 12:38 PM Gopi Manohar Tatiraju <
>>>>> deathcoderx at gmail.com> wrote:
>>>>>
>>>>>> Hey,
>>>>>> What are roles and responsibilities of a release manager?
>>>>>>
>>>>>
>>>>> That's documented at
>>>>> http://scipy.github.io/devdocs/dev/index.html#making-a-scipy-release.
>>>>> Additionally, some decisions need to be made about backports etc (mostly
>>>>> documented as well, search for "release manager" in that same page).
>>>>>
>>>>> Any specific qualifications?
>>>>>>
>>>>>
>>>>> You should at least already be a project maintainer.
>>>>>
>>>>> Cheers,
>>>>> Ralf
>>>>>
>>>>>
>>>>>> Cheers,
>>>>>> Gopi
>>>>>>
>>>>>> On Tue, Apr 9, 2019 at 11:33 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> It's about time to start thinking about the next release. We should
>>>>>>> probably be aiming for around mid May. Is anyone interested to be the
>>>>>>> release manager for this release?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ralf
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190410/698e7eb5/attachment-0001.html>

From andrewjhynes at gmail.com  Wed Apr 10 22:18:06 2019
From: andrewjhynes at gmail.com (Andrew Hynes)
Date: Wed, 10 Apr 2019 22:18:06 -0400
Subject: [SciPy-Dev] [ANN] Release of scikit-spatial package
In-Reply-To: <CAHPuU_aCzr+t1vgP_JaBYLP1gQQLMkBReS-1pvrHoKwdZykoYA@mail.gmail.com>
References: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
 <555a5a21-6a0a-4bf5-ba6f-83361c7f840a@www.fastmail.com>
 <CAD-yzHZJSDvJsXQorZtAtqRpgANR35UN9fbE_2gmKKnUm1qkjQ@mail.gmail.com>
 <CAHPuU_aCzr+t1vgP_JaBYLP1gQQLMkBReS-1pvrHoKwdZykoYA@mail.gmail.com>
Message-ID: <CAD-yzHZc2WL4kmxJO6_MAUODLDdKio93+jekTYfyyDuf2fC3cQ@mail.gmail.com>

Hello Tyler,

Some of the algorithms might be suitable for inclusion. Probably easier if
> there's a nice paper / source for algorithm citation and it is clear that
> we don't already have the functionality somewhere in SciPy.
>

My main reference for the functions has been http://mathworld.wolfram.com/.
Some of the docstrings have a link to the relevant webpage.

I'd like to try making a pull request for scipy.spatial. Is there an area
of scikit-spatial that you think would be best to start?

Also, would you prefer that the code is not object-oriented? For example,
the collinearity function is a method of the Points class, but I can adapt
it to be a regular function that takes a 2D ndarray as input. Or if you're
fine with the object oriented style, I can work on a pull request to
include the Point and Vector classes, which could be imported from a
scipy.spatial.objects module.

Thanks,

Andrew


On Tue, Apr 9, 2019 at 2:05 PM Tyler Reddy <tyler.je.reddy at gmail.com> wrote:

> Some of the algorithms might be suitable for inclusion. Probably easier if
> there's a nice paper / source for algorithm citation and it is clear that
> we don't already have the functionality somewhere in SciPy.
>
> To give one example, just browsing through, I see a collinearity
> algorithm. Since collinearity is often used in the assessment of general
> position prior to embarking on an algorithm in computational geometry,
> it may be sensible to check if the low-level library we vendor for many
> comp geo routines (Qhull) has a routine for this. Even if it does, it might
> not be easy to expose directly, but it is a consideration I think.
>
> Some of the operations, if ultimately suitable for inclusion, may fit in
> the scipy.spatial.transform namespace, but probably case-by-case basis is
> best in terms of assessing broad interest in the algorithm
> and its suitability for inclusion.
>
> On Mon, 8 Apr 2019 at 16:08, Andrew Hynes <andrewjhynes at gmail.com> wrote:
>
>> Hi St?fan,
>>
>>> This looks neat!  It reminds me a bit of the following book which I
>>> enjoyed:
>>>
>>> http://www.geometricalgebra.net/
>>>
>>
>> Thanks for the link - it looks like a good source for expanding the
>> package.
>>
>> Can you tell us a bit more about how you see these functions typically
>>> being applied in practice?
>>>
>> Sure, I can give an example from my masters project. It involved clinical
>> gait analysis with a depth camera, so I used some of these functions to
>> calculate gait parameters from positions in space.
>>
>> A basic walking stride consists of three positions: The initial swing
>> foot, the stance foot, and the final swing foot. The stride length is the
>> distance from the initial to final swing foot. The stride width is the
>> length of the projection from the stance foot to the swing path (the line
>> from the initial swing foot to the final).
>>
>> Here's a snippet of code using scikit-spatial to calculate gait
>> parameters from three points: point_a_i (initial swing foot), point_b
>> (stance foot), and point_a_f (final swing foot).
>>
>> from skspatial.objects import Vector, Line
>>
>> vector_a = Vector.from_points(point_a_i, point_a_f)
>> line_a = Line(point=point_a_i, direction=vector_a)
>>
>> point_b_proj = line_a.project_point(point_b)
>>
>> stride_length = vector_a.norm()
>> absolute_step_length = Vector.from_points(point_b, point_a_f).norm()
>> step_length = Vector.from_points(point_b_proj, point_a_f).norm()
>> stride_width = line_a.distance_point(point_b)
>>
>>
>> Hopefully that gives an idea as to how the package can be used.
>>
>> Thanks,
>>
>> Andrew
>>
>> P. S. Great job on scikit-image!
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190410/225ff187/attachment.html>

From ralf.gommers at gmail.com  Fri Apr 12 04:56:06 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Fri, 12 Apr 2019 10:56:06 +0200
Subject: [SciPy-Dev] plan for SciPy 1.3.0 release
In-Reply-To: <CAEBuzr8CFKMf2OSaAKfx=DD-6f0=zCPoCmKKFJf_oow0=QxLYQ@mail.gmail.com>
References: <CABL7CQgtG01tHJwLuQCafDAQAixYoNQQ5DhUHkG2yz-Su1x3mA@mail.gmail.com>
 <CADYNDzibKKPGp4pOUP3Y96wxyRAQZq-pd6R4LUB9WwOELRHHiw@mail.gmail.com>
 <CABL7CQiFR5srtrDuq2LHqy6MSfhet6hgdZHiSHeb=YzHCLw3yA@mail.gmail.com>
 <CADYNDzjhC7pZAMrMJQ_jN68zK0-6suFyxWGnK=b7isE9hOpdCg@mail.gmail.com>
 <CABL7CQjJiedxUa0c5U4W52ydFHnV0pSd07A3EFy32VSEc1c-OQ@mail.gmail.com>
 <CADYNDzii3Pn4Ko1b7ekUhf7P9hchnc9-+K7z-5rnfiGfx=Ex+w@mail.gmail.com>
 <CAHPuU_aR2kOk5cy9ESjRhCcz4PjZpBMm2gtKdFuN=aQ9C6+Q8g@mail.gmail.com>
 <CAEBuzr8CFKMf2OSaAKfx=DD-6f0=zCPoCmKKFJf_oow0=QxLYQ@mail.gmail.com>
Message-ID: <CABL7CQgoazbCBuuCys=L3piDAp7ChhG+=TJWZdCHCDDdBxcKvA@mail.gmail.com>

On Wed, Apr 10, 2019 at 8:38 PM Ilhan Polat <ilhanpolat at gmail.com> wrote:

> I would prefer Tyler do it but if he is already healing the previous 1.2.1
> wounds I can be the backup.
>

Same here, I'm happy to do it but Tyler did a great job last time around
and I also have lost of other ideas of things to work on:)

No other takers, so Tyler will be the release manager. Thanks a lot for
offering Tyler!

Though OSX wheels are really really frightening me
>

It's a matter of changing one commit hash in a config file and pushing a
commit - the rest is all automated. Wheels are mostly a smooth experience
these days.

Cheers,
Ralf



> /* Bohemian Rhapsody starts to play */
>
> On Wed, Apr 10, 2019 at 7:08 PM Tyler Reddy <tyler.je.reddy at gmail.com>
> wrote:
>
>> I can do this again if I'm not depriving another maintainer that wants to
>> try.
>>
>> On Wed, 10 Apr 2019 at 04:46, Gopi Manohar Tatiraju <
>> deathcoderx at gmail.com> wrote:
>>
>>> Yea, you did.
>>> And I will keep contributing to this community.
>>>
>>> Cheers.
>>>
>>> On Wed, Apr 10, 2019, 5:09 PM Ralf Gommers <ralf.gommers at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Apr 10, 2019 at 1:09 PM Gopi Manohar Tatiraju <
>>>> deathcoderx at gmail.com> wrote:
>>>>
>>>>> I am not a project manager already, so that puts me out of options,
>>>>> right?
>>>>>
>>>>
>>>> Yes:) Release manager is one of the more complex things to do in a
>>>> project. You're new to the community, so it would be better to start
>>>> simple, like with a few more pull requests:) I believe I have reviewed one
>>>> from you before.
>>>>
>>>> Cheers,
>>>> Ralf
>>>>
>>>>
>>>>> On Wed, Apr 10, 2019, 4:37 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 10, 2019 at 12:38 PM Gopi Manohar Tatiraju <
>>>>>> deathcoderx at gmail.com> wrote:
>>>>>>
>>>>>>> Hey,
>>>>>>> What are roles and responsibilities of a release manager?
>>>>>>>
>>>>>>
>>>>>> That's documented at
>>>>>> http://scipy.github.io/devdocs/dev/index.html#making-a-scipy-release.
>>>>>> Additionally, some decisions need to be made about backports etc (mostly
>>>>>> documented as well, search for "release manager" in that same page).
>>>>>>
>>>>>> Any specific qualifications?
>>>>>>>
>>>>>>
>>>>>> You should at least already be a project maintainer.
>>>>>>
>>>>>> Cheers,
>>>>>> Ralf
>>>>>>
>>>>>>
>>>>>>> Cheers,
>>>>>>> Gopi
>>>>>>>
>>>>>>> On Tue, Apr 9, 2019 at 11:33 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> It's about time to start thinking about the next release. We should
>>>>>>>> probably be aiming for around mid May. Is anyone interested to be the
>>>>>>>> release manager for this release?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Ralf
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190412/65e5a8e6/attachment.html>

From tyler.je.reddy at gmail.com  Sat Apr 13 17:19:11 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Sat, 13 Apr 2019 14:19:11 -0700
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
Message-ID: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>

Hi All,

It is almost 4 months after the (slightly-delayed) 1.2.0 release on
December 17/ 2018, so probably time to plan the 1.3.0 release. It would be
a good idea to look over the PRs with a 1.3.0 milestone, and tag anything
else that should have this milestone appropriately.

I'd like to propose the following schedule:

April 25: branch 1.3.x
April 28: rc1
May 11: rc2 (if needed)
May 20: final release

Thoughts?
Tyler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190413/d19c6dd8/attachment.html>

From andyfaff at gmail.com  Sat Apr 13 18:27:15 2019
From: andyfaff at gmail.com (Andrew Nelson)
Date: Sun, 14 Apr 2019 08:27:15 +1000
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
Message-ID: <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>

Would it be possible to add 9990 and 10002 to 1.3.0, or is that too
ambitious?

On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <tyler.je.reddy at gmail.com> wrote:

> Hi All,
>
> It is almost 4 months after the (slightly-delayed) 1.2.0 release on
> December 17/ 2018, so probably time to plan the 1.3.0 release. It would be
> a good idea to look over the PRs with a 1.3.0 milestone, and tag anything
> else that should have this milestone appropriately.
>
> I'd like to propose the following schedule:
>
> April 25: branch 1.3.x
> April 28: rc1
> May 11: rc2 (if needed)
> May 20: final release
>
> Thoughts?
> Tyler
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190414/82458bc7/attachment.html>

From ralf.gommers at gmail.com  Sun Apr 14 05:12:20 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 14 Apr 2019 11:12:20 +0200
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
 <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
Message-ID: <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>

On Sun, Apr 14, 2019 at 12:27 AM Andrew Nelson <andyfaff at gmail.com> wrote:

> Would it be possible to add 9990 and 10002 to 1.3.0, or is that too
> ambitious?
>

Those look like they're in good shape, should be doable. I've added them to
the milestone. Tyler can always remove them again if we run out of time.


> On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <tyler.je.reddy at gmail.com>
> wrote:
>
>> Hi All,
>>
>> It is almost 4 months after the (slightly-delayed) 1.2.0 release on
>> December 17/ 2018, so probably time to plan the 1.3.0 release. It would be
>> a good idea to look over the PRs with a 1.3.0 milestone, and tag anything
>> else that should have this milestone appropriately.
>>
>> I'd like to propose the following schedule:
>>
>> April 25: branch 1.3.x
>> April 28: rc1
>> May 11: rc2 (if needed)
>> May 20: final release
>>
>> Thoughts?
>>
>
That works for me. There may be a few items in
https://github.com/scipy/scipy/milestone/37 that we won't get to, but the
only real blocker (py37 build issue) on that list is ready to merge.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190414/8f7c9361/attachment.html>

From mikofski at berkeley.edu  Sun Apr 14 10:39:28 2019
From: mikofski at berkeley.edu (Mark Alexander Mikofski)
Date: Sun, 14 Apr 2019 07:39:28 -0700
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
 <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
 <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>
Message-ID: <CAEqRcW27eWa_ypS9wU-2UXuQ7mZDCyhBpHzvWOpHDS2Aza19Nw@mail.gmail.com>

Hi Tyler,

Thanks for managing the release again! This is a very important service for
the SciPy community, and I'm very grateful!

Do you think we could try to add #9568 and #10052 assuming everyone agrees
they are good?

thanks again!
Mark

On Sun, Apr 14, 2019 at 2:13 AM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Sun, Apr 14, 2019 at 12:27 AM Andrew Nelson <andyfaff at gmail.com> wrote:
>
>> Would it be possible to add 9990 and 10002 to 1.3.0, or is that too
>> ambitious?
>>
>
> Those look like they're in good shape, should be doable. I've added them
> to the milestone. Tyler can always remove them again if we run out of time.
>
>
>> On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <tyler.je.reddy at gmail.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> It is almost 4 months after the (slightly-delayed) 1.2.0 release on
>>> December 17/ 2018, so probably time to plan the 1.3.0 release. It would be
>>> a good idea to look over the PRs with a 1.3.0 milestone, and tag anything
>>> else that should have this milestone appropriately.
>>>
>>> I'd like to propose the following schedule:
>>>
>>> April 25: branch 1.3.x
>>> April 28: rc1
>>> May 11: rc2 (if needed)
>>> May 20: final release
>>>
>>> Thoughts?
>>>
>>
> That works for me. There may be a few items in
> https://github.com/scipy/scipy/milestone/37 that we won't get to, but the
> only real blocker (py37 build issue) on that list is ready to merge.
>
> Cheers,
> Ralf
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>


-- 
Mark Mikofski, PhD (2005)
*Fiat Lux*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190414/99916491/attachment-0001.html>

From ralf.gommers at gmail.com  Sun Apr 14 11:35:52 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 14 Apr 2019 17:35:52 +0200
Subject: [SciPy-Dev] Google Season of Docs
In-Reply-To: <CABXY2qB5NuaTdfWnPOF+BUDZWHdMrzgWG4ZMC97LBMZr4TCrQQ@mail.gmail.com>
References: <mailman.1683.1554388938.2938.scipy-dev@python.org>
 <CABXY2qB5NuaTdfWnPOF+BUDZWHdMrzgWG4ZMC97LBMZr4TCrQQ@mail.gmail.com>
Message-ID: <CABL7CQjtmCZfZgYVc2jEHYc8FChp3MYZC+ADXbyMYN3Wzuo5mg@mail.gmail.com>

On Fri, Apr 5, 2019 at 9:24 PM Christoph Baumgarten <
christoph.baumgarten at gmail.com> wrote:

>
> I created a first draft in a forked repo:
>
> https://github.com/chrisb83/gsod/blob/gsod-stats/2019/SciPy_ideas_list.md
>
> Feedback is welcome!
> https://github.com/chrisb83/gsod/pull/1
>

Thanks Chris! Sorry it took a while to get to this. Your content looked
good, I added a bit to it in https://github.com/numfocus/gsod/pull/4. I
also added a second idea and high level information about the state of
SciPy's docs and how we build/develop it.

Cheers,
Ralf



>
> On Thu, Apr 4, 2019 at 4:43 PM <scipy-dev-request at python.org> wrote:
>
>> Send SciPy-Dev mailing list submissions to
>>         scipy-dev at python.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://mail.python.org/mailman/listinfo/scipy-dev
>> or, via email, send a message with subject or body 'help' to
>>         scipy-dev-request at python.org
>>
>> You can reach the person managing the list at
>>         scipy-dev-owner at python.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of SciPy-Dev digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Google Season of Docs (Ralf Gommers)
>>    2. Re: GSoC 2019 Projects (Gregory Lee)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 4 Apr 2019 13:26:40 +0200
>> From: Ralf Gommers <ralf.gommers at gmail.com>
>> To: SciPy Developers List <scipy-dev at python.org>
>> Subject: Re: [SciPy-Dev] Google Season of Docs
>> Message-ID:
>>         <CABL7CQg5Qyjb=
>> xf_JMmAOvLamd330m47E1Y356-cLfj99TOXKA at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Wed, Apr 3, 2019 at 11:49 PM Paul van Mulbregt <
>> p.vanmulbregt at comcast.net>
>> wrote:
>>
>> > I can be a second mentor for the stats documentation proposal.
>> >
>>
>> Great, thanks Paul!
>>
>>
>> > -Paul
>> >
>> > On Apr 3, 2019, at 3:12 PM, Christoph Baumgarten <
>> > christoph.baumgarten at gmail.com> wrote:
>> >
>> >
>> > Sure, I will add it in the next few days.
>> >
>> > On Tue, Apr 2, 2019 at 6:02 PM <scipy-dev-request at python.org> wrote:
>> >
>> >> Send SciPy-Dev mailing list submissions to
>> >>         scipy-dev at python.org
>> >>
>> >> To subscribe or unsubscribe via the World Wide Web, visit
>> >>         https://mail.python.org/mailman/listinfo/scipy-dev
>> >> or, via email, send a message with subject or body 'help' to
>> >>         scipy-dev-request at python.org
>> >>
>> >> You can reach the person managing the list at
>> >>         scipy-dev-owner at python.org
>> >>
>> >> When replying, please edit your Subject line so it is more specific
>> >> than "Re: Contents of SciPy-Dev digest..."
>> >>
>> >>
>> >> Today's Topics:
>> >>
>> >>    1. Re: Google Season of Docs (Ralf Gommers)
>> >>
>> >>
>> >> ----------------------------------------------------------------------
>> >>
>> >> Message: 1
>> >> Date: Tue, 2 Apr 2019 10:40:20 +0200
>> >> From: Ralf Gommers <ralf.gommers at gmail.com>
>> >> To: SciPy Developers List <scipy-dev at python.org>
>> >> Subject: Re: [SciPy-Dev] Google Season of Docs
>> >> Message-ID:
>> >>         <CABL7CQipvttnWrAE=
>> >> V6Fr+iJKjGM1x0wgKbK-ea7ZNsOXx6YDg at mail.gmail.com>
>> >> Content-Type: text/plain; charset="utf-8"
>> >>
>> >> On Fri, Mar 22, 2019 at 8:07 PM Ralf Gommers <ralf.gommers at gmail.com>
>> >> wrote:
>> >>
>> >> >
>> >> >
>> >> > On Thu, Mar 21, 2019 at 12:10 PM Christoph Baumgarten <
>> >> > christoph.baumgarten at gmail.com> wrote:
>> >> >
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> taking up Ralf's mail on GSoD, I had a look at the website and
>> propose
>> >> to
>> >> >> apply.
>> >> >>
>> >> >> My project suggestion would be to work on the documentation of a
>> module
>> >> >> like stats:
>> >> >>
>> >> >
>> >> >> - improve the tutorial site
>> >> >> https://docs.scipy.org/doc/scipy/reference/tutorial/stats.html
>> >> >> - improve the documentation of the API
>> >> >>   - check whether current descriptions can be improved
>> >> >>   - add examples and references
>> >> >>   - cross-ref to other relevant / similar functions in the module
>> >> >>
>> >> >> The second point would require decent knowledge of statistics
>> whereas
>> >> the
>> >> >> first point should be easier to tackle for a technical writer. So I
>> >> see the
>> >> >> second point as optional and one could also try to work on the
>> tutorial
>> >> >> site of more than one module during the 3-month period.
>> >> >>
>> >> >
>> >> >> The task would leave quite a bit of freedom to the writer to choose
>> >> what
>> >> >> areas to focus on, potentially taking up some of the documentation
>> >> issues
>> >> >> that are already on Github.
>> >> >>
>> >> >> I could assist as a mentor for stats (we need at least two mentors).
>> >> >>
>> >> >> Any suggestions or comments?
>> >> >>
>> >> >
>> >> > Thanks Christoph, this sounds like a good idea to me. We have a lot
>> of
>> >> > content on scipy.stats, and a tech writer could really make a
>> >> difference in
>> >> > making that easier to understand for users. I suggest we write this
>> up
>> >> as
>> >> > an idea on our (to be created) ideas page as soon as we know whether
>> we
>> >> > have an umbrella organization that we can participate with.
>> >> >
>> >>
>> >>  An update on this: NumFOCUS is applying as an umbrella org. We'll
>> need to
>> >> add our ideas at
>> >> https://github.com/numfocus/gsod/blob/master/2019/SciPy_ideas_list.md.
>> >> Since there are going to be few spots available, it's the quality of
>> the
>> >> content that matters for acceptance of NumFOCUS as an umbrella org. We
>> >> should have 1-2 ideas that are well described up on that page by April
>> >> 14th. There are some guidelines at
>> >>
>> >>
>> https://developers.google.com/season-of-docs/docs/project-ideas#project-idea
>> >>
>> >> Christoph, could you add your idea in that SciPy_ideas_list.md file?
>> >>
>> >> I will add some more general information there about getting started on
>> >> the
>> >> SciPy docs. Also, if anyone has another idea, that would be great to
>> hear.
>> >>
>> >> Cheers,
>> >> Ralf
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >> URL: <
>> >>
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190402/244fdd76/attachment-0001.html
>> >> >
>> >>
>> >> ------------------------------
>> >>
>> >> Subject: Digest Footer
>> >>
>> >> _______________________________________________
>> >> SciPy-Dev mailing list
>> >> SciPy-Dev at python.org
>> >> https://mail.python.org/mailman/listinfo/scipy-dev
>> >>
>> >>
>> >> ------------------------------
>> >>
>> >> End of SciPy-Dev Digest, Vol 186, Issue 6
>> >> *****************************************
>> >>
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190404/8005557c/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 4 Apr 2019 10:42:04 -0400
>> From: Gregory Lee <grlee77 at gmail.com>
>> To: SciPy Developers List <scipy-dev at python.org>
>> Subject: Re: [SciPy-Dev] GSoC 2019 Projects
>> Message-ID:
>>         <CAJR3sXcsQATgJ952UK+Bigqf-L8EVL0hS=
>> XMWahNyZKHVhcs0Q at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi Peter,
>>
>> Yes, the application period is still open for GSOC, although the final
>> deadline is the 9th, so time is becoming fairly short to get feedback on
>> proposals.
>>
>> A few other students have expressed interest in the FFT-based backends,
>> but
>> any interested candidates are welcome to apply. Please see some prior
>> posts
>> on this lists for some discussions related to that project. The primary
>> intention is to allow 3rd party implementations to override the ones
>> provided by SciPy when requested. Ideally there should also be some way to
>> provide additional arguments specific to those implementations (e.g.
>> specifying number of threads, planner effort, etc in the case of PyFFTW).
>> We do not want any breaking changes to the existing scipy.fftpack
>> interfaces as we need to maintain backwards compatibility with a lot of
>> preexisting code in downstream libraries. Ideally downstream libraries
>> should be able to benefit from the changes made in SciPy without any
>> substantial refactoring on their end.
>>
>> I am not personally familiar with the specifics of the ODE project and do
>> not know if other candidates are currently pursuing that topic. Hopefully
>> one of the mentors for it can respond here.
>>
>> - Greg
>>
>>
>>
>>
>> On Wed, Apr 3, 2019 at 10:05 AM Peter Bell <peterbell10 at live.co.uk>
>> wrote:
>>
>> > Hello,
>> >
>> >
>> >
>> > I am interested in applying for Google summer of code and was wondering
>> if
>> > you
>> >
>> > are still looking for students?
>> >
>> >
>> >
>> > A bit about myself
>> >
>> > -------------------
>> >
>> > My name is Peter and I'm in my 4th (penultimate) year of an integrated
>> > masters
>> >
>> > in computational physics. Programming and numerical methods forms a key
>> > part of
>> >
>> > this degree and many of my courses make heavy use of python with cython,
>> > numpy,
>> >
>> > scipy, matplotlib, etc. While my degree is primarily Physics, I have
>> taken
>> > a
>> >
>> > number of computer science courses covering software engineering, object
>> >
>> > oriented design and high performance programming.
>> >
>> >
>> >
>> > I also have an interest in open source collaboration and, when time has
>> > allowed,
>> >
>> > have contributed to a few projects via github (@peterbell10). The
>> majority
>> > of
>> >
>> > my contributions have been to a minecraft server which I've been
>> > contributing to
>> >
>> > since summer 2017. You can see my pull requests here:
>> >
>> >
>> >
>> https://github.com/cuberite/cuberite/pulls?q=is%3Apr+is%3Amerged+author%3Apeterbell10
>> >
>> >
>> >
>> > Questions about the projects
>> >
>> > -----------------------------
>> >
>> > I have some questions regarding both of the proposed projects.
>> >
>> >
>> >
>> > Revamp fftpack:
>> >
>> > * Is the primary intention to keep the scipy.fftpack interface the same,
>> > but add
>> >
>> >   some mechanism to inject custom implementations? Or will this require
>> > changes
>> >
>> >   to the front-facing interface as well? (e.g. for agreement with
>> > numpy.fft)
>> >
>> > * What should this look like from the user's point of view? e.g.
>> >
>> >
>> >
>> >        import scipy.fftpack
>> >
>> >        import pyFFTW.interfaces.scipy_fftpack as fftw_pack
>> >
>> >
>> >
>> >        scipy.fftpack.set_backend(fftw_pack)
>> >
>> >
>> >
>> >   where we just provide a module implementing a well-documented backend
>> >
>> >   interface. Alternatively, fftw_pack could be an object, potentially
>> with
>> >
>> >   its own instances of caches and settings which might allow for more
>> >
>> >   configuration from the user.
>> >
>> >
>> >
>> > Improve ODE solvers (mainly the first 3 tasks):
>> >
>> > * How much mathematical background is required? I have done a course
>> > covering
>> >
>> >   the mathematics of ODE schemes including RK methods and some variable
>> > timestep
>> >
>> >   methods, but am not familiar with control theory which is mentioned
>> for
>> > the
>> >
>> >   3rd task.
>> >
>> > * Will developing the test set just involve binding existing
>> > implementations to
>> >
>> >   python for use in a testing framework, or do you expect these to be
>> > rewritten
>> >
>> >   entirely in python or cython?
>> >
>> >
>> >
>> >
>> >
>> > Best regards,
>> >
>> > Peter
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190404/484e79ff/attachment.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>>
>> ------------------------------
>>
>> End of SciPy-Dev Digest, Vol 186, Issue 10
>> ******************************************
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190414/27e0f9c3/attachment-0001.html>

From haberland at ucla.edu  Sun Apr 14 20:40:46 2019
From: haberland at ucla.edu (Matt Haberland)
Date: Sun, 14 Apr 2019 17:40:46 -0700
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CAEqRcW27eWa_ypS9wU-2UXuQ7mZDCyhBpHzvWOpHDS2Aza19Nw@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
 <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
 <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>
 <CAEqRcW27eWa_ypS9wU-2UXuQ7mZDCyhBpHzvWOpHDS2Aza19Nw@mail.gmail.com>
Message-ID: <CADuxUixwV-9G8-PaLnL+M=TSsyE7_nPWMTdGe+k34pXN=tHm5w@mail.gmail.com>

I'd like to get #10026 in there, too. SuiteSparse seems to routinely speed
up `linprog` by a factor of 2-4 (when available).

On Sun, Apr 14, 2019 at 7:40 AM Mark Alexander Mikofski <
mikofski at berkeley.edu> wrote:

> Hi Tyler,
>
> Thanks for managing the release again! This is a very important service
> for the SciPy community, and I'm very grateful!
>
> Do you think we could try to add #9568 and #10052 assuming everyone agrees
> they are good?
>
> thanks again!
> Mark
>
> On Sun, Apr 14, 2019 at 2:13 AM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>>
>>
>> On Sun, Apr 14, 2019 at 12:27 AM Andrew Nelson <andyfaff at gmail.com>
>> wrote:
>>
>>> Would it be possible to add 9990 and 10002 to 1.3.0, or is that too
>>> ambitious?
>>>
>>
>> Those look like they're in good shape, should be doable. I've added them
>> to the milestone. Tyler can always remove them again if we run out of time.
>>
>>
>>> On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <tyler.je.reddy at gmail.com>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> It is almost 4 months after the (slightly-delayed) 1.2.0 release on
>>>> December 17/ 2018, so probably time to plan the 1.3.0 release. It would be
>>>> a good idea to look over the PRs with a 1.3.0 milestone, and tag anything
>>>> else that should have this milestone appropriately.
>>>>
>>>> I'd like to propose the following schedule:
>>>>
>>>> April 25: branch 1.3.x
>>>> April 28: rc1
>>>> May 11: rc2 (if needed)
>>>> May 20: final release
>>>>
>>>> Thoughts?
>>>>
>>>
>> That works for me. There may be a few items in
>> https://github.com/scipy/scipy/milestone/37 that we won't get to, but
>> the only real blocker (py37 build issue) on that list is ready to merge.
>>
>> Cheers,
>> Ralf
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>
>
> --
> Mark Mikofski, PhD (2005)
> *Fiat Lux*
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>


-- 
Matt Haberland
Assistant Adjunct Professor in the Program in Computing
Department of Mathematics
6617A Math Sciences Building, UCLA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190414/7c720833/attachment.html>

From f20170920 at goa.bits-pilani.ac.in  Mon Apr 15 16:13:29 2019
From: f20170920 at goa.bits-pilani.ac.in (Anany Shrey Jain)
Date: Tue, 16 Apr 2019 01:43:29 +0530
Subject: [SciPy-Dev] GSoC 2019: Project Revamp `scipy.fftpack`
In-Reply-To: <CAG7QgjiDixsvV4ePV1NJVf7NGy_SR9Nn5pAp-a8RcrQnimmhWQ@mail.gmail.com>
References: <mailman.50.1554702855.2981.scipy-dev@python.org>
 <CAG7QgjiDixsvV4ePV1NJVf7NGy_SR9Nn5pAp-a8RcrQnimmhWQ@mail.gmail.com>
Message-ID: <CAG7QgjhQ1Y+tNhpWSoqdX5vjQHLvL_1dKZFwRZvb8dtNLbCZSw@mail.gmail.com>

Hey,

I was planning to start some work on the initial interface, but before that
I need to discuss a few things:

1) From the previous discussions it seems like instead of taking the values
of additional arguments from user, we will pass some default values of
those arguments to the backend library. Will it be better to implement a
method `set_args` to change the default value of these  arguments?
Here is the basic implementation:
https://github.com/ananyashreyjain/Gsoc-Scipy/blob/master/backend.py

2) Apart from having a environment variable for storing the backend library
can we also have one more environment variable that can have the optional
config file, in-case user wants to change the values of default arguments?

3) Are there any better ideas to get the values of additional arguments
from user? Or should we just focus on setting them up with default values?

Minor thing: Due to cancellation of a humanities course, my exams will now
end on 11th May instead of 15th (I mentioned it in my proposal), so now I
will have more time for API related discussions in the community bonding
period.

- Anany


 On Tue, Apr 9, 2019 at 7:28 AM Anany Shrey Jain <
f20170920 at goa.bits-pilani.ac.in> wrote:

> Hey,
> Thanks Greg for going through my proposal. I appreciate the way you went
> through every small detail .
>
> It will be very difficult for me to make changes in the implementation
> details now. Moreover the API will be changed a lot after the discussions
> with other developers, so for now, it will be better to stick with the
> current API .
>
> Except the API I have incorporated all the suggestions. The week 5 was
> left intentionally as a buffer during the phase 1 evaluations (I admit that
> I should have mentioned that in my proposal) .
> Nothing special was planned for mkl_fft, I just thought there might be
> need of some conversions lsubroutines ike this :
> https://github.com/pyFFTW/pyFFTW/blob/e9966e5d215a00f89156bd88e1d42b884f85df78/pyfftw/interfaces/scipy_fftpack.py#L227
> . But after seeing the Mkl code base again I don't think it will be
> required.
>
> Luckily, I have that kind of GPU (Cuda 9.1) but still it will be very
> difficult to reach to a common point and get things merged in CuPy. So I
> have removed the text about it, during the mentioned week, from my proposal.
>
> Here is the link to my proposal:
> https://docs.google.com/document/d/1TIiH9j3rPAN--53MwjZz7NFO1GGtxmEH3RiGzvqnEBk/edit#
>
> -Anany
>
>
> Date: Mon, 8 Apr 2019 01:54:00 -0400
>> From: Gregory Lee <grlee77 at gmail.com>
>> To: SciPy Developers List <scipy-dev at python.org>
>> Subject: Re: [SciPy-Dev] GSoC 2019: Project Proposal
>> Message-ID:
>>         <
>> CAJR3sXdxc-3EHBMXHwtT4_5pVM-J2Lb9_FV1y8v1fBs9J3iC3w at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Sat, Apr 6, 2019 at 5:08 PM Anany Shrey Jain <
>> f20170920 at goa.bits-pilani.ac.in> wrote:
>>
>> >
>> > Hey ,
>> > Thanks Greg for a detailed reply. I will be working on both
>> > https://github.com/pyFFTW/pyFFTW/pull/256 and
>> > https://github.com/cupy/cupy/issues/1936 as a part of this project. I
>> > have constructed my API implementation based on the `set_backend`
>> function
>> > approach, but in comparatively cleaner way. I have written my proposal
>> for
>> > this project and here is a link to it:
>> >
>> https://docs.google.com/document/d/1TIiH9j3rPAN--53MwjZz7NFO1GGtxmEH3RiGzvqnEBk/edit?usp=sharing
>> .
>> > Please go through my proposal and if possible send some feedback on it.
>> >
>> > -Anany
>> >
>> >
>> Hi Anany,
>>
>> I appreciate that you have narrowed down some of the possibilities. The
>> API
>> will need further refinement to reach consensus, but the general concept
>> as
>> presented seems reasonable and I don't think we have to reach consensus on
>> the finer implementation details for purposes of the proposal. I am not
>> sure it is necessary to have the `set_backend` function return a class
>> that
>> allows setting additional arguments. Ralf's made a comment earlier that
>> was
>> in favor of just supporting the arguments currently present in SciPy's
>> fftpack. I was also thinking something a bit simpler in terms of just
>> reading the name of the backend from a configuration file or environment
>> variable as opposed to running a full configuration script, but others may
>> disagree.
>>
>> I will comment mainly on the timeline section of the proposal as we did
>> not
>> discuss that previously:
>>
>> I think the timeline is a bit overly optimistic and dedicates too much
>> time
>> to third party libraries. It is probably not realistically going to be
>> possible to complete changes to SciPy as well as pyFFTW, mkl_fft and CuPy.
>> I would focus the majority of the timeline on SciPy itself. You can leave
>> the text about working on the pyFFTW and CuPy issues as goals for weeks
>> 9-12, but I think all work in the early weeks should be in SciPy itself
>> and
>> not require any changes to the third-party libraries in order for the
>> backend code to function. Each of the third party libraries already has a
>> substantial portion of the SciPy API implemented and can usefully be
>> integrated as backends as-is.
>>
>> I think you can keep the plan to implement an initial interface and pyFFTW
>> support in weeks 1-2, but I think week 3-4 should be primarily along the
>> lines of improving and revising the initial interface based on reviewer
>> feedback from your first PR. Realistically, it will take a substantial
>> amount of time to reach agreement among all parties and code will not be
>> merged right away. I would focus weeks 3-4 on revising based on feedback
>> rather than proposing to "make CuPy compatible". CuPy already has
>> compatible interfaces for many of the functions (
>> https://github.com/cupy/cupy/blob/master/cupyx/scipy/fftpack/fft.py).
>>
>> Week 5 seems to be missing from the timeline?
>>
>
> The week 5 was left intentionally as a buffer during the phase 1
> evaluations (I admit that I should have mentioned that in my proposal) .
>
>>
>> I would remove the item about adding changes to mkl_fft (in week 6). Was
>> there something specific you had in mind for that?
>
>
> Nothing special was planned for mkl_fft, I just thought there might be
> need of some conversions like this :
> https://github.com/pyFFTW/pyFFTW/blob/e9966e5d215a00f89156bd88e1d42b884f85df78/pyfftw/interfaces/scipy_fftpack.py#L227
> . But after seeing the Mkl codebase again I don't think it will be
> required.
>
> There are already
>> existing wrappers (
>> https://github.com/IntelPython/mkl_fft/blob/master/mkl_fft/_scipy_fft.py)
>> and I'm not sure there is much more to do there.  A suitable replacement
>> for the week 5-6 section of the timeline could be working on the SciPy
>> user
>> documentation detailing how to use and configure the backends. It could be
>> considered to potentially make small PRs to third party library
>> documentation as well, mentioning how scipy can be configured to use them
>> as its default backend. For instance, the new backend-based approach will
>> be preferable to the monkey patching currently discussed in the pyFFTW
>> docs.
>>
>> I proposed above to remove mention of CuPy from weeks 3-4 to reduce the
>> overall proportion of time in the proposal that is related to CuPy for a
>> couple of reasons:
>>
>> 1.) There is no existing precedent for interfacing with GPU code from
>> SciPy
>> so that may be a little controversial among the larger group of SciPy
>> developers and have a harder time of getting merged. If we assume NumPy
>> inputs should give NumPy outputs then the required host/device memory
>> transfers will reduce performance, making the GPU-based approach only
>> beneficial for large transforms. We could allow GPU-based input/output,
>> but
>> other functions in SciPy itself do not support GPU-based arrays.
>>
>> 2.) Using CuPy requires access to a relatively recent (~last five years or
>> so) NVidia GPU that supports CUDA (I think at least CUDA 8.0 is required).
>> Do you have access to an appropriate GPU?
>
>
> Luckily I have that kind of GPU (Cuda 9.1) but still it will be very
> difficult to reach to a common point and get things merged in CuPy. So I
> have removed the text about it from my proposal.
>
> There is no requirement for
>> applicants to have access to such hardware, but it will difficult to
>> propose making contributions to CuPy itself without it. We may be able to
>> work out remote access to a machine that has appropriate hardware, but I
>> have not looked into specifics of how we would arrange that yet and cannot
>> guarantee it.
>>
>>
>>
>>
>> Message: 1
>> > Date: Fri, 5 Apr 2019 12:13:15 -0400
>> > From: Gregory Lee <grlee77 at gmail.com>
>> > To: SciPy Developers List <scipy-dev at python.org>
>> > Subject: Re: [SciPy-Dev] GSoC 2019
>> > Message-ID:
>> >         <
>> > CAJR3sXeVPAB+jGB_EdxiDg45jbR4wHzLVjjBk7+RiesT0XMrpw at mail.gmail.com>
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> > On Fri, Apr 5, 2019 at 4:25 AM Anany Shrey Jain <
>> > f20170920 at goa.bits-pilani.ac.in> wrote:
>> >
>> > > Hey Greg,
>> > > The project "Revamp FFTPACK" also aims at contributing to third party
>> > > libraries to fill in functionality gaps. For pyFFTW I can see that
>> work
>> > on
>> > > adding Real-to-Real transforms has been going on for a long time. So
>> do I
>> > > need to continue the work going on in
>> > > https://github.com/pyFFTW/pyFFTW/pull/256 as a part of this project?
>> > >
>> >
>> > It is not a requirement that you work on the pyFFTW wrappers, but that
>> > would be a good complement to this project. Here are some thoughts.
>> >
>> > 1.) I would first have a mechanism to fall back to the existing
>> > scipy.fftpack implementations for any functions not currently supported
>> by
>> > a given backend. pyFFTW currently already falls back to scipy's own
>> > implementation for DCT and DST transforms (
>> >
>> >
>> https://github.com/pyFFTW/pyFFTW/blob/e9966e5d215a00f89156bd88e1d42b884f85df78/pyfftw/interfaces/scipy_fftpack.py#L81-L82
>> > ).
>> > The PR you referenced would allow it to use FFTW to perform these
>> > transforms instead and there would be no remaining functions that fall
>> back
>> > to scipy.fftpack.
>> >
>> > 2.) You can work on adding real-to-real support in supporting libraries,
>> > but this is a secondary goal to pursue once the SciPy side of the
>> project
>> > has been completed.
>> >    pyFFTW builds on FFTW which does already have functions providing
>> > real-to-real transforms. So what you see in the PR referenced above is
>> > mainly adding the wrappers for those to pyFFTW.
>> >
>> >
>> >
>> > > What needs to be done for the other two libraries? Do I need to make a
>> > > similar PR to other two libraries as well?
>> > >
>> > >
>> > You could potentially try that, but I think that is more of a stretch
>> goal.
>> > The approach for CuPy or mkl-fft would have to be different, because for
>> > those two cases the underlying libraries DO NOT have dedicated functions
>> > implementing the real-to-real transforms. Also, the underlying FFT
>> > libraries are proprietary, so we cannot propose to add new transforms on
>> > the C/C++ side. However, it is possible in principle to implement
>> > real-to-real transforms using only the already existing complex-valued
>> > transforms (albeit at some additional computational/memory cost). Some
>> > detailed examples of this are given in the following thread on DSP
>> > StackExchange:
>> >
>> https://dsp.stackexchange.com/questions/2807/fast-cosine-transform-via-fft
>> >
>> > I think that is probably the only feasible route for real-to-real
>> > transforms using those two backends. I think whether or not this type of
>> > implementation would give a performance benefit over just reusing the
>> > existing scipy.fftpack implementations is unknown.
>> >
>> > One FFT-related issues that could be improved in CuPy in a more
>> > straightforward manner than adding real-to-real support, is improving
>> the
>> > real-to-complex and complex-to-real support.  These transforms are
>> > supported by the underlying CUFFT library, but support for this within
>> CuPy
>> > is incomplete.  One issue related to this was opened at (
>> > https://github.com/cupy/cupy/issues/1936), but no PR implementing it
>> has
>> > been made.
>> >
>> >
>> > > For all the three libraries there are SciPy-compatable routines
>> already
>> > > defined. After getting required information using the newly created
>> > > interface I need to use them at the backend, right?
>> > >
>> >
>> > Yes, you should rely on the already existing interfaces when
>> implementing
>> > the backends in SciPy. Any additional 3rd party libraries would have to
>> > provide a scipy-like interface in order to be compatible for use as a
>> > backend.
>> >
>> >
>> >
>> > >
>> > > -Anany
>> > >
>> > >>
>> ----------------------------------------------------------------------
>> > >>
>> > >> Message: 1
>> > >> Date: Thu, 4 Apr 2019 10:58:27 -0400
>> > >> From: Gregory Lee <grlee77 at gmail.com>
>> > >> To: SciPy Developers List <scipy-dev at python.org>
>> > >> Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 185, Issue 18
>> > >> Message-ID:
>> > >>         <
>> > >> CAJR3sXcJuqQJrDboN5zH-pd7NG-wD8EWCdTCAtQ+vJpnZjKsRw at mail.gmail.com>
>> > >> Content-Type: text/plain; charset="utf-8"
>> > >>
>> > >> Hi Anany,
>> > >>
>> > >> It is nice to see that you have updated with multiple potential APIs.
>> > Can
>> > >> some other core SciPy devs also help give feedback on what SciPy
>> would
>> > >> find
>> > >> preferable? Out of the four you proposed, I think something along the
>> > >> lines
>> > >> of the second method is cleanest in terms of setting the backend at
>> > >> runtime. I think having some aspect from your 4th variant where the
>> > >> default
>> > >> backend can be read from a configuration file and/or environment
>> > variable
>> > >> is also desirable so that the user's desired default can always be
>> > >> automatically set at import time.
>> > >>
>> > >> I disagree with the following specific statement, though:
>> > >> "It is better to use all the above mentioned ideas because every idea
>> > has
>> > >> its own benefits besides it gives user the luxury to choose the
>> method
>> > >> implementation of backend."
>> > >>
>> > >> I do not think we want to provide multiple ways to do the same
>> thing. It
>> > >> can be confusing to users and more work for devs to maintain. I think
>> > >> there
>> > >> should be one method of setting the backend that the user can either
>> > call
>> > >> at run time or have it be automatically called based on some sort of
>> > >> configuration file and/or environment variable(s) at import time.
>> > >>
>> > >> - Greg
>> > >>
>> > >>
>> > >> On Tue, Apr 2, 2019 at 2:19 PM Anany Shrey Jain <
>> > >> f20170920 at goa.bits-pilani.ac.in> wrote:
>> > >>
>> > >> > Hey,
>> > >> > I have already sent the link to the page containing the list of
>> ideas
>> > >> for
>> > >> > implementation of new API that I propose for this project. Would
>> you
>> > >> like
>> > >> > to add something to it or give some comments on it? The Gsoc
>> proposal
>> > >> > deadline is 9th of April and I am planning to put all of this in my
>> > >> > proposal to make it effective . So any more ideas or comments will
>> be
>> > >> > really helpful for me . Here is the link to the page:
>> > >> >
>> https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy .
>> > >> >
>> > >> > On Sun, Mar 31, 2019 at 5:23 AM <scipy-dev-request at python.org>
>> wrote:
>> > >> >
>> > >> >>
>> > >> >> Message: 1
>> > >> >> Date: Sat, 30 Mar 2019 13:31:51 -0400
>> > >> >> From: Eric Larson <larson.eric.d at gmail.com>
>> > >> >> To: SciPy Developers List <scipy-dev at python.org>
>> > >> >> Subject: Re: [SciPy-Dev] GSoC 2019
>> > >> >> Message-ID:
>> > >> >>         <
>> > >> >>
>> CAGu2niVWsKrMukfWcAWAtj-1NBm2utCeh3BOnNku7jNoAcx-kw at mail.gmail.com>
>> > >> >> Content-Type: text/plain; charset="utf-8"
>> > >> >>
>> > >> >> It looks like the main ideas are in these bits of code, but not
>> > >> explicitly
>> > >> >> stated. In brief it looks like the proposed API is to add a
>> > >> `fft_object`
>> > >> >> kwarg to every function in `scipy.fftpack`. It would be good to
>> > discuss
>> > >> >> this choice explicitly -- what advantages and disadvantages it has
>> > >> >> relative
>> > >> >> to other approaches (e.g., creating new namespaces, or having a
>> > >> >> `set_backend` function (and/or context manager) that would change
>> > >> things
>> > >> >> under the hood).
>> > >> >>
>> > >> >> If you make changes and need more feedback, let us know. The more
>> > >> specific
>> > >> >> you can be about what you need feedback on (high level ideas, low
>> > level
>> > >> >> implementation, etc.), the better.
>> > >> >>
>> > >> >> Eric
>> > >> >>
>> > >> >>
>> > >> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
>> > >> >> f20170920 at goa.bits-pilani.ac.in> wrote:
>> > >> >>
>> > >> >> > Hey,
>> > >> >> > I went through the idea list of Scipy for this years's GSoC and
>> I
>> > >> intend
>> > >> >> > to work towards the idea of revamping the Scipy's fftpack. I
>> have
>> > >> >> already
>> > >> >> > been contributing to Scipy since the end of last year and I have
>> > some
>> > >> >> > knowledge about Fourier transforms as it was the part of my
>> > >> discipline.
>> > >> >> I
>> > >> >> > could not take part in this discussion earlier because my mid
>> > >> semester
>> > >> >> > exams were going on, but since they are now over so I can
>> devote as
>> > >> much
>> > >> >> > time as required on this project. I have already created a
>> github
>> > >> page
>> > >> >> with
>> > >> >> > some code snippets and functionalities that we can implement,
>> here
>> > is
>> > >> >> the
>> > >> >> > link to it:
>> > >> >> >
>> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
>> > >> .
>> > >> >> >
>> > >> >> > Cheers,
>> > >> >> > Anany Jain
>> > >> >> >
>> > >> >> > _______________________________________________
>> > >> >> > SciPy-Dev mailing list
>> > >> >> > SciPy-Dev at python.org
>> > >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >
>> > >> >> -------------- next part --------------
>> > >> >> An HTML attachment was scrubbed...
>> > >> >> URL: <
>> > >> >>
>> > >>
>> >
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/f1755dfb/attachment-0001.html
>> > >> >> >
>> > >> >>
>> > >> >> ------------------------------
>> > >> >>
>> > >> >> Message: 2
>> > >> >> Date: Sat, 30 Mar 2019 19:38:41 -0400
>> > >> >> From: Gregory Lee <grlee77 at gmail.com>
>> > >> >> To: SciPy Developers List <scipy-dev at python.org>
>> > >> >> Subject: Re: [SciPy-Dev] GSoC 2019
>> > >> >> Message-ID:
>> > >> >>         <CAJR3sXfnnr-0JO87gLbhh-7b-w=KjaNpac+F+FHTeFt2K=_
>> > >> >> QMw at mail.gmail.com>
>> > >> >> Content-Type: text/plain; charset="utf-8"
>> > >> >>
>> > >> >> On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain <
>> > >> >> f20170920 at goa.bits-pilani.ac.in> wrote:
>> > >> >>
>> > >> >> > Hey,
>> > >> >> > I went through the idea list of Scipy for this years's GSoC and
>> I
>> > >> intend
>> > >> >> > to work towards the idea of revamping the Scipy's fftpack. I
>> have
>> > >> >> already
>> > >> >> > been contributing to Scipy since the end of last year and I have
>> > some
>> > >> >> > knowledge about Fourier transforms as it was the part of my
>> > >> discipline.
>> > >> >> I
>> > >> >> > could not take part in this discussion earlier because my mid
>> > >> semester
>> > >> >> > exams were going on, but since they are now over so I can
>> devote as
>> > >> much
>> > >> >> > time as required on this project. I have already created a
>> github
>> > >> page
>> > >> >> with
>> > >> >> > some code snippets and functionalities that we can implement,
>> here
>> > is
>> > >> >> the
>> > >> >> > link to it:
>> > >> >> >
>> > https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy
>> > >> .
>> > >> >> >
>> > >> >> > Cheers,
>> > >> >> > Anany Jain
>> > >> >> >
>> > >> >> > _______________________________________________
>> > >> >> > SciPy-Dev mailing list
>> > >> >> > SciPy-Dev at python.org
>> > >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >>
>> > >> >>
>> > >> >> Hi Anany,
>> > >> >>
>> > >> >> Thank you for your interest in GSOC with SciPy!  It's great to see
>> > that
>> > >> >> you
>> > >> >> are already thinking about a potential API and learning about the
>> 3rd
>> > >> >> party
>> > >> >> FFT libraries. Along the lines of Eric's comment, think about what
>> > this
>> > >> >> API
>> > >> >> choice implies for users of libraries built upon SciPy. Would
>> users
>> > of
>> > >> 3rd
>> > >> >> party libraries that rely on SciPy's FFTs be immediately able to
>> take
>> > >> >> advantage of a differentf FFT backend in this scenario? (in other
>> > >> words,
>> > >> >> the case where the user is not calling scipy.fftpack.fft directly
>> but
>> > >> is
>> > >> >> using it only indirectly via a function in a downstream library).
>> > >> >>
>> > >> >> Matplotlib is an example of an existing Python library supporting
>> > >> multiple
>> > >> >> backends that can be considered for comparison (see:
>> > >> >> https://matplotlib.org/faq/usage_faq.html#what-is-a-backend).
>> Think
>> > >> about
>> > >> >> the relative benefits/drawbacks of some of the methods they use
>> for
>> > >> >> setting
>> > >> >> a backend there as compared to the approach proposed for FFTs
>> here.
>> > >> >>
>> > >> >> Another thing that should be considered: pyFFTW, MKL and CuPy
>> already
>> > >> have
>> > >> >> some functions that match the existing scipy.fftpack API, but they
>> > may
>> > >> >> have
>> > >> >> one or more additional arguments particular to features of that
>> > >> library.
>> > >> >> How would you propose to deal with supporting additional optional
>> > >> >> arguments
>> > >> >> on the SciPy end?
>> > >> >>
>> > >> >> One other minor comment: I know that the blog post you made may be
>> > >> serving
>> > >> >> partly as personal notes, but please do not directly copy
>> sections of
>> > >> text
>> > >> >> (e.g. the description of BLAS/LAPACK libraries) from elsewhere
>> > without
>> > >> >> attribution when writing a final proposal. (Also, the FFT
>> functions
>> > are
>> > >> >> separate from the BLAS/LAPACK functions in MKL, so you will not
>> need
>> > to
>> > >> >> discuss BLAS or LAPACK specifically in your proposal)
>> > >> >>
>> > >> >> - Greg
>> > >> >> -------------- next part --------------
>> > >> >> An HTML attachment was scrubbed...
>> > >> >> URL: <
>> > >> >>
>> > >>
>> >
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/c1351e7e/attachment-0001.html
>> > >> >> >
>> > >> >>
>> > >> >> ------------------------------
>> > >> >>
>> > >> >> Message: 3
>> > >> >> Date: Sat, 30 Mar 2019 19:53:02 -0400
>> > >> >> From: Gregory Lee <grlee77 at gmail.com>
>> > >> >> To: SciPy Developers List <scipy-dev at python.org>
>> > >> >> Subject: Re: [SciPy-Dev] GSoC 2019
>> > >> >> Message-ID:
>> > >> >>         <CAJR3sXdcPMAn_DETF8W-=
>> > >> >> MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw at mail.gmail.com>
>> > >> >> Content-Type: text/plain; charset="utf-8"
>> > >> >>
>> > >> >> Hi Gopi,
>> > >> >>
>> > >> >> I am not sure I follow exactly what you are suggesting here. Are
>> you
>> > >> >> proposing that the `fftpackN` variable in your example would be a
>> > >> Python
>> > >> >> module corresponding to a given backend? If so, why is an array of
>> > >> data,
>> > >> >> z,
>> > >> >> being passed into the newAPI function here? I don't see why a data
>> > >> array
>> > >> >> should be needed at all to choose a backend.
>> > >> >>
>> > >> >> Please also see my response to Anany's recent post on this list
>> for a
>> > >> >> couple of other suggestions of things to consider in terms of the
>> > API.
>> > >> >>
>> > >> >> - Greg
>> > >> >>
>> > >> >>
>> > >> >> On Fri, Mar 29, 2019 at 5:27 AM Gopi Manohar Tatiraju <
>> > >> >> deathcoderx at gmail.com>
>> > >> >> wrote:
>> > >> >>
>> > >> >> > Hey,
>> > >> >> > I went through the code and got some ideas.
>> > >> >> > So what will happen is:
>> > >> >> > First, we will declare FFTW as we use them normally.
>> > >> >> >
>> > >> >> > z = np.random.rand(2, 128, 64)
>> > >> >> > pyfftw.FFTW(z, axes=(-1, ))
>> > >> >> > ..
>> > >> >> > ..
>> > >> >> > Now after declaring our basic work to shift to another FFTpack,
>> > what
>> > >> we
>> > >> >> > can do is:
>> > >> >> > fftPackN= newAPI(z, pack = 'PYFFTW');
>> > >> >> >
>> > >> >> > Pack will take the name of the 3rd party FFT pack which we want
>> to
>> > >> use.
>> > >> >> > Suggestions needed.
>> > >> >> >
>> > >> >> > Cheers.
>> > >> >> >
>> > >> >> >
>> > >> >>
>> > >> >> >
>> > >> >> > On Wed, Mar 27, 2019 at 8:43 PM Eric Larson <
>> > larson.eric.d at gmail.com
>> > >> >
>> > >> >> > wrote:
>> > >> >> >
>> > >> >> >> After reading the related issues and thinking about the
>> problem,
>> > >> >> perhaps
>> > >> >> >> the best first step is you come up with some initial API
>> proposal.
>> > >> >> >>
>> > >> >> >> One way to work through the process is to think about the use
>> > cases
>> > >> >> that
>> > >> >> >> we want to support. How should users actually write code to use
>> > the
>> > >> new
>> > >> >> >> functionality? You can start with short code snippets that do
>> not
>> > >> work
>> > >> >> >> currently, but should work for users at the end of the project.
>> > Then
>> > >> >> think
>> > >> >> >> about what needs to change inside SciPy for these code
>> snippets to
>> > >> >> work.
>> > >> >> >> This can become an iterative process as you realize that the
>> SciPy
>> > >> >> changes
>> > >> >> >> might be better or easier with changes to the user-facing API,
>> > etc.
>> > >> >> >>
>> > >> >> >> Eric
>> > >> >> >>
>> > >> >> >>
>> > >> >> >> On Tue, Mar 26, 2019 at 3:38 PM Gopi Manohar Tatiraju <
>> > >> >> >> deathcoderx at gmail.com> wrote:
>> > >> >> >>
>> > >> >> >>> Hey,
>> > >> >> >>> As proposal submission period started I want to discuss a bit
>> > anobt
>> > >> >> how
>> > >> >> >>> can we implement the API.
>> > >> >> >>> I would very much appriciate inputs and guidance.
>> > >> >> >>>
>> > >> >> >>> Cheers.
>> > >> >> >>>
>> > >> >> >>> On Thu, Mar 7, 2019 at 11:40 PM Eric Larson <
>> > >> larson.eric.d at gmail.com>
>> > >> >> >>> wrote:
>> > >> >> >>>
>> > >> >> >>>> The best way to figure that out is probably to take a look at
>> > >> some of
>> > >> >> >>>> the existing (minor) SciPy GitHub issues and try to work on
>> one
>> > or
>> > >> >> two that
>> > >> >> >>>> you feel like working on. Actually trying to work out how to
>> > >> >> contribute
>> > >> >> >>>> code changes (as independently as possible/reasonable based
>> on
>> > the
>> > >> >> existing
>> > >> >> >>>> guides/docs already discoverable online) will quickly
>> highlight
>> > >> >> things that
>> > >> >> >>>> need to be learned. Some of the general things are the SciPy
>> > >> >> contributing
>> > >> >> >>>> guidelines, standard GitHub PR workflow, communication with
>> > >> >> reviewers, and
>> > >> >> >>>> so forth.
>> > >> >> >>>>
>> > >> >> >>>> For this particular project, it's important to understand the
>> > >> various
>> > >> >> >>>> flavors and properties of FFT in SciPy (real, complex,
>> > >> n-dimensional,
>> > >> >> >>>> caching plans, etc.) as well as other projects like NumPy,
>> CuPy,
>> > >> and
>> > >> >> >>>> pyFFTW. Some of this can be learned and improved upon as
>> part of
>> > >> >> GSoC, but
>> > >> >> >>>> the more you know and can demonstrate / put into practice
>> > >> knowledge
>> > >> >> of
>> > >> >> >>>> before the applications are reviewed, the better.
>> > >> >> >>>>
>> > >> >> >>>> Eric
>> > >> >> >>>>
>> > >> >> >>>>
>> > >> >> >>>> On Wed, Mar 6, 2019 at 4:55 AM Gopi Manohar Tatiraju <
>> > >> >> >>>> deathcoderx at gmail.com> wrote:
>> > >> >> >>>>
>> > >> >> >>>>> Thank you for the detailed reply.
>> > >> >> >>>>> I will keep these point in mind while preparing my proposal.
>> > >> Apart
>> > >> >> >>>>> from proposal, what skills shall I improve so that I can
>> > >> contribute
>> > >> >> more
>> > >> >> >>>>> effectively and efficiently.
>> > >> >> >>>>>
>> > >> >> >>>>> Cheers.
>> > >> >> >>>>>
>> > >> >> >>>>>
>> > >> >> >>>>> On Wed, Mar 6, 2019, 3:42 AM Eric Larson <
>> > >> larson.eric.d at gmail.com>
>> > >> >> >>>>> wrote:
>> > >> >> >>>>>
>> > >> >> >>>>>> There are a number of considerations that would be good to
>> > >> address.
>> > >> >> >>>>>> I'd start by considering the things that are typically
>> > >> considered
>> > >> >> >>>>>> when making changes to SciPy
>> > >> >> >>>>>> <
>> > >> >>
>> > >>
>> >
>> https://docs.scipy.org/doc/scipy/reference/hacking.html#contributing-to-scipy
>> > >> >> >,
>> > >> >> >>>>>> but I'd expand it to a longer list since the scope is
>> bigger
>> > >> than
>> > >> >> a typical
>> > >> >> >>>>>> single PR. The list would contain (at least):
>> > >> >> >>>>>>
>> > >> >> >>>>>> - what will the user-facing API / contract be?
>> > >> >> >>>>>> - what in SciPy needs to change to allow it (internals /
>> > >> >> >>>>>> implementation outline, perhaps skeleton
>> functions/classes)?
>> > >> >> >>>>>> - what examples should we show users (in general this ends
>> up
>> > >> being
>> > >> >> >>>>>> just simple use cases of the API)?
>> > >> >> >>>>>> - how will we test it for correctness?
>> > >> >> >>>>>> - how will we benchmark it to prevent performance
>> regressions?
>> > >> >> >>>>>> - how can we break up the work for these steps (if
>> possible)
>> > >> into
>> > >> >> >>>>>> separable, sequential (or -- better but not usually
>> possible
>> > --
>> > >> >> >>>>>> independent) PRs?
>> > >> >> >>>>>>
>> > >> >> >>>>>> You might notice that none of these points are actually all
>> > that
>> > >> >> >>>>>> specific to the FFT project, but can be generally
>> applicable
>> > to
>> > >> >> GSoC
>> > >> >> >>>>>> projects. For the FFT project, I would say "how do we build
>> > the
>> > >> >> backend" is
>> > >> >> >>>>>> indeed implicitly contained / outlined in these bullet
>> points.
>> > >> And
>> > >> >> as with
>> > >> >> >>>>>> most projects, the first two points (and possibly the last)
>> > will
>> > >> >> probably
>> > >> >> >>>>>> be the most challenging to sort out.
>> > >> >> >>>>>>
>> > >> >> >>>>>> Eric
>> > >> >> >>>>>>
>> > >> >> >>>>>>
>> > >> >> >>>>>> On Mon, Mar 4, 2019 at 10:09 PM Gopi Manohar Tatiraju <
>> > >> >> >>>>>> deathcoderx at gmail.com> wrote:
>> > >> >> >>>>>>
>> > >> >> >>>>>>> Hey Eric,
>> > >> >> >>>>>>> So for my proposal, shall I include how can we built a
>> back
>> > >> end?
>> > >> >> >>>>>>> What all points shall I include to make it effective?
>> > >> >> >>>>>>>
>> > >> >> >>>>>>> Cheers.
>> > >> >> >>>>>>>
>> > >> >> >>>>>>> On Tue, Mar 5, 2019, 4:50 AM Eric Larson <
>> > >> larson.eric.d at gmail.com
>> > >> >> >
>> > >> >> >>>>>>> wrote:
>> > >> >> >>>>>>>
>> > >> >> >>>>>>>> That would be me -- don't worry, I'm on this list, as are
>> > >> >> >>>>>>>> (presumably) other developers interested in the
>> discussion,
>> > so
>> > >> >> no need to
>> > >> >> >>>>>>>> document elsewhere for now from our end. It looks like
>> Greg
>> > >> has
>> > >> >> summarized
>> > >> >> >>>>>>>> the current status and thoughts we've had, so I don't
>> have
>> > >> much
>> > >> >> to add at
>> > >> >> >>>>>>>> this point.
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>> Eric
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>> On Sun, Mar 3, 2019 at 11:59 PM Gopi Manohar Tatiraju <
>> > >> >> >>>>>>>> deathcoderx at gmail.com> wrote:
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>>> Hey Greg,
>> > >> >> >>>>>>>>> I got the basic idea about what we want to implement
>> this
>> > >> year.
>> > >> >> >>>>>>>>> Our first priority is to create a backend for 3rd party
>> > >> >> fftpacks.
>> > >> >> >>>>>>>>> We can create API using Python and Flask or any other
>> > >> suitable
>> > >> >> framework.
>> > >> >> >>>>>>>>>
>> > >> >> >>>>>>>>> I thought this discussion was going on on SciPy
>> Developer
>> > >> List
>> > >> >> >>>>>>>>> only. So do I need to document it all and post it
>> somewhere
>> > >> so
>> > >> >> that other
>> > >> >> >>>>>>>>> contributors can see this?
>> > >> >> >>>>>>>>> Also, I couldn't find any contact info regarding Eric.
>> It
>> > >> would
>> > >> >> be
>> > >> >> >>>>>>>>> very helpful if we include him in this discussion as
>> this
>> > is
>> > >> a
>> > >> >> roadmap for
>> > >> >> >>>>>>>>> GSoC project and I can also get more insight into the
>> > project
>> > >> >> and expected
>> > >> >> >>>>>>>>> outcomes.
>> > >> >> >>>>>>>>>
>> > >> >> >>>>>>>>> Cheers.
>> > >> >> >>>>>>>>>
>> > >> >> >>>>>>>>> On Mon, Mar 4, 2019 at 9:31 AM Gregory Lee <
>> > >> grlee77 at gmail.com>
>> > >> >> >>>>>>>>> wrote:
>> > >> >> >>>>>>>>>
>> > >> >> >>>>>>>>>>
>> > >> >> >>>>>>>>>>
>> > >> >> >>>>>>>>>> On Sun, Mar 3, 2019 at 12:28 PM Gopi Manohar Tatiraju <
>> > >> >> >>>>>>>>>> deathcoderx at gmail.com> wrote:
>> > >> >> >>>>>>>>>>
>> > >> >> >>>>>>>>>>> Hey Gregory,
>> > >> >> >>>>>>>>>>> I went through the idea and I am very much interested
>> in
>> > >> >> working
>> > >> >> >>>>>>>>>>> on it. I had Fourier Transforms as a part of my
>> academic
>> > >> >> course, so I am
>> > >> >> >>>>>>>>>>> well aware with basic concepts.
>> > >> >> >>>>>>>>>>> One thing I want to discuss is, its mentioned that we
>> > have
>> > >> to
>> > >> >> >>>>>>>>>>> create a backend system for 3rd party FFTpacks so my
>> > dobuts
>> > >> >> >>>>>>>>>>>
>> > >> >> >>>>>>>>>>
>> > >> >> >>>>>>>>>>
>> > >> >> >>>>>>>>>>> 1. How are we going to create API?
>> > >> >> >>>>>>>>>>>
>> > >> >> >>>>>>>>>>
>> > >> >> >>>>>>>>>> This will needed to be decided on in consensus with the
>> > >> SciPy
>> > >> >> >>>>>>>>>> developers and user community. I am mentoring for the
>> > >> project
>> > >> >> as a
>> > >> >> >>>>>>>>>> contributor here and a maintainer of the related pyFFTW
>> > >> >> package, but I am
>> > >> >> >>>>>>>>>> not a core SciPy dev (the other mentor, Eric, is a core
>> > dev
>> > >> >> here). I have
>> > >> >> >>>>>>>>>> not discussed the API in any detail with the SciPy
>> team at
>> > >> >> this stage.
>> > >> >> >>>>>>>>>> Working out details of what the API should look like
>> and
>> > >> >> working to
>> > >> >> >>>>>>>>>> finalize that in collaboration with the community will
>> be
>> > a
>> > >> >> primary task
>> > >> >> >>>>>>>>>> during the early part of the GSOC project.
>> > >> >> >>>>>>>>>>
>> > >> >> >>>>>>>>>> 2. After the creation of backend will user at the time
>> of
>> > >> >> >>>>>>>>>>> installation of SciPy will decide what all 3rd party
>> > >> FFTpacks
>> > >> >> he needs or
>> > >> >> >>>>>>>>>>> we will include some by default?
>> > >> >> >>>>>>>>>>>
>> > >> >> >>>>>>>>>>> The idea is to allow users to opt-in to a different
>> FFT
>> > >> >> backend
>> > >> >> >>>>>>>>>> at run time, but these alternative libraries will not
>> be
>> > >> >> distributed with
>> > >> >> >>>>>>>>>> SciPy itself due to incompatible software licenses
>> (pyFFTW
>> > >> and
>> > >> >> mkl-fft) or
>> > >> >> >>>>>>>>>> a requirement for specific hardware (CuPy requires an
>> > NVIDIA
>> > >> >> GPU). SciPy
>> > >> >> >>>>>>>>>> will continue to offer its own bundled FFT library
>> > >> (currently
>> > >> >> fftpack, but
>> > >> >> >>>>>>>>>> this could be switched to pocketfft as discussed in the
>> > >> ideas
>> > >> >> page). The
>> > >> >> >>>>>>>>>> purpose of the backend interface is to provide a
>> > convenient
>> > >> >> way for users
>> > >> >> >>>>>>>>>> to have third party libraries perform the FFTs instead,
>> > but
>> > >> >> under the
>> > >> >> >>>>>>>>>> existing scipy.fftpack API. This is motivated by a
>> desire
>> > by
>> > >> >> end users and
>> > >> >> >>>>>>>>>> downstream projects to have features such as
>> > multi-threading
>> > >> >> (pyFFTW and
>> > >> >> >>>>>>>>>> mkl-fft) or GPU support (CuPy) that are not
>> implemented in
>> > >> >> scipy.fftpack.
>> > >> >> >>>>>>>>>> Ultimately it will be up to users that opt-in to using
>> > these
>> > >> >> other
>> > >> >> >>>>>>>>>> libraries to confirm that the license terms and are
>> > >> compatible
>> > >> >> with their
>> > >> >> >>>>>>>>>> use case.
>> > >> >> >>>>>>>>>>
>> > >> >> >>>>>>>>>> p.s. It is not a big deal, but I think the SciPy-Dev
>> > mailing
>> > >> >> >>>>>>>>>> lists prefers replies **below** the email you are
>> replying
>> > >> to
>> > >> >> so people can
>> > >> >> >>>>>>>>>> more easily follow the thread of discussion. There are
>> > some
>> > >> >> guidelines at:
>> > >> >> >>>>>>>>>> https://www.scipy.org/scipylib/mailing-lists.html
>> > >> >> >>>>>>>>>>
>> > >> >> >>>>>>>>>>
>> > >> >> >>>>>>>>>>
>> > >> >> >>>>>>>>>> I will research more about how to implement a backend
>> > myself
>> > >> >> and
>> > >> >> >>>>>>>>>>> will let you know as soon as I come up with something
>> > new.
>> > >> >> >>>>>>>>>>>
>> > >> >> >>>>>>>>>>>
>> > >> >> >>>>>>>>>> CHeers,
>> > >> >> >>>>>>>>>>> Greg
>> > >> >> >>>>>>>>>>>
>> > >> >> >>>>>>>>>>> On Sun, Mar 3, 2019 at 10:25 PM Gregory Lee <
>> > >> >> grlee77 at gmail.com>
>> > >> >> >>>>>>>>>>> wrote:
>> > >> >> >>>>>>>>>>>
>> > >> >> >>>>>>>>>>>> On Sun, Mar 3, 2019 at 4:19 AM Gopi Manohar Tatiraju
>> <
>> > >> >> >>>>>>>>>>>> deathcoderx at gmail.com> wrote:
>> > >> >> >>>>>>>>>>>>
>> > >> >> >>>>>>>>>>>>> I want to work on SciPy in GSoC 2019. I started
>> fixing
>> > >> some
>> > >> >> >>>>>>>>>>>>> bugs, also made some pull request. Can anyone
>> suggest
>> > me
>> > >> >> how should I
>> > >> >> >>>>>>>>>>>>> proceed further?
>> > >> >> >>>>>>>>>>>>> _______________________________________________
>> > >> >> >>>>>>>>>>>>> SciPy-Dev mailing list
>> > >> >> >>>>>>>>>>>>> SciPy-Dev at python.org
>> > >> >> >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >>>>>>>>>>>>
>> > >> >> >>>>>>>>>>>>
>> > >> >> >>>>>>>>>>>> Hi Gopi,
>> > >> >> >>>>>>>>>>>>
>> > >> >> >>>>>>>>>>>> I think you have probably already found it, but the
>> GSOC
>> > >> >> >>>>>>>>>>>> project we have already identified mentors for in
>> SciPy
>> > is
>> > >> >> here:
>> > >> >> >>>>>>>>>>>>
>> > >> https://github.com/scipy/scipy/wiki/GSoC-2019-project-ideas
>> > >> >> >>>>>>>>>>>>
>> > >> >> >>>>>>>>>>>> If this is a project you are interested in then I
>> would
>> > >> start
>> > >> >> >>>>>>>>>>>> thinking about what the FFT interface would look like
>> > and
>> > >> >> reviewing some of
>> > >> >> >>>>>>>>>>>> the past/present issues related to fftpack / FFT in
>> > SciPy.
>> > >> >> Please ask
>> > >> >> >>>>>>>>>>>> questions you have related to that project here so
>> that
>> > >> you
>> > >> >> can clarify
>> > >> >> >>>>>>>>>>>> what would be involved in writing a successful
>> > >> application.
>> > >> >> >>>>>>>>>>>>
>> > >> >> >>>>>>>>>>>> If you have a different idea in mind you can propose
>> it
>> > >> here,
>> > >> >> >>>>>>>>>>>> but you should do that soon, because it will be
>> > necessary
>> > >> to
>> > >> >> determine if
>> > >> >> >>>>>>>>>>>> there is interest from the SciPy team before you
>> spend
>> > >> time
>> > >> >> coming up with
>> > >> >> >>>>>>>>>>>> a detailed proposal. We have to determine if a
>> project
>> > >> >> sounds feasible to
>> > >> >> >>>>>>>>>>>> complete for GSOC and if appropriate mentors can be
>> > >> >> identified.
>> > >> >> >>>>>>>>>>>>
>> > >> >> >>>>>>>>>>>> Ultimately, you will need to submit an application to
>> > >> SciPy
>> > >> >> >>>>>>>>>>>> between March 25th - April 9th.
>> > >> >> >>>>>>>>>>>>
>> > >> >> >>>>>>>>>>>> Cheers,
>> > >> >> >>>>>>>>>>>> Greg
>> > >> >> >>>>>>>>>>>>
>> > >> >> >>>>>>>>>>>>
>> > >> >> >>>>>>>>>>>> _______________________________________________
>> > >> >> >>>>>>>>>>>> SciPy-Dev mailing list
>> > >> >> >>>>>>>>>>>> SciPy-Dev at python.org
>> > >> >> >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >>>>>>>>>>>>
>> > >> >> >>>>>>>>>>> _______________________________________________
>> > >> >> >>>>>>>>>>> SciPy-Dev mailing list
>> > >> >> >>>>>>>>>>> SciPy-Dev at python.org
>> > >> >> >>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >>>>>>>>>>>
>> > >> >> >>>>>>>>>> _______________________________________________
>> > >> >> >>>>>>>>>> SciPy-Dev mailing list
>> > >> >> >>>>>>>>>> SciPy-Dev at python.org
>> > >> >> >>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >>>>>>>>>>
>> > >> >> >>>>>>>>> _______________________________________________
>> > >> >> >>>>>>>>> SciPy-Dev mailing list
>> > >> >> >>>>>>>>> SciPy-Dev at python.org
>> > >> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >>>>>>>>>
>> > >> >> >>>>>>>> _______________________________________________
>> > >> >> >>>>>>>> SciPy-Dev mailing list
>> > >> >> >>>>>>>> SciPy-Dev at python.org
>> > >> >> >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>> _______________________________________________
>> > >> >> >>>>>>> SciPy-Dev mailing list
>> > >> >> >>>>>>> SciPy-Dev at python.org
>> > >> >> >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >>>>>>>
>> > >> >> >>>>>> _______________________________________________
>> > >> >> >>>>>> SciPy-Dev mailing list
>> > >> >> >>>>>> SciPy-Dev at python.org
>> > >> >> >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >>>>>>
>> > >> >> >>>>> _______________________________________________
>> > >> >> >>>>> SciPy-Dev mailing list
>> > >> >> >>>>> SciPy-Dev at python.org
>> > >> >> >>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >>>>>
>> > >> >> >>>> _______________________________________________
>> > >> >> >>>> SciPy-Dev mailing list
>> > >> >> >>>> SciPy-Dev at python.org
>> > >> >> >>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >>>>
>> > >> >> >>> _______________________________________________
>> > >> >> >>> SciPy-Dev mailing list
>> > >> >> >>> SciPy-Dev at python.org
>> > >> >> >>> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >>>
>> > >> >> >> _______________________________________________
>> > >> >> >> SciPy-Dev mailing list
>> > >> >> >> SciPy-Dev at python.org
>> > >> >> >> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >>
>> > >> >> > _______________________________________________
>> > >> >> > SciPy-Dev mailing list
>> > >> >> > SciPy-Dev at python.org
>> > >> >> > https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >> >
>> > >> >> -------------- next part --------------
>> > >> >> An HTML attachment was scrubbed...
>> > >> >> URL: <
>> > >> >>
>> > >>
>> >
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190330/54f38250/attachment.html
>> > >> >> >
>> > >> >>
>> > >> >> ------------------------------
>> > >> >>
>> > >> >> Subject: Digest Footer
>> > >> >>
>> > >> >> _______________________________________________
>> > >> >> SciPy-Dev mailing list
>> > >> >> SciPy-Dev at python.org
>> > >> >> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >>
>> > >> >>
>> > >> >> ------------------------------
>> > >> >>
>> > >> >> End of SciPy-Dev Digest, Vol 185, Issue 18
>> > >> >> ******************************************
>> > >> >>
>> > >> > _______________________________________________
>> > >> > SciPy-Dev mailing list
>> > >> > SciPy-Dev at python.org
>> > >> > https://mail.python.org/mailman/listinfo/scipy-dev
>> > >> >
>> > >> -------------- next part --------------
>> > >> An HTML attachment was scrubbed...
>> > >> URL: <
>> > >>
>> >
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190404/1a670020/attachment.html
>> > >> >
>> > >>
>> > >> ------------------------------
>> > >>
>> > >> Subject: Digest Footer
>> > >>
>> > >> _______________________________________________
>> > >> SciPy-Dev mailing list
>> > >> SciPy-Dev at python.org
>> > >> https://mail.python.org/mailman/listinfo/scipy-dev
>> > >>
>> > >>
>> > >> ------------------------------
>> > >>
>> > >> End of SciPy-Dev Digest, Vol 186, Issue 11
>> > >> ******************************************
>> > >>
>> > > _______________________________________________
>> > > SciPy-Dev mailing list
>> > > SciPy-Dev at python.org
>> > > https://mail.python.org/mailman/listinfo/scipy-dev
>> > >
>> > -------------- next part --------------
>> > An HTML attachment was scrubbed...
>> > URL: <
>> >
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190405/cc4019f5/attachment.html
>> > >
>> >
>> > ------------------------------
>> >
>> > Subject: Digest Footer
>> >
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >
>> >
>> > ------------------------------
>> >
>> > End of SciPy-Dev Digest, Vol 186, Issue 15
>> > ******************************************
>> >
>> _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/scipy-dev
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://mail.python.org/pipermail/scipy-dev/attachments/20190408/a59718a0/attachment.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>>
>> ------------------------------
>>
>> End of SciPy-Dev Digest, Vol 186, Issue 22
>> ******************************************
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190416/221d5bf8/attachment-0001.html>

From ilhanpolat at gmail.com  Tue Apr 16 03:13:05 2019
From: ilhanpolat at gmail.com (Ilhan Polat)
Date: Tue, 16 Apr 2019 09:13:05 +0200
Subject: [SciPy-Dev] pinv2 and pinvh cutoff accuracy
Message-ID: <CAEBuzr_LmAaOsyuv+pDK=qLdCLbCnZg3hOSD505oacyM=B=5AQ@mail.gmail.com>

Dear all,

In https://github.com/scipy/scipy/pull/10067 I proposed to change the
default cutoff values for pinv2 and pinvh to match the values of pinv
(which are also widely used).

Please let me know if there is any objections to this. Feedback is most
welcome.

best,
ilhan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190416/102cbf6d/attachment.html>

From ralf.gommers at gmail.com  Thu Apr 18 04:35:11 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 18 Apr 2019 10:35:11 +0200
Subject: [SciPy-Dev] SciPy now fiscally sponsored by NumFOCUS
Message-ID: <CABL7CQiokKra-iKYUT4ASTshf9PYThQ5VkbB5mSGmpTt+uGz8A@mail.gmail.com>

Hi everyone,

I'm happy to tell you that, finally, SciPy is now fiscally sponsored by
NumFOCUS. We signed a "Fiscal Sponsorship Agreement" between the SciPy
Steering Council and NumFOCUS, see
https://numfocus.org/information-fiscal-sponsorship (comprehensive model).

What this means is basically that we can have access to services like
administrative, legal, marketing support, and can through NumFOCUS accept
donations, grants, etc. and use those funds to further improve SciPy. Until
now we were only an "affiliated project", which didn't give us our own
account or the right to use funds that were donated to NumFOCUS dedicated
to SciPy (note that we did get some financial support before, e.g. the
small grants for optimize.linprog and pydata/sparse).

One thing we do need to do is clarify the situation around sponsors on
scipy.org. Right now it says "sponsored by Enthought" fairly prominently on
every page, and all other sponsors are hidden away at
https://scipy.org/scipylib/donations.html#infrastructure-non-financial-support.
NumFOCUS asked that we fix this. The situation is:
1. NumFOCUS is our fiscal sponsor
2. We have a number of former and current sponsors (both money and things
like free infrastructure or services). Those all need to be acknowledged in
a fair and visible way.

I will work on an update to scipy.org (aiming for next week) to fix this. A
more comprehensive overhaul of scipy.org would also be nice at some point,
but that's for later.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190418/582bd7db/attachment.html>

From ralf.gommers at gmail.com  Thu Apr 18 06:36:16 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 18 Apr 2019 12:36:16 +0200
Subject: [SciPy-Dev] grant proposal for core scientific Python projects
 (rejected)
Message-ID: <CABL7CQi0pBqeKta5FBV4XrOkLmiLME4jrjRm6TJo8rWREZ=KRA@mail.gmail.com>

Hi all,

A number of core projects (NumPy, SciPy, Matplotlib, Pandas, scikit-learn)
got together and put in a proposal to NSF for a large 5 year grant, and it
was unfortunately just rejected. We now published the proposal, which may
be of interest:
https://figshare.com/articles/Mid-Scale_Research_Infrastructure_-_The_Scientific_Python_Ecosystem/8009441
.

Those of you who are on Twitter may already know about this. First mention
of this rejection on Twitter with a lot of conversation following:
https://twitter.com/amuellerml/status/1117455802598662144. Full quote from
Andreas Mueller, replying to a tweet that the first ever image of a black
hole was built on Matplotlib, SciPy, NumPy, Pandas, Jupyter, AstroPy:
"Slightly ironic that in the same week @NSF rejects a grant to fund the
scipy ecosystem saying that working on it is not impactful enough and
hiring developers to work on it is too expensive." And a follow-up
conversation on Twitter about the rejection:
https://twitter.com/amuellerml/status/1118617331058475008

This proposal was led by Columbia, who submitted it together with NumFOCUS
and Quansight. It was largely written by Andreas Mueller (scikit-learn,
also the PI), Andy Terrel (NumFOCUS) and myself (NumPy/SciPy), with a lot
of valuable input from Thomas Caswell (Matplotlib), Jeff Reback (Pandas),
Gina Helfrich (NumFOCUS), the other co-PIs, the core teams of the projects,
and many others who pitched in ideas and advice.

This was the first time we tried a proposal of this scale and ambition (as
far as I know), and while it's disappointing that the NSF doesn't seem to
value software much (not really news, nor unique to NSF), rejections are a
normal part of submitting grant proposals and we now have a much better
idea of what it will take to submit further proposals in the future. Which
we plan on doing.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190418/46a864e0/attachment.html>

From stefanv at berkeley.edu  Thu Apr 18 13:49:51 2019
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Thu, 18 Apr 2019 10:49:51 -0700
Subject: [SciPy-Dev] SciPy now fiscally sponsored by NumFOCUS
In-Reply-To: <CABL7CQiokKra-iKYUT4ASTshf9PYThQ5VkbB5mSGmpTt+uGz8A@mail.gmail.com>
References: <CABL7CQiokKra-iKYUT4ASTshf9PYThQ5VkbB5mSGmpTt+uGz8A@mail.gmail.com>
Message-ID: <20190418174951.347uic7iphez2bvn@carbo>

Hi Ralf,

On Thu, 18 Apr 2019 10:35:11 +0200, Ralf Gommers wrote:
> One thing we do need to do is clarify the situation around sponsors on
> scipy.org. Right now it says "sponsored by Enthought" fairly prominently on
> every page, and all other sponsors are hidden away at
> https://scipy.org/scipylib/donations.html#infrastructure-non-financial-support.
> NumFOCUS asked that we fix this. The situation is:
> 1. NumFOCUS is our fiscal sponsor
> 2. We have a number of former and current sponsors (both money and things
> like free infrastructure or services). Those all need to be acknowledged in
> a fair and visible way.
> 
> I will work on an update to scipy.org (aiming for next week) to fix this. A
> more comprehensive overhaul of scipy.org would also be nice at some point,
> but that's for later.

I support clarifying the website in this regard.  A single page that
lists the various supporting organization, and the capacity in which
they did/do so, sorted by time, seems like it would be most fair.

Best regards,
St?fan

From teoliphant at gmail.com  Thu Apr 18 15:37:49 2019
From: teoliphant at gmail.com (Travis Oliphant)
Date: Thu, 18 Apr 2019 14:37:49 -0500
Subject: [SciPy-Dev] SciPy now fiscally sponsored by NumFOCUS
In-Reply-To: <CABL7CQiokKra-iKYUT4ASTshf9PYThQ5VkbB5mSGmpTt+uGz8A@mail.gmail.com>
References: <CABL7CQiokKra-iKYUT4ASTshf9PYThQ5VkbB5mSGmpTt+uGz8A@mail.gmail.com>
Message-ID: <CAFMmPGNqktQp+XRqMsFpPALRDFyR-4nT0hH+pb79d8LCGoOCwA@mail.gmail.com>

This is exciting news.  Thanks for all the work on this.

As you are putting up historical institutional sponsors for the work, I
would appreciate mention Mayo Clinic (1998-2001) and BYU (2001-2007) where
I was a paid graduate student and professor and worked on what became SciPy
and then SciPy.

Thanks,

-Travis




On Thu, Apr 18, 2019 at 3:35 AM Ralf Gommers <ralf.gommers at gmail.com> wrote:

> Hi everyone,
>
> I'm happy to tell you that, finally, SciPy is now fiscally sponsored by
> NumFOCUS. We signed a "Fiscal Sponsorship Agreement" between the SciPy
> Steering Council and NumFOCUS, see
> https://numfocus.org/information-fiscal-sponsorship (comprehensive model).
>
> What this means is basically that we can have access to services like
> administrative, legal, marketing support, and can through NumFOCUS accept
> donations, grants, etc. and use those funds to further improve SciPy. Until
> now we were only an "affiliated project", which didn't give us our own
> account or the right to use funds that were donated to NumFOCUS dedicated
> to SciPy (note that we did get some financial support before, e.g. the
> small grants for optimize.linprog and pydata/sparse).
>
> One thing we do need to do is clarify the situation around sponsors on
> scipy.org. Right now it says "sponsored by Enthought" fairly prominently
> on every page, and all other sponsors are hidden away at
> https://scipy.org/scipylib/donations.html#infrastructure-non-financial-support.
> NumFOCUS asked that we fix this. The situation is:
> 1. NumFOCUS is our fiscal sponsor
> 2. We have a number of former and current sponsors (both money and things
> like free infrastructure or services). Those all need to be acknowledged in
> a fair and visible way.
>
> I will work on an update to scipy.org (aiming for next week) to fix this.
> A more comprehensive overhaul of scipy.org would also be nice at some
> point, but that's for later.
>
> Cheers,
> Ralf
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190418/effc086f/attachment.html>

From ralf.gommers at gmail.com  Thu Apr 18 17:35:52 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 18 Apr 2019 23:35:52 +0200
Subject: [SciPy-Dev] SciPy now fiscally sponsored by NumFOCUS
In-Reply-To: <20190418174951.347uic7iphez2bvn@carbo>
References: <CABL7CQiokKra-iKYUT4ASTshf9PYThQ5VkbB5mSGmpTt+uGz8A@mail.gmail.com>
 <20190418174951.347uic7iphez2bvn@carbo>
Message-ID: <CABL7CQjUfRoJMAozzZyDuAsMS0bUAwYdY1DO=4sAFKRezgOjWA@mail.gmail.com>

On Thu, Apr 18, 2019 at 7:51 PM Stefan van der Walt <stefanv at berkeley.edu>
wrote:

> Hi Ralf,
>
> On Thu, 18 Apr 2019 10:35:11 +0200, Ralf Gommers wrote:
> > One thing we do need to do is clarify the situation around sponsors on
> > scipy.org. Right now it says "sponsored by Enthought" fairly
> prominently on
> > every page, and all other sponsors are hidden away at
> >
> https://scipy.org/scipylib/donations.html#infrastructure-non-financial-support
> .
> > NumFOCUS asked that we fix this. The situation is:
> > 1. NumFOCUS is our fiscal sponsor
> > 2. We have a number of former and current sponsors (both money and things
> > like free infrastructure or services). Those all need to be acknowledged
> in
> > a fair and visible way.
> >
> > I will work on an update to scipy.org (aiming for next week) to fix
> this. A
> > more comprehensive overhaul of scipy.org would also be nice at some
> point,
> > but that's for later.
>
> I support clarifying the website in this regard.  A single page that
> lists the various supporting organization, and the capacity in which
> they did/do so, sorted by time, seems like it would be most fair.
>

Sounds good, I'll do that.

Cheers,
Ralf


> Best regards,
> St?fan
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190418/285cb0c2/attachment.html>

From ralf.gommers at gmail.com  Thu Apr 18 17:47:44 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 18 Apr 2019 23:47:44 +0200
Subject: [SciPy-Dev] SciPy now fiscally sponsored by NumFOCUS
In-Reply-To: <CAFMmPGNqktQp+XRqMsFpPALRDFyR-4nT0hH+pb79d8LCGoOCwA@mail.gmail.com>
References: <CABL7CQiokKra-iKYUT4ASTshf9PYThQ5VkbB5mSGmpTt+uGz8A@mail.gmail.com>
 <CAFMmPGNqktQp+XRqMsFpPALRDFyR-4nT0hH+pb79d8LCGoOCwA@mail.gmail.com>
Message-ID: <CABL7CQjPUdaVKGKTDBokkwyA7EzMFRyjz3izemA96=8+Q4mtKg@mail.gmail.com>

On Thu, Apr 18, 2019 at 9:38 PM Travis Oliphant <teoliphant at gmail.com>
wrote:

> This is exciting news.  Thanks for all the work on this.
>
> As you are putting up historical institutional sponsors for the work, I
> would appreciate mention Mayo Clinic (1998-2001) and BYU (2001-2007) where
> I was a paid graduate student and professor and worked on what became SciPy
> and then SciPy.
>

Thanks for the input Travis. That's a fair request, and I will include
those two institutions.

A further thought on this: going forward I think we should only list
Institutional Partners, for which we have a clear definition:
http://scipy.github.io/devdocs/dev/governance/governance.html#institutional-partners-and-funding.
The key point of that is: work on SciPy has to be part of the official
duties of the employee. However going back in time I think we should be
inclusive, also when other past contributors have done large amounts of
work "in the boss's time" and make a similar requests.

Cheers,
Ralf




> Thanks,
>
> -Travis
>
>
>
>
> On Thu, Apr 18, 2019 at 3:35 AM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> I'm happy to tell you that, finally, SciPy is now fiscally sponsored by
>> NumFOCUS. We signed a "Fiscal Sponsorship Agreement" between the SciPy
>> Steering Council and NumFOCUS, see
>> https://numfocus.org/information-fiscal-sponsorship (comprehensive
>> model).
>>
>> What this means is basically that we can have access to services like
>> administrative, legal, marketing support, and can through NumFOCUS accept
>> donations, grants, etc. and use those funds to further improve SciPy. Until
>> now we were only an "affiliated project", which didn't give us our own
>> account or the right to use funds that were donated to NumFOCUS dedicated
>> to SciPy (note that we did get some financial support before, e.g. the
>> small grants for optimize.linprog and pydata/sparse).
>>
>> One thing we do need to do is clarify the situation around sponsors on
>> scipy.org. Right now it says "sponsored by Enthought" fairly prominently
>> on every page, and all other sponsors are hidden away at
>> https://scipy.org/scipylib/donations.html#infrastructure-non-financial-support.
>> NumFOCUS asked that we fix this. The situation is:
>> 1. NumFOCUS is our fiscal sponsor
>> 2. We have a number of former and current sponsors (both money and things
>> like free infrastructure or services). Those all need to be acknowledged in
>> a fair and visible way.
>>
>> I will work on an update to scipy.org (aiming for next week) to fix
>> this. A more comprehensive overhaul of scipy.org would also be nice at
>> some point, but that's for later.
>>
>> Cheers,
>> Ralf
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190418/2eb49cfe/attachment-0001.html>

From mikofski at berkeley.edu  Fri Apr 19 03:33:38 2019
From: mikofski at berkeley.edu (Mark Mikofski)
Date: Fri, 19 Apr 2019 00:33:38 -0700
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CADuxUixwV-9G8-PaLnL+M=TSsyE7_nPWMTdGe+k34pXN=tHm5w@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
 <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
 <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>
 <CAEqRcW27eWa_ypS9wU-2UXuQ7mZDCyhBpHzvWOpHDS2Aza19Nw@mail.gmail.com>
 <CADuxUixwV-9G8-PaLnL+M=TSsyE7_nPWMTdGe+k34pXN=tHm5w@mail.gmail.com>
Message-ID: <CAEqRcW1R5jCuP51aJe3N-s+YaGuCA-FVjK-bYL2_N8V7Y=PqHw@mail.gmail.com>

Hi Tyler,

Thanks again for taking on the release management.

Is there anything that we (as contributors) can do to help? Should we be
reviewing the 1.3.0 milestone PR's? What would be most helpful specifically?

I read through the dev guide (
https://docs.scipy.org/doc/scipy/reference/dev/index.html) and hacking
guidelines (https://docs.scipy.org/doc/scipy/reference/hacking.html), and I
looked at the 1.3.0 milestones, and it seems like reviewing PR's with the
fewest comments might be the best approach. Would that help?

Cheers,
Mark

On Sun, Apr 14, 2019 at 5:42 PM Matt Haberland <haberland at ucla.edu> wrote:

> I'd like to get #10026 in there, too. SuiteSparse seems to routinely speed
> up `linprog` by a factor of 2-4 (when available).
>
> On Sun, Apr 14, 2019 at 7:40 AM Mark Alexander Mikofski <
> mikofski at berkeley.edu> wrote:
>
>> Hi Tyler,
>>
>> Thanks for managing the release again! This is a very important service
>> for the SciPy community, and I'm very grateful!
>>
>> Do you think we could try to add #9568 and #10052 assuming everyone
>> agrees they are good?
>>
>> thanks again!
>> Mark
>>
>> On Sun, Apr 14, 2019 at 2:13 AM Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sun, Apr 14, 2019 at 12:27 AM Andrew Nelson <andyfaff at gmail.com>
>>> wrote:
>>>
>>>> Would it be possible to add 9990 and 10002 to 1.3.0, or is that too
>>>> ambitious?
>>>>
>>>
>>> Those look like they're in good shape, should be doable. I've added them
>>> to the milestone. Tyler can always remove them again if we run out of time.
>>>
>>>
>>>> On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <tyler.je.reddy at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> It is almost 4 months after the (slightly-delayed) 1.2.0 release on
>>>>> December 17/ 2018, so probably time to plan the 1.3.0 release. It would be
>>>>> a good idea to look over the PRs with a 1.3.0 milestone, and tag anything
>>>>> else that should have this milestone appropriately.
>>>>>
>>>>> I'd like to propose the following schedule:
>>>>>
>>>>> April 25: branch 1.3.x
>>>>> April 28: rc1
>>>>> May 11: rc2 (if needed)
>>>>> May 20: final release
>>>>>
>>>>> Thoughts?
>>>>>
>>>>
>>> That works for me. There may be a few items in
>>> https://github.com/scipy/scipy/milestone/37 that we won't get to, but
>>> the only real blocker (py37 build issue) on that list is ready to merge.
>>>
>>> Cheers,
>>> Ralf
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>>
>>
>> --
>> Mark Mikofski, PhD (2005)
>> *Fiat Lux*
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>
>
> --
> Matt Haberland
> Assistant Adjunct Professor in the Program in Computing
> Department of Mathematics
> 6617A Math Sciences Building, UCLA
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>


-- 
Mark Mikofski, PhD (2005)
*Fiat Lux*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190419/bd691f34/attachment.html>

From ralf.gommers at gmail.com  Fri Apr 19 05:48:24 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Fri, 19 Apr 2019 11:48:24 +0200
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CAEqRcW1R5jCuP51aJe3N-s+YaGuCA-FVjK-bYL2_N8V7Y=PqHw@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
 <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
 <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>
 <CAEqRcW27eWa_ypS9wU-2UXuQ7mZDCyhBpHzvWOpHDS2Aza19Nw@mail.gmail.com>
 <CADuxUixwV-9G8-PaLnL+M=TSsyE7_nPWMTdGe+k34pXN=tHm5w@mail.gmail.com>
 <CAEqRcW1R5jCuP51aJe3N-s+YaGuCA-FVjK-bYL2_N8V7Y=PqHw@mail.gmail.com>
Message-ID: <CABL7CQjzT+nZDK8cZSMWHc8QAc_NrGA8CCzFTgGHL2EoYi+Q-Q@mail.gmail.com>

On Fri, Apr 19, 2019 at 9:34 AM Mark Mikofski <mikofski at berkeley.edu> wrote:

> Hi Tyler,
>
> Thanks again for taking on the release management.
>
> Is there anything that we (as contributors) can do to help? Should we be
> reviewing the 1.3.0 milestone PR's? What would be most helpful specifically?
>

Help with reviewing can be a very valuable contribution, not just for a
particular release but in general. I think many contributors are under the
impression that you need to be a maintainer to review - this definitely
isn't the case, as long as you have the knowledge to understand the code in
a PR you can help a lot. In particular this is the case for larger PRs that
propose new features, because those are often a lot of work to review and
require domain-specific knowledge. Here is an example (also tagged for
1.3.0): https://github.com/scipy/scipy/pull/7310, adding a logarithmic FFT
implementation. Two kinds of things would be helpful:
- someone who understands FFTs well and can review the implementation
- someone who needs the feature, and can test it and confirm that
everything works as expected

A couple more in the same vein:
- peak declustering for scipy.signal:
https://github.com/scipy/scipy/pull/9513
- RotationSpline for scipy.spatial.transform:
https://github.com/scipy/scipy/pull/9831
- support for ARFF relational attributes in scipy.io:
https://github.com/scipy/scipy/pull/9854

Cheers,
Ralf


> I read through the dev guide (
> https://docs.scipy.org/doc/scipy/reference/dev/index.html) and hacking
> guidelines (https://docs.scipy.org/doc/scipy/reference/hacking.html), and
> I looked at the 1.3.0 milestones, and it seems like reviewing PR's with the
> fewest comments might be the best approach. Would that help?
>
> Cheers,
> Mark
>
> On Sun, Apr 14, 2019 at 5:42 PM Matt Haberland <haberland at ucla.edu> wrote:
>
>> I'd like to get #10026 in there, too. SuiteSparse seems to routinely
>> speed up `linprog` by a factor of 2-4 (when available).
>>
>> On Sun, Apr 14, 2019 at 7:40 AM Mark Alexander Mikofski <
>> mikofski at berkeley.edu> wrote:
>>
>>> Hi Tyler,
>>>
>>> Thanks for managing the release again! This is a very important service
>>> for the SciPy community, and I'm very grateful!
>>>
>>> Do you think we could try to add #9568 and #10052 assuming everyone
>>> agrees they are good?
>>>
>>> thanks again!
>>> Mark
>>>
>>> On Sun, Apr 14, 2019 at 2:13 AM Ralf Gommers <ralf.gommers at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sun, Apr 14, 2019 at 12:27 AM Andrew Nelson <andyfaff at gmail.com>
>>>> wrote:
>>>>
>>>>> Would it be possible to add 9990 and 10002 to 1.3.0, or is that too
>>>>> ambitious?
>>>>>
>>>>
>>>> Those look like they're in good shape, should be doable. I've added
>>>> them to the milestone. Tyler can always remove them again if we run out of
>>>> time.
>>>>
>>>>
>>>>> On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <tyler.je.reddy at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> It is almost 4 months after the (slightly-delayed) 1.2.0 release on
>>>>>> December 17/ 2018, so probably time to plan the 1.3.0 release. It would be
>>>>>> a good idea to look over the PRs with a 1.3.0 milestone, and tag anything
>>>>>> else that should have this milestone appropriately.
>>>>>>
>>>>>> I'd like to propose the following schedule:
>>>>>>
>>>>>> April 25: branch 1.3.x
>>>>>> April 28: rc1
>>>>>> May 11: rc2 (if needed)
>>>>>> May 20: final release
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>
>>>> That works for me. There may be a few items in
>>>> https://github.com/scipy/scipy/milestone/37 that we won't get to, but
>>>> the only real blocker (py37 build issue) on that list is ready to merge.
>>>>
>>>> Cheers,
>>>> Ralf
>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>>
>>>
>>> --
>>> Mark Mikofski, PhD (2005)
>>> *Fiat Lux*
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>>
>>
>> --
>> Matt Haberland
>> Assistant Adjunct Professor in the Program in Computing
>> Department of Mathematics
>> 6617A Math Sciences Building, UCLA
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>
>
> --
> Mark Mikofski, PhD (2005)
> *Fiat Lux*
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190419/de80d990/attachment-0001.html>

From tyler.je.reddy at gmail.com  Fri Apr 19 20:54:29 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Fri, 19 Apr 2019 17:54:29 -0700
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CABL7CQjzT+nZDK8cZSMWHc8QAc_NrGA8CCzFTgGHL2EoYi+Q-Q@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
 <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
 <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>
 <CAEqRcW27eWa_ypS9wU-2UXuQ7mZDCyhBpHzvWOpHDS2Aza19Nw@mail.gmail.com>
 <CADuxUixwV-9G8-PaLnL+M=TSsyE7_nPWMTdGe+k34pXN=tHm5w@mail.gmail.com>
 <CAEqRcW1R5jCuP51aJe3N-s+YaGuCA-FVjK-bYL2_N8V7Y=PqHw@mail.gmail.com>
 <CABL7CQjzT+nZDK8cZSMWHc8QAc_NrGA8CCzFTgGHL2EoYi+Q-Q@mail.gmail.com>
Message-ID: <CAHPuU_bGtsX=DLn8=G_p+31vwwrxuwBTWS5gdpy3o5h9j=PymA@mail.gmail.com>

We are sitting at 20 open PRs with the 1.3.0 milestone:
https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0

We were close to 30 recently, so let's try to keep it < 20 over the weekend
/ moving into next week.

On Fri, 19 Apr 2019 at 02:48, Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Fri, Apr 19, 2019 at 9:34 AM Mark Mikofski <mikofski at berkeley.edu>
> wrote:
>
>> Hi Tyler,
>>
>> Thanks again for taking on the release management.
>>
>> Is there anything that we (as contributors) can do to help? Should we be
>> reviewing the 1.3.0 milestone PR's? What would be most helpful specifically?
>>
>
> Help with reviewing can be a very valuable contribution, not just for a
> particular release but in general. I think many contributors are under the
> impression that you need to be a maintainer to review - this definitely
> isn't the case, as long as you have the knowledge to understand the code in
> a PR you can help a lot. In particular this is the case for larger PRs that
> propose new features, because those are often a lot of work to review and
> require domain-specific knowledge. Here is an example (also tagged for
> 1.3.0): https://github.com/scipy/scipy/pull/7310, adding a logarithmic
> FFT implementation. Two kinds of things would be helpful:
> - someone who understands FFTs well and can review the implementation
> - someone who needs the feature, and can test it and confirm that
> everything works as expected
>
> A couple more in the same vein:
> - peak declustering for scipy.signal:
> https://github.com/scipy/scipy/pull/9513
> - RotationSpline for scipy.spatial.transform:
> https://github.com/scipy/scipy/pull/9831
> - support for ARFF relational attributes in scipy.io:
> https://github.com/scipy/scipy/pull/9854
>
> Cheers,
> Ralf
>
>
>> I read through the dev guide (
>> https://docs.scipy.org/doc/scipy/reference/dev/index.html) and hacking
>> guidelines (https://docs.scipy.org/doc/scipy/reference/hacking.html),
>> and I looked at the 1.3.0 milestones, and it seems like reviewing PR's with
>> the fewest comments might be the best approach. Would that help?
>>
>> Cheers,
>> Mark
>>
>> On Sun, Apr 14, 2019 at 5:42 PM Matt Haberland <haberland at ucla.edu>
>> wrote:
>>
>>> I'd like to get #10026 in there, too. SuiteSparse seems to routinely
>>> speed up `linprog` by a factor of 2-4 (when available).
>>>
>>> On Sun, Apr 14, 2019 at 7:40 AM Mark Alexander Mikofski <
>>> mikofski at berkeley.edu> wrote:
>>>
>>>> Hi Tyler,
>>>>
>>>> Thanks for managing the release again! This is a very important service
>>>> for the SciPy community, and I'm very grateful!
>>>>
>>>> Do you think we could try to add #9568 and #10052 assuming everyone
>>>> agrees they are good?
>>>>
>>>> thanks again!
>>>> Mark
>>>>
>>>> On Sun, Apr 14, 2019 at 2:13 AM Ralf Gommers <ralf.gommers at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Apr 14, 2019 at 12:27 AM Andrew Nelson <andyfaff at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Would it be possible to add 9990 and 10002 to 1.3.0, or is that too
>>>>>> ambitious?
>>>>>>
>>>>>
>>>>> Those look like they're in good shape, should be doable. I've added
>>>>> them to the milestone. Tyler can always remove them again if we run out of
>>>>> time.
>>>>>
>>>>>
>>>>>> On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <tyler.je.reddy at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> It is almost 4 months after the (slightly-delayed) 1.2.0 release on
>>>>>>> December 17/ 2018, so probably time to plan the 1.3.0 release. It would be
>>>>>>> a good idea to look over the PRs with a 1.3.0 milestone, and tag anything
>>>>>>> else that should have this milestone appropriately.
>>>>>>>
>>>>>>> I'd like to propose the following schedule:
>>>>>>>
>>>>>>> April 25: branch 1.3.x
>>>>>>> April 28: rc1
>>>>>>> May 11: rc2 (if needed)
>>>>>>> May 20: final release
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>
>>>>> That works for me. There may be a few items in
>>>>> https://github.com/scipy/scipy/milestone/37 that we won't get to, but
>>>>> the only real blocker (py37 build issue) on that list is ready to merge.
>>>>>
>>>>> Cheers,
>>>>> Ralf
>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> Mark Mikofski, PhD (2005)
>>>> *Fiat Lux*
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>>
>>>
>>> --
>>> Matt Haberland
>>> Assistant Adjunct Professor in the Program in Computing
>>> Department of Mathematics
>>> 6617A Math Sciences Building, UCLA
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>>
>>
>> --
>> Mark Mikofski, PhD (2005)
>> *Fiat Lux*
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190419/44ede472/attachment.html>

From ralf.gommers at gmail.com  Sun Apr 21 15:47:26 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 21 Apr 2019 21:47:26 +0200
Subject: [SciPy-Dev] toolchain roadmap
Message-ID: <CABL7CQiVB3FhSfnLaQMywzQ83pw_h3oOj1VLkmh+EZwpsyskSg@mail.gmail.com>

Hi all,

This is worth a mention: Paul van Mulbregt wrote a very nice "toolchain
roadmap" that was just merged. So if you want to know when you can use C99,
or what LAPACK versions are supported, or any such question:
http://scipy.github.io/devdocs/toolchain.html

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190421/e3aa9f4c/attachment.html>

From cournape at gmail.com  Sun Apr 21 19:09:43 2019
From: cournape at gmail.com (David Cournapeau)
Date: Mon, 22 Apr 2019 08:09:43 +0900
Subject: [SciPy-Dev] toolchain roadmap
In-Reply-To: <CABL7CQiVB3FhSfnLaQMywzQ83pw_h3oOj1VLkmh+EZwpsyskSg@mail.gmail.com>
References: <CABL7CQiVB3FhSfnLaQMywzQ83pw_h3oOj1VLkmh+EZwpsyskSg@mail.gmail.com>
Message-ID: <CAGY4rcXWHJL5AAihnXi5tfPCitqKU4MDiSAEH-m7LhiFUS4utA@mail.gmail.com>

Nice. I am looking forward to the time where we can finally rely on decent
C99 support !

On Mon, Apr 22, 2019 at 4:47 AM Ralf Gommers <ralf.gommers at gmail.com> wrote:

> Hi all,
>
> This is worth a mention: Paul van Mulbregt wrote a very nice "toolchain
> roadmap" that was just merged. So if you want to know when you can use C99,
> or what LAPACK versions are supported, or any such question:
> http://scipy.github.io/devdocs/toolchain.html
>
> Cheers,
> Ralf
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190422/2ad25991/attachment.html>

From charlesr.harris at gmail.com  Sun Apr 21 22:39:15 2019
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 21 Apr 2019 20:39:15 -0600
Subject: [SciPy-Dev] NumPy 1.16. 3 release
Message-ID: <CAB6mnxLgBLa_HQ2rahtSDhvXrWTu3PSi8E2BKKE9X+6=mTRpOg@mail.gmail.com>

Hi All,

On behalf of the NumPy team I am pleased to announce the release of NumPy
1.16.3 which contains several fixes for newly reported bugs.  The Python
versions supported in this release are 2.7 and 3.5-3.7.  There are several
notable changes.

   - Unpickling object arrays when loading *.npy or *.npz files now
   requires an explicit opt-in. This backwards incompatible change was made
   in response to CVE-2019-6446
   <https://nvd.nist.gov/vuln/detail/CVE-2019-6446>.
   - The covariance in 'random.mvnormal' is cast to double. This should
   make the tolerance more useful when checking the singular values of the
   covariance matrix.
   - The '__array_interface__' offset now works as documented. The  offset
   value was being mistakenly ignored.

Downstream developers building this release should use Cython >= 0.29.2
and, if using OpenBLAS, OpenBLAS > v0.3.4.  Wheels for this release can be
downloaded from PyPI <https://pypi.org/project/numpy/1.16.3/>, source
archives and release notes are available from Github
<https://github.com/numpy/numpy/releases/tag/v1.16.3>.

If you are installing using pip, you may encounter a problem with older
installed versions of NumPy that pip did not delete becoming mixed with the
current version, resulting in an ``ImportError``. That problem is
particularly
common on Debian derived distributions due to a modified pip.  The fix is
to make sure all previous NumPy versions installed by pip have been
removed. See #12736 <https://github.com/numpy/numpy/issues/12736> for
discussion of the issue.

*Contributors*

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

   - Andreas Schwab
   - Bharat Raghunathan +
   - Bran +
   - Charles Harris
   - Eric Wieser
   - Jakub Wilk
   - Kevin Sheppard
   - Marten van Kerkwijk
   - Matti Picus
   - Paul Ivanov
   - Ralf Gommers
   - Sebastian Berg
   - Tyler Reddy
   - Warren Weckesser
   - Yu Feng
   - adeak +


*Pull requests merged*

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

   - gh-13072 : BUG: Fixes to numpy.distutils.Configuration.get_version
   (#13056)
   - gh-13082 : BUG: Fix errors in string formatting while producing an
   error
   - gh-13083 : BUG: Convert fortran flags in environment variable
   - gh-13084 : BUG: Remove error-prone borrowed reference handling
   - gh-13085 : BUG: Add error checks when converting integers to datetime
   types
   - gh-13091 : BUG: Remove our patched version of `distutils.split_quoted`
   - gh-13141 : BUG: Fix testsuite failures on ppc and riscv
   - gh-13142 : BUG: Fix parameter validity checks in ``random.choice``
   - gh-13143 : BUG: Ensure linspace works on object input.
   - gh-13144 : BLD: fix include list for sdist building.
   - gh-13145 : BUG: __array_interface__ offset was always ignored
   - gh-13274 : MAINT: f2py: Add a cast to avoid a compiler warning.
   - gh-13275 : BUG, MAINT: fix reference count error on invalid input to
   ndarray.flat
   - gh-13276 : ENH: Cast covariance to double in random mvnormal
   - gh-13278 : BUG: Fix null pointer dereference in
   PyArray_DTypeFromObjectHelper
   - gh-13339 : BUG: Use C call to sysctlbyname for AVX detection on MacOS.
   - gh-13340 : BUG: Fix crash when calling savetxt on a padded array
   - gh-13341 : BUG: ufunc.at iteration variable size fix
   - gh-13342 : DOC: Add as_ctypes_type to the documentation
   - gh-13350 : BUG: Return the coefficients array directly
   - gh-13351 : BUG/MAINT: Tidy typeinfo.h and .c
   - gh-13359 : BUG: Make allow_pickle=False the default for loading
   - gh-13360 : DOC: fix some doctest failures
   - gh-13363 : BUG/MAINT: Tidy typeinfo.h and .c
   - gh-13381 : BLD: address mingw-w64 issue. Follow-up to gh-9977
   - gh-13382 : REL: Prepare for the NumPy release.

Cheers,

Charles Harris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190421/1418781b/attachment.html>

From ralf.gommers at gmail.com  Mon Apr 22 04:47:42 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 22 Apr 2019 10:47:42 +0200
Subject: [SciPy-Dev] toolchain roadmap
In-Reply-To: <CAGY4rcXWHJL5AAihnXi5tfPCitqKU4MDiSAEH-m7LhiFUS4utA@mail.gmail.com>
References: <CABL7CQiVB3FhSfnLaQMywzQ83pw_h3oOj1VLkmh+EZwpsyskSg@mail.gmail.com>
 <CAGY4rcXWHJL5AAihnXi5tfPCitqKU4MDiSAEH-m7LhiFUS4utA@mail.gmail.com>
Message-ID: <CABL7CQgVRe7cXuFb=b2L35h+SocW5oMWvWxnZDBJyLR60q56Xw@mail.gmail.com>

On Mon, Apr 22, 2019 at 1:10 AM David Cournapeau <cournape at gmail.com> wrote:

> Nice. I am looking forward to the time where we can finally rely on decent
> C99 support !
>

In principle we can today. NumPy already requires C99 after the addition of
Pocketfft and there have been no major issues with that.

Cheers,
Ralf


> On Mon, Apr 22, 2019 at 4:47 AM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>> Hi all,
>>
>> This is worth a mention: Paul van Mulbregt wrote a very nice "toolchain
>> roadmap" that was just merged. So if you want to know when you can use C99,
>> or what LAPACK versions are supported, or any such question:
>> http://scipy.github.io/devdocs/toolchain.html
>>
>> Cheers,
>> Ralf
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190422/664b506b/attachment-0001.html>

From tyler.je.reddy at gmail.com  Tue Apr 23 18:31:53 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Tue, 23 Apr 2019 15:31:53 -0700
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CAHPuU_bGtsX=DLn8=G_p+31vwwrxuwBTWS5gdpy3o5h9j=PymA@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
 <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
 <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>
 <CAEqRcW27eWa_ypS9wU-2UXuQ7mZDCyhBpHzvWOpHDS2Aza19Nw@mail.gmail.com>
 <CADuxUixwV-9G8-PaLnL+M=TSsyE7_nPWMTdGe+k34pXN=tHm5w@mail.gmail.com>
 <CAEqRcW1R5jCuP51aJe3N-s+YaGuCA-FVjK-bYL2_N8V7Y=PqHw@mail.gmail.com>
 <CABL7CQjzT+nZDK8cZSMWHc8QAc_NrGA8CCzFTgGHL2EoYi+Q-Q@mail.gmail.com>
 <CAHPuU_bGtsX=DLn8=G_p+31vwwrxuwBTWS5gdpy3o5h9j=PymA@mail.gmail.com>
Message-ID: <CAHPuU_a0fMpLp-pA9w7KRx0hEdAnS7ukgMgsk32iJL6OwDxkEw@mail.gmail.com>

Down to 5 open PRs with the 1.3.0 milestone:
https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0



On Fri, 19 Apr 2019 at 17:54, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:

> We are sitting at 20 open PRs with the 1.3.0 milestone:
> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0
>
> We were close to 30 recently, so let's try to keep it < 20 over the
> weekend / moving into next week.
>
> On Fri, 19 Apr 2019 at 02:48, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>>
>>
>> On Fri, Apr 19, 2019 at 9:34 AM Mark Mikofski <mikofski at berkeley.edu>
>> wrote:
>>
>>> Hi Tyler,
>>>
>>> Thanks again for taking on the release management.
>>>
>>> Is there anything that we (as contributors) can do to help? Should we be
>>> reviewing the 1.3.0 milestone PR's? What would be most helpful specifically?
>>>
>>
>> Help with reviewing can be a very valuable contribution, not just for a
>> particular release but in general. I think many contributors are under the
>> impression that you need to be a maintainer to review - this definitely
>> isn't the case, as long as you have the knowledge to understand the code in
>> a PR you can help a lot. In particular this is the case for larger PRs that
>> propose new features, because those are often a lot of work to review and
>> require domain-specific knowledge. Here is an example (also tagged for
>> 1.3.0): https://github.com/scipy/scipy/pull/7310, adding a logarithmic
>> FFT implementation. Two kinds of things would be helpful:
>> - someone who understands FFTs well and can review the implementation
>> - someone who needs the feature, and can test it and confirm that
>> everything works as expected
>>
>> A couple more in the same vein:
>> - peak declustering for scipy.signal:
>> https://github.com/scipy/scipy/pull/9513
>> - RotationSpline for scipy.spatial.transform:
>> https://github.com/scipy/scipy/pull/9831
>> - support for ARFF relational attributes in scipy.io:
>> https://github.com/scipy/scipy/pull/9854
>>
>> Cheers,
>> Ralf
>>
>>
>>> I read through the dev guide (
>>> https://docs.scipy.org/doc/scipy/reference/dev/index.html) and hacking
>>> guidelines (https://docs.scipy.org/doc/scipy/reference/hacking.html),
>>> and I looked at the 1.3.0 milestones, and it seems like reviewing PR's with
>>> the fewest comments might be the best approach. Would that help?
>>>
>>> Cheers,
>>> Mark
>>>
>>> On Sun, Apr 14, 2019 at 5:42 PM Matt Haberland <haberland at ucla.edu>
>>> wrote:
>>>
>>>> I'd like to get #10026 in there, too. SuiteSparse seems to routinely
>>>> speed up `linprog` by a factor of 2-4 (when available).
>>>>
>>>> On Sun, Apr 14, 2019 at 7:40 AM Mark Alexander Mikofski <
>>>> mikofski at berkeley.edu> wrote:
>>>>
>>>>> Hi Tyler,
>>>>>
>>>>> Thanks for managing the release again! This is a very important
>>>>> service for the SciPy community, and I'm very grateful!
>>>>>
>>>>> Do you think we could try to add #9568 and #10052 assuming everyone
>>>>> agrees they are good?
>>>>>
>>>>> thanks again!
>>>>> Mark
>>>>>
>>>>> On Sun, Apr 14, 2019 at 2:13 AM Ralf Gommers <ralf.gommers at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Apr 14, 2019 at 12:27 AM Andrew Nelson <andyfaff at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Would it be possible to add 9990 and 10002 to 1.3.0, or is that too
>>>>>>> ambitious?
>>>>>>>
>>>>>>
>>>>>> Those look like they're in good shape, should be doable. I've added
>>>>>> them to the milestone. Tyler can always remove them again if we run out of
>>>>>> time.
>>>>>>
>>>>>>
>>>>>>> On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <tyler.je.reddy at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> It is almost 4 months after the (slightly-delayed) 1.2.0 release on
>>>>>>>> December 17/ 2018, so probably time to plan the 1.3.0 release. It would be
>>>>>>>> a good idea to look over the PRs with a 1.3.0 milestone, and tag anything
>>>>>>>> else that should have this milestone appropriately.
>>>>>>>>
>>>>>>>> I'd like to propose the following schedule:
>>>>>>>>
>>>>>>>> April 25: branch 1.3.x
>>>>>>>> April 28: rc1
>>>>>>>> May 11: rc2 (if needed)
>>>>>>>> May 20: final release
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>
>>>>>> That works for me. There may be a few items in
>>>>>> https://github.com/scipy/scipy/milestone/37 that we won't get to,
>>>>>> but the only real blocker (py37 build issue) on that list is ready to merge.
>>>>>>
>>>>>> Cheers,
>>>>>> Ralf
>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mark Mikofski, PhD (2005)
>>>>> *Fiat Lux*
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Haberland
>>>> Assistant Adjunct Professor in the Program in Computing
>>>> Department of Mathematics
>>>> 6617A Math Sciences Building, UCLA
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>>
>>>
>>> --
>>> Mark Mikofski, PhD (2005)
>>> *Fiat Lux*
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190423/c3870884/attachment.html>

From tyler.je.reddy at gmail.com  Thu Apr 25 13:59:25 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Thu, 25 Apr 2019 10:59:25 -0700
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CAHPuU_a0fMpLp-pA9w7KRx0hEdAnS7ukgMgsk32iJL6OwDxkEw@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
 <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
 <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>
 <CAEqRcW27eWa_ypS9wU-2UXuQ7mZDCyhBpHzvWOpHDS2Aza19Nw@mail.gmail.com>
 <CADuxUixwV-9G8-PaLnL+M=TSsyE7_nPWMTdGe+k34pXN=tHm5w@mail.gmail.com>
 <CAEqRcW1R5jCuP51aJe3N-s+YaGuCA-FVjK-bYL2_N8V7Y=PqHw@mail.gmail.com>
 <CABL7CQjzT+nZDK8cZSMWHc8QAc_NrGA8CCzFTgGHL2EoYi+Q-Q@mail.gmail.com>
 <CAHPuU_bGtsX=DLn8=G_p+31vwwrxuwBTWS5gdpy3o5h9j=PymA@mail.gmail.com>
 <CAHPuU_a0fMpLp-pA9w7KRx0hEdAnS7ukgMgsk32iJL6OwDxkEw@mail.gmail.com>
Message-ID: <CAHPuU_Y68Varm-rvOFzsKE0hA3xEtvjtNE7pDcyUf-U-FGRQEw@mail.gmail.com>

There should be no open issues / PRs with the 1.3.0 milestone now. I'm
going to work on improving the release notes for a while & open a PR for
that soon-ish.

On Tue, 23 Apr 2019 at 15:31, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:

> Down to 5 open PRs with the 1.3.0 milestone:
> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0
>
>
>
> On Fri, 19 Apr 2019 at 17:54, Tyler Reddy <tyler.je.reddy at gmail.com>
> wrote:
>
>> We are sitting at 20 open PRs with the 1.3.0 milestone:
>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0
>>
>> We were close to 30 recently, so let's try to keep it < 20 over the
>> weekend / moving into next week.
>>
>> On Fri, 19 Apr 2019 at 02:48, Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Apr 19, 2019 at 9:34 AM Mark Mikofski <mikofski at berkeley.edu>
>>> wrote:
>>>
>>>> Hi Tyler,
>>>>
>>>> Thanks again for taking on the release management.
>>>>
>>>> Is there anything that we (as contributors) can do to help? Should we
>>>> be reviewing the 1.3.0 milestone PR's? What would be most helpful
>>>> specifically?
>>>>
>>>
>>> Help with reviewing can be a very valuable contribution, not just for a
>>> particular release but in general. I think many contributors are under the
>>> impression that you need to be a maintainer to review - this definitely
>>> isn't the case, as long as you have the knowledge to understand the code in
>>> a PR you can help a lot. In particular this is the case for larger PRs that
>>> propose new features, because those are often a lot of work to review and
>>> require domain-specific knowledge. Here is an example (also tagged for
>>> 1.3.0): https://github.com/scipy/scipy/pull/7310, adding a logarithmic
>>> FFT implementation. Two kinds of things would be helpful:
>>> - someone who understands FFTs well and can review the implementation
>>> - someone who needs the feature, and can test it and confirm that
>>> everything works as expected
>>>
>>> A couple more in the same vein:
>>> - peak declustering for scipy.signal:
>>> https://github.com/scipy/scipy/pull/9513
>>> - RotationSpline for scipy.spatial.transform:
>>> https://github.com/scipy/scipy/pull/9831
>>> - support for ARFF relational attributes in scipy.io:
>>> https://github.com/scipy/scipy/pull/9854
>>>
>>> Cheers,
>>> Ralf
>>>
>>>
>>>> I read through the dev guide (
>>>> https://docs.scipy.org/doc/scipy/reference/dev/index.html) and hacking
>>>> guidelines (https://docs.scipy.org/doc/scipy/reference/hacking.html),
>>>> and I looked at the 1.3.0 milestones, and it seems like reviewing PR's with
>>>> the fewest comments might be the best approach. Would that help?
>>>>
>>>> Cheers,
>>>> Mark
>>>>
>>>> On Sun, Apr 14, 2019 at 5:42 PM Matt Haberland <haberland at ucla.edu>
>>>> wrote:
>>>>
>>>>> I'd like to get #10026 in there, too. SuiteSparse seems to routinely
>>>>> speed up `linprog` by a factor of 2-4 (when available).
>>>>>
>>>>> On Sun, Apr 14, 2019 at 7:40 AM Mark Alexander Mikofski <
>>>>> mikofski at berkeley.edu> wrote:
>>>>>
>>>>>> Hi Tyler,
>>>>>>
>>>>>> Thanks for managing the release again! This is a very important
>>>>>> service for the SciPy community, and I'm very grateful!
>>>>>>
>>>>>> Do you think we could try to add #9568 and #10052 assuming everyone
>>>>>> agrees they are good?
>>>>>>
>>>>>> thanks again!
>>>>>> Mark
>>>>>>
>>>>>> On Sun, Apr 14, 2019 at 2:13 AM Ralf Gommers <ralf.gommers at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Apr 14, 2019 at 12:27 AM Andrew Nelson <andyfaff at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Would it be possible to add 9990 and 10002 to 1.3.0, or is that too
>>>>>>>> ambitious?
>>>>>>>>
>>>>>>>
>>>>>>> Those look like they're in good shape, should be doable. I've added
>>>>>>> them to the milestone. Tyler can always remove them again if we run out of
>>>>>>> time.
>>>>>>>
>>>>>>>
>>>>>>>> On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <tyler.je.reddy at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> It is almost 4 months after the (slightly-delayed) 1.2.0 release
>>>>>>>>> on December 17/ 2018, so probably time to plan the 1.3.0 release. It would
>>>>>>>>> be a good idea to look over the PRs with a 1.3.0 milestone, and tag
>>>>>>>>> anything else that should have this milestone appropriately.
>>>>>>>>>
>>>>>>>>> I'd like to propose the following schedule:
>>>>>>>>>
>>>>>>>>> April 25: branch 1.3.x
>>>>>>>>> April 28: rc1
>>>>>>>>> May 11: rc2 (if needed)
>>>>>>>>> May 20: final release
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>
>>>>>>> That works for me. There may be a few items in
>>>>>>> https://github.com/scipy/scipy/milestone/37 that we won't get to,
>>>>>>> but the only real blocker (py37 build issue) on that list is ready to merge.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ralf
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mark Mikofski, PhD (2005)
>>>>>> *Fiat Lux*
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Haberland
>>>>> Assistant Adjunct Professor in the Program in Computing
>>>>> Department of Mathematics
>>>>> 6617A Math Sciences Building, UCLA
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> Mark Mikofski, PhD (2005)
>>>> *Fiat Lux*
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190425/7d263292/attachment.html>

From tyler.je.reddy at gmail.com  Thu Apr 25 19:18:07 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Thu, 25 Apr 2019 16:18:07 -0700
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CAHPuU_Y68Varm-rvOFzsKE0hA3xEtvjtNE7pDcyUf-U-FGRQEw@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
 <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
 <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>
 <CAEqRcW27eWa_ypS9wU-2UXuQ7mZDCyhBpHzvWOpHDS2Aza19Nw@mail.gmail.com>
 <CADuxUixwV-9G8-PaLnL+M=TSsyE7_nPWMTdGe+k34pXN=tHm5w@mail.gmail.com>
 <CAEqRcW1R5jCuP51aJe3N-s+YaGuCA-FVjK-bYL2_N8V7Y=PqHw@mail.gmail.com>
 <CABL7CQjzT+nZDK8cZSMWHc8QAc_NrGA8CCzFTgGHL2EoYi+Q-Q@mail.gmail.com>
 <CAHPuU_bGtsX=DLn8=G_p+31vwwrxuwBTWS5gdpy3o5h9j=PymA@mail.gmail.com>
 <CAHPuU_a0fMpLp-pA9w7KRx0hEdAnS7ukgMgsk32iJL6OwDxkEw@mail.gmail.com>
 <CAHPuU_Y68Varm-rvOFzsKE0hA3xEtvjtNE7pDcyUf-U-FGRQEw@mail.gmail.com>
Message-ID: <CAHPuU_aXcwo45Pwp_cCPyWxYq2dkr2Qafb5Gf1zNkzBoyLXQwA@mail.gmail.com>

The release notes / mailmap PR is open, please do have a look at your
attribution as appropriate: https://github.com/scipy/scipy/pull/10097

On Thu, 25 Apr 2019 at 10:59, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:

> There should be no open issues / PRs with the 1.3.0 milestone now. I'm
> going to work on improving the release notes for a while & open a PR for
> that soon-ish.
>
> On Tue, 23 Apr 2019 at 15:31, Tyler Reddy <tyler.je.reddy at gmail.com>
> wrote:
>
>> Down to 5 open PRs with the 1.3.0 milestone:
>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0
>>
>>
>>
>> On Fri, 19 Apr 2019 at 17:54, Tyler Reddy <tyler.je.reddy at gmail.com>
>> wrote:
>>
>>> We are sitting at 20 open PRs with the 1.3.0 milestone:
>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0
>>>
>>> We were close to 30 recently, so let's try to keep it < 20 over the
>>> weekend / moving into next week.
>>>
>>> On Fri, 19 Apr 2019 at 02:48, Ralf Gommers <ralf.gommers at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Apr 19, 2019 at 9:34 AM Mark Mikofski <mikofski at berkeley.edu>
>>>> wrote:
>>>>
>>>>> Hi Tyler,
>>>>>
>>>>> Thanks again for taking on the release management.
>>>>>
>>>>> Is there anything that we (as contributors) can do to help? Should we
>>>>> be reviewing the 1.3.0 milestone PR's? What would be most helpful
>>>>> specifically?
>>>>>
>>>>
>>>> Help with reviewing can be a very valuable contribution, not just for a
>>>> particular release but in general. I think many contributors are under the
>>>> impression that you need to be a maintainer to review - this definitely
>>>> isn't the case, as long as you have the knowledge to understand the code in
>>>> a PR you can help a lot. In particular this is the case for larger PRs that
>>>> propose new features, because those are often a lot of work to review and
>>>> require domain-specific knowledge. Here is an example (also tagged for
>>>> 1.3.0): https://github.com/scipy/scipy/pull/7310, adding a logarithmic
>>>> FFT implementation. Two kinds of things would be helpful:
>>>> - someone who understands FFTs well and can review the implementation
>>>> - someone who needs the feature, and can test it and confirm that
>>>> everything works as expected
>>>>
>>>> A couple more in the same vein:
>>>> - peak declustering for scipy.signal:
>>>> https://github.com/scipy/scipy/pull/9513
>>>> - RotationSpline for scipy.spatial.transform:
>>>> https://github.com/scipy/scipy/pull/9831
>>>> - support for ARFF relational attributes in scipy.io:
>>>> https://github.com/scipy/scipy/pull/9854
>>>>
>>>> Cheers,
>>>> Ralf
>>>>
>>>>
>>>>> I read through the dev guide (
>>>>> https://docs.scipy.org/doc/scipy/reference/dev/index.html) and
>>>>> hacking guidelines (
>>>>> https://docs.scipy.org/doc/scipy/reference/hacking.html), and I
>>>>> looked at the 1.3.0 milestones, and it seems like reviewing PR's with the
>>>>> fewest comments might be the best approach. Would that help?
>>>>>
>>>>> Cheers,
>>>>> Mark
>>>>>
>>>>> On Sun, Apr 14, 2019 at 5:42 PM Matt Haberland <haberland at ucla.edu>
>>>>> wrote:
>>>>>
>>>>>> I'd like to get #10026 in there, too. SuiteSparse seems to routinely
>>>>>> speed up `linprog` by a factor of 2-4 (when available).
>>>>>>
>>>>>> On Sun, Apr 14, 2019 at 7:40 AM Mark Alexander Mikofski <
>>>>>> mikofski at berkeley.edu> wrote:
>>>>>>
>>>>>>> Hi Tyler,
>>>>>>>
>>>>>>> Thanks for managing the release again! This is a very important
>>>>>>> service for the SciPy community, and I'm very grateful!
>>>>>>>
>>>>>>> Do you think we could try to add #9568 and #10052 assuming everyone
>>>>>>> agrees they are good?
>>>>>>>
>>>>>>> thanks again!
>>>>>>> Mark
>>>>>>>
>>>>>>> On Sun, Apr 14, 2019 at 2:13 AM Ralf Gommers <ralf.gommers at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Apr 14, 2019 at 12:27 AM Andrew Nelson <andyfaff at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Would it be possible to add 9990 and 10002 to 1.3.0, or is that
>>>>>>>>> too ambitious?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Those look like they're in good shape, should be doable. I've added
>>>>>>>> them to the milestone. Tyler can always remove them again if we run out of
>>>>>>>> time.
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <
>>>>>>>>> tyler.je.reddy at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> It is almost 4 months after the (slightly-delayed) 1.2.0 release
>>>>>>>>>> on December 17/ 2018, so probably time to plan the 1.3.0 release. It would
>>>>>>>>>> be a good idea to look over the PRs with a 1.3.0 milestone, and tag
>>>>>>>>>> anything else that should have this milestone appropriately.
>>>>>>>>>>
>>>>>>>>>> I'd like to propose the following schedule:
>>>>>>>>>>
>>>>>>>>>> April 25: branch 1.3.x
>>>>>>>>>> April 28: rc1
>>>>>>>>>> May 11: rc2 (if needed)
>>>>>>>>>> May 20: final release
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> That works for me. There may be a few items in
>>>>>>>> https://github.com/scipy/scipy/milestone/37 that we won't get to,
>>>>>>>> but the only real blocker (py37 build issue) on that list is ready to merge.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Ralf
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mark Mikofski, PhD (2005)
>>>>>>> *Fiat Lux*
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Haberland
>>>>>> Assistant Adjunct Professor in the Program in Computing
>>>>>> Department of Mathematics
>>>>>> 6617A Math Sciences Building, UCLA
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mark Mikofski, PhD (2005)
>>>>> *Fiat Lux*
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190425/adb3b4c8/attachment-0001.html>

From tyler.je.reddy at gmail.com  Fri Apr 26 00:50:58 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Thu, 25 Apr 2019 21:50:58 -0700
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CAHPuU_aXcwo45Pwp_cCPyWxYq2dkr2Qafb5Gf1zNkzBoyLXQwA@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
 <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
 <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>
 <CAEqRcW27eWa_ypS9wU-2UXuQ7mZDCyhBpHzvWOpHDS2Aza19Nw@mail.gmail.com>
 <CADuxUixwV-9G8-PaLnL+M=TSsyE7_nPWMTdGe+k34pXN=tHm5w@mail.gmail.com>
 <CAEqRcW1R5jCuP51aJe3N-s+YaGuCA-FVjK-bYL2_N8V7Y=PqHw@mail.gmail.com>
 <CABL7CQjzT+nZDK8cZSMWHc8QAc_NrGA8CCzFTgGHL2EoYi+Q-Q@mail.gmail.com>
 <CAHPuU_bGtsX=DLn8=G_p+31vwwrxuwBTWS5gdpy3o5h9j=PymA@mail.gmail.com>
 <CAHPuU_a0fMpLp-pA9w7KRx0hEdAnS7ukgMgsk32iJL6OwDxkEw@mail.gmail.com>
 <CAHPuU_Y68Varm-rvOFzsKE0hA3xEtvjtNE7pDcyUf-U-FGRQEw@mail.gmail.com>
 <CAHPuU_aXcwo45Pwp_cCPyWxYq2dkr2Qafb5Gf1zNkzBoyLXQwA@mail.gmail.com>
Message-ID: <CAHPuU_YEzhD5optup7jF+ZfF9B+KCL47S5e+kq9=urMHfpvRHQ@mail.gmail.com>

There have been some helpful comments on the release notes, but there are
sufficient revisions requested that I'll likely delay completion / merge of
that PR until morning of April 26 (tomorrow). Please be mindful merging PRs
until the notes get merged & I cut the branch, thanks :)

On Thu, 25 Apr 2019 at 16:18, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:

> The release notes / mailmap PR is open, please do have a look at your
> attribution as appropriate: https://github.com/scipy/scipy/pull/10097
>
> On Thu, 25 Apr 2019 at 10:59, Tyler Reddy <tyler.je.reddy at gmail.com>
> wrote:
>
>> There should be no open issues / PRs with the 1.3.0 milestone now. I'm
>> going to work on improving the release notes for a while & open a PR for
>> that soon-ish.
>>
>> On Tue, 23 Apr 2019 at 15:31, Tyler Reddy <tyler.je.reddy at gmail.com>
>> wrote:
>>
>>> Down to 5 open PRs with the 1.3.0 milestone:
>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0
>>>
>>>
>>>
>>> On Fri, 19 Apr 2019 at 17:54, Tyler Reddy <tyler.je.reddy at gmail.com>
>>> wrote:
>>>
>>>> We are sitting at 20 open PRs with the 1.3.0 milestone:
>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0
>>>>
>>>> We were close to 30 recently, so let's try to keep it < 20 over the
>>>> weekend / moving into next week.
>>>>
>>>> On Fri, 19 Apr 2019 at 02:48, Ralf Gommers <ralf.gommers at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 19, 2019 at 9:34 AM Mark Mikofski <mikofski at berkeley.edu>
>>>>> wrote:
>>>>>
>>>>>> Hi Tyler,
>>>>>>
>>>>>> Thanks again for taking on the release management.
>>>>>>
>>>>>> Is there anything that we (as contributors) can do to help? Should we
>>>>>> be reviewing the 1.3.0 milestone PR's? What would be most helpful
>>>>>> specifically?
>>>>>>
>>>>>
>>>>> Help with reviewing can be a very valuable contribution, not just for
>>>>> a particular release but in general. I think many contributors are under
>>>>> the impression that you need to be a maintainer to review - this definitely
>>>>> isn't the case, as long as you have the knowledge to understand the code in
>>>>> a PR you can help a lot. In particular this is the case for larger PRs that
>>>>> propose new features, because those are often a lot of work to review and
>>>>> require domain-specific knowledge. Here is an example (also tagged for
>>>>> 1.3.0): https://github.com/scipy/scipy/pull/7310, adding a
>>>>> logarithmic FFT implementation. Two kinds of things would be helpful:
>>>>> - someone who understands FFTs well and can review the implementation
>>>>> - someone who needs the feature, and can test it and confirm that
>>>>> everything works as expected
>>>>>
>>>>> A couple more in the same vein:
>>>>> - peak declustering for scipy.signal:
>>>>> https://github.com/scipy/scipy/pull/9513
>>>>> - RotationSpline for scipy.spatial.transform:
>>>>> https://github.com/scipy/scipy/pull/9831
>>>>> - support for ARFF relational attributes in scipy.io:
>>>>> https://github.com/scipy/scipy/pull/9854
>>>>>
>>>>> Cheers,
>>>>> Ralf
>>>>>
>>>>>
>>>>>> I read through the dev guide (
>>>>>> https://docs.scipy.org/doc/scipy/reference/dev/index.html) and
>>>>>> hacking guidelines (
>>>>>> https://docs.scipy.org/doc/scipy/reference/hacking.html), and I
>>>>>> looked at the 1.3.0 milestones, and it seems like reviewing PR's with the
>>>>>> fewest comments might be the best approach. Would that help?
>>>>>>
>>>>>> Cheers,
>>>>>> Mark
>>>>>>
>>>>>> On Sun, Apr 14, 2019 at 5:42 PM Matt Haberland <haberland at ucla.edu>
>>>>>> wrote:
>>>>>>
>>>>>>> I'd like to get #10026 in there, too. SuiteSparse seems to routinely
>>>>>>> speed up `linprog` by a factor of 2-4 (when available).
>>>>>>>
>>>>>>> On Sun, Apr 14, 2019 at 7:40 AM Mark Alexander Mikofski <
>>>>>>> mikofski at berkeley.edu> wrote:
>>>>>>>
>>>>>>>> Hi Tyler,
>>>>>>>>
>>>>>>>> Thanks for managing the release again! This is a very important
>>>>>>>> service for the SciPy community, and I'm very grateful!
>>>>>>>>
>>>>>>>> Do you think we could try to add #9568 and #10052 assuming everyone
>>>>>>>> agrees they are good?
>>>>>>>>
>>>>>>>> thanks again!
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> On Sun, Apr 14, 2019 at 2:13 AM Ralf Gommers <
>>>>>>>> ralf.gommers at gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Apr 14, 2019 at 12:27 AM Andrew Nelson <andyfaff at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Would it be possible to add 9990 and 10002 to 1.3.0, or is that
>>>>>>>>>> too ambitious?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Those look like they're in good shape, should be doable. I've
>>>>>>>>> added them to the milestone. Tyler can always remove them again if we run
>>>>>>>>> out of time.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <
>>>>>>>>>> tyler.je.reddy at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> It is almost 4 months after the (slightly-delayed) 1.2.0 release
>>>>>>>>>>> on December 17/ 2018, so probably time to plan the 1.3.0 release. It would
>>>>>>>>>>> be a good idea to look over the PRs with a 1.3.0 milestone, and tag
>>>>>>>>>>> anything else that should have this milestone appropriately.
>>>>>>>>>>>
>>>>>>>>>>> I'd like to propose the following schedule:
>>>>>>>>>>>
>>>>>>>>>>> April 25: branch 1.3.x
>>>>>>>>>>> April 28: rc1
>>>>>>>>>>> May 11: rc2 (if needed)
>>>>>>>>>>> May 20: final release
>>>>>>>>>>>
>>>>>>>>>>> Thoughts?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> That works for me. There may be a few items in
>>>>>>>>> https://github.com/scipy/scipy/milestone/37 that we won't get to,
>>>>>>>>> but the only real blocker (py37 build issue) on that list is ready to merge.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Ralf
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Mark Mikofski, PhD (2005)
>>>>>>>> *Fiat Lux*
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Haberland
>>>>>>> Assistant Adjunct Professor in the Program in Computing
>>>>>>> Department of Mathematics
>>>>>>> 6617A Math Sciences Building, UCLA
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mark Mikofski, PhD (2005)
>>>>>> *Fiat Lux*
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190425/d8e443d4/attachment.html>

From tyler.je.reddy at gmail.com  Fri Apr 26 13:49:17 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Fri, 26 Apr 2019 10:49:17 -0700
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CAHPuU_YEzhD5optup7jF+ZfF9B+KCL47S5e+kq9=urMHfpvRHQ@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
 <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
 <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>
 <CAEqRcW27eWa_ypS9wU-2UXuQ7mZDCyhBpHzvWOpHDS2Aza19Nw@mail.gmail.com>
 <CADuxUixwV-9G8-PaLnL+M=TSsyE7_nPWMTdGe+k34pXN=tHm5w@mail.gmail.com>
 <CAEqRcW1R5jCuP51aJe3N-s+YaGuCA-FVjK-bYL2_N8V7Y=PqHw@mail.gmail.com>
 <CABL7CQjzT+nZDK8cZSMWHc8QAc_NrGA8CCzFTgGHL2EoYi+Q-Q@mail.gmail.com>
 <CAHPuU_bGtsX=DLn8=G_p+31vwwrxuwBTWS5gdpy3o5h9j=PymA@mail.gmail.com>
 <CAHPuU_a0fMpLp-pA9w7KRx0hEdAnS7ukgMgsk32iJL6OwDxkEw@mail.gmail.com>
 <CAHPuU_Y68Varm-rvOFzsKE0hA3xEtvjtNE7pDcyUf-U-FGRQEw@mail.gmail.com>
 <CAHPuU_aXcwo45Pwp_cCPyWxYq2dkr2Qafb5Gf1zNkzBoyLXQwA@mail.gmail.com>
 <CAHPuU_YEzhD5optup7jF+ZfF9B+KCL47S5e+kq9=urMHfpvRHQ@mail.gmail.com>
Message-ID: <CAHPuU_aRLWVZUmiJG5fNy6muW3c-0t-pUmKJc3Z1OhwbnXyPxA@mail.gmail.com>

SciPy 1.3.x was branched (not released) at 9:40 am Pacific on April 26/ 2019
Master branch is now open for the development of SciPy 1.4.0

On Thu, 25 Apr 2019 at 21:50, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:

> There have been some helpful comments on the release notes, but there are
> sufficient revisions requested that I'll likely delay completion / merge of
> that PR until morning of April 26 (tomorrow). Please be mindful merging PRs
> until the notes get merged & I cut the branch, thanks :)
>
> On Thu, 25 Apr 2019 at 16:18, Tyler Reddy <tyler.je.reddy at gmail.com>
> wrote:
>
>> The release notes / mailmap PR is open, please do have a look at your
>> attribution as appropriate: https://github.com/scipy/scipy/pull/10097
>>
>> On Thu, 25 Apr 2019 at 10:59, Tyler Reddy <tyler.je.reddy at gmail.com>
>> wrote:
>>
>>> There should be no open issues / PRs with the 1.3.0 milestone now. I'm
>>> going to work on improving the release notes for a while & open a PR for
>>> that soon-ish.
>>>
>>> On Tue, 23 Apr 2019 at 15:31, Tyler Reddy <tyler.je.reddy at gmail.com>
>>> wrote:
>>>
>>>> Down to 5 open PRs with the 1.3.0 milestone:
>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0
>>>>
>>>>
>>>>
>>>> On Fri, 19 Apr 2019 at 17:54, Tyler Reddy <tyler.je.reddy at gmail.com>
>>>> wrote:
>>>>
>>>>> We are sitting at 20 open PRs with the 1.3.0 milestone:
>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0
>>>>>
>>>>> We were close to 30 recently, so let's try to keep it < 20 over the
>>>>> weekend / moving into next week.
>>>>>
>>>>> On Fri, 19 Apr 2019 at 02:48, Ralf Gommers <ralf.gommers at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Apr 19, 2019 at 9:34 AM Mark Mikofski <mikofski at berkeley.edu>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Tyler,
>>>>>>>
>>>>>>> Thanks again for taking on the release management.
>>>>>>>
>>>>>>> Is there anything that we (as contributors) can do to help? Should
>>>>>>> we be reviewing the 1.3.0 milestone PR's? What would be most helpful
>>>>>>> specifically?
>>>>>>>
>>>>>>
>>>>>> Help with reviewing can be a very valuable contribution, not just for
>>>>>> a particular release but in general. I think many contributors are under
>>>>>> the impression that you need to be a maintainer to review - this definitely
>>>>>> isn't the case, as long as you have the knowledge to understand the code in
>>>>>> a PR you can help a lot. In particular this is the case for larger PRs that
>>>>>> propose new features, because those are often a lot of work to review and
>>>>>> require domain-specific knowledge. Here is an example (also tagged for
>>>>>> 1.3.0): https://github.com/scipy/scipy/pull/7310, adding a
>>>>>> logarithmic FFT implementation. Two kinds of things would be helpful:
>>>>>> - someone who understands FFTs well and can review the implementation
>>>>>> - someone who needs the feature, and can test it and confirm that
>>>>>> everything works as expected
>>>>>>
>>>>>> A couple more in the same vein:
>>>>>> - peak declustering for scipy.signal:
>>>>>> https://github.com/scipy/scipy/pull/9513
>>>>>> - RotationSpline for scipy.spatial.transform:
>>>>>> https://github.com/scipy/scipy/pull/9831
>>>>>> - support for ARFF relational attributes in scipy.io:
>>>>>> https://github.com/scipy/scipy/pull/9854
>>>>>>
>>>>>> Cheers,
>>>>>> Ralf
>>>>>>
>>>>>>
>>>>>>> I read through the dev guide (
>>>>>>> https://docs.scipy.org/doc/scipy/reference/dev/index.html) and
>>>>>>> hacking guidelines (
>>>>>>> https://docs.scipy.org/doc/scipy/reference/hacking.html), and I
>>>>>>> looked at the 1.3.0 milestones, and it seems like reviewing PR's with the
>>>>>>> fewest comments might be the best approach. Would that help?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Mark
>>>>>>>
>>>>>>> On Sun, Apr 14, 2019 at 5:42 PM Matt Haberland <haberland at ucla.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I'd like to get #10026 in there, too. SuiteSparse seems to
>>>>>>>> routinely speed up `linprog` by a factor of 2-4 (when available).
>>>>>>>>
>>>>>>>> On Sun, Apr 14, 2019 at 7:40 AM Mark Alexander Mikofski <
>>>>>>>> mikofski at berkeley.edu> wrote:
>>>>>>>>
>>>>>>>>> Hi Tyler,
>>>>>>>>>
>>>>>>>>> Thanks for managing the release again! This is a very important
>>>>>>>>> service for the SciPy community, and I'm very grateful!
>>>>>>>>>
>>>>>>>>> Do you think we could try to add #9568 and #10052 assuming
>>>>>>>>> everyone agrees they are good?
>>>>>>>>>
>>>>>>>>> thanks again!
>>>>>>>>> Mark
>>>>>>>>>
>>>>>>>>> On Sun, Apr 14, 2019 at 2:13 AM Ralf Gommers <
>>>>>>>>> ralf.gommers at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, Apr 14, 2019 at 12:27 AM Andrew Nelson <
>>>>>>>>>> andyfaff at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Would it be possible to add 9990 and 10002 to 1.3.0, or is that
>>>>>>>>>>> too ambitious?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Those look like they're in good shape, should be doable. I've
>>>>>>>>>> added them to the milestone. Tyler can always remove them again if we run
>>>>>>>>>> out of time.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <
>>>>>>>>>>> tyler.je.reddy at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> It is almost 4 months after the (slightly-delayed) 1.2.0
>>>>>>>>>>>> release on December 17/ 2018, so probably time to plan the 1.3.0 release.
>>>>>>>>>>>> It would be a good idea to look over the PRs with a 1.3.0 milestone, and
>>>>>>>>>>>> tag anything else that should have this milestone appropriately.
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to propose the following schedule:
>>>>>>>>>>>>
>>>>>>>>>>>> April 25: branch 1.3.x
>>>>>>>>>>>> April 28: rc1
>>>>>>>>>>>> May 11: rc2 (if needed)
>>>>>>>>>>>> May 20: final release
>>>>>>>>>>>>
>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> That works for me. There may be a few items in
>>>>>>>>>> https://github.com/scipy/scipy/milestone/37 that we won't get
>>>>>>>>>> to, but the only real blocker (py37 build issue) on that list is ready to
>>>>>>>>>> merge.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Ralf
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Mark Mikofski, PhD (2005)
>>>>>>>>> *Fiat Lux*
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Haberland
>>>>>>>> Assistant Adjunct Professor in the Program in Computing
>>>>>>>> Department of Mathematics
>>>>>>>> 6617A Math Sciences Building, UCLA
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mark Mikofski, PhD (2005)
>>>>>>> *Fiat Lux*
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190426/31da204e/attachment.html>

From tyler.je.reddy at gmail.com  Fri Apr 26 19:13:01 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Fri, 26 Apr 2019 16:13:01 -0700
Subject: [SciPy-Dev] [ANN] Release of scikit-spatial package
In-Reply-To: <CAHPuU_YA=cWOs2agguvXSmRqn0UhHVbwPSyBLZjiBa9Ztk0+5A@mail.gmail.com>
References: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
 <555a5a21-6a0a-4bf5-ba6f-83361c7f840a@www.fastmail.com>
 <CAD-yzHZJSDvJsXQorZtAtqRpgANR35UN9fbE_2gmKKnUm1qkjQ@mail.gmail.com>
 <CAHPuU_aCzr+t1vgP_JaBYLP1gQQLMkBReS-1pvrHoKwdZykoYA@mail.gmail.com>
 <CAD-yzHZc2WL4kmxJO6_MAUODLDdKio93+jekTYfyyDuf2fC3cQ@mail.gmail.com>
 <CAHPuU_YA=cWOs2agguvXSmRqn0UhHVbwPSyBLZjiBa9Ztk0+5A@mail.gmail.com>
Message-ID: <CAHPuU_b2MSPrqUyff+eEB8C6yjPWhWtoLyZFvr+JXvpVAccD0Q@mail.gmail.com>

One more follow-up thought -- are_collinear() appears to provide a simple
bool return value for a set of coordinates in your Points class. But what
if you had an array of 2 million points and you wanted to know the
*indices* of *any* points that were collinear with any other?

That might be interesting if it could be done more efficiently than brute
force? Then you could exclude said collinear points and feed them into a
comp geo algorithm. Someone must have thought of this already.



On Fri, 26 Apr 2019 at 16:04, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:

> I've thought a little more about this. I didn't come up with a great first
> choice for migrating functionality into scipy.spatial just yet, but this
> was my thought process for one of your methods, are_collinear():
>
> - the boolean return value may be useful for assessments of general
> position in computational geometry, for rejection of array input to other
> algorithms / functions by fiat
> - the main problem is that the algorithm is effectively a NumPy one-liner
> on array-input: numpy.linalg.matrix_rank(input) <= 1
> - before I realized that, I also considered how you might transplant it if
> relative simplicity were not an issue for a new public SciPy function
> - I would suggest avoiding the object-oriented / ndarray subclassing
> approach used in the scikit & matching our scipy.spatial distance-style
> approach which generally takes an array-like into a simple function &
> operates on it / returns something directly; avoiding ndarray subclassing
> will probably reduce the controversy of a PR
>
> So, not sure how helpful that is. I think the initial assessment on
> collinear is: 1) very useful; but 2) perhaps a little too simple to justify
> an exposed / new SciPy function?
>
> Perhaps that evaluation strategy (usefulness + non-trivial implementation;
> avoiding ndarray subclasses) may help you select the right candidate for
> migrating over to SciPy? Others may have different thoughts though.
>
> On Wed, 10 Apr 2019 at 19:17, Andrew Hynes <andrewjhynes at gmail.com> wrote:
>
>> Hello Tyler,
>>
>> Some of the algorithms might be suitable for inclusion. Probably easier
>>> if there's a nice paper / source for algorithm citation and it is clear
>>> that we don't already have the functionality somewhere in SciPy.
>>>
>>
>> My main reference for the functions has been
>> http://mathworld.wolfram.com/. Some of the docstrings have a link to the
>> relevant webpage.
>>
>> I'd like to try making a pull request for scipy.spatial. Is there an area
>> of scikit-spatial that you think would be best to start?
>>
>> Also, would you prefer that the code is not object-oriented? For example,
>> the collinearity function is a method of the Points class, but I can adapt
>> it to be a regular function that takes a 2D ndarray as input. Or if you're
>> fine with the object oriented style, I can work on a pull request to
>> include the Point and Vector classes, which could be imported from a
>> scipy.spatial.objects module.
>>
>> Thanks,
>>
>> Andrew
>>
>>
>> On Tue, Apr 9, 2019 at 2:05 PM Tyler Reddy <tyler.je.reddy at gmail.com>
>> wrote:
>>
>>> Some of the algorithms might be suitable for inclusion. Probably easier
>>> if there's a nice paper / source for algorithm citation and it is clear
>>> that we don't already have the functionality somewhere in SciPy.
>>>
>>> To give one example, just browsing through, I see a collinearity
>>> algorithm. Since collinearity is often used in the assessment of general
>>> position prior to embarking on an algorithm in computational geometry,
>>> it may be sensible to check if the low-level library we vendor for many
>>> comp geo routines (Qhull) has a routine for this. Even if it does, it might
>>> not be easy to expose directly, but it is a consideration I think.
>>>
>>> Some of the operations, if ultimately suitable for inclusion, may fit in
>>> the scipy.spatial.transform namespace, but probably case-by-case basis is
>>> best in terms of assessing broad interest in the algorithm
>>> and its suitability for inclusion.
>>>
>>> On Mon, 8 Apr 2019 at 16:08, Andrew Hynes <andrewjhynes at gmail.com>
>>> wrote:
>>>
>>>> Hi St?fan,
>>>>
>>>>> This looks neat!  It reminds me a bit of the following book which I
>>>>> enjoyed:
>>>>>
>>>>> http://www.geometricalgebra.net/
>>>>>
>>>>
>>>> Thanks for the link - it looks like a good source for expanding the
>>>> package.
>>>>
>>>> Can you tell us a bit more about how you see these functions typically
>>>>> being applied in practice?
>>>>>
>>>> Sure, I can give an example from my masters project. It involved
>>>> clinical gait analysis with a depth camera, so I used some of these
>>>> functions to calculate gait parameters from positions in space.
>>>>
>>>> A basic walking stride consists of three positions: The initial swing
>>>> foot, the stance foot, and the final swing foot. The stride length is the
>>>> distance from the initial to final swing foot. The stride width is the
>>>> length of the projection from the stance foot to the swing path (the line
>>>> from the initial swing foot to the final).
>>>>
>>>> Here's a snippet of code using scikit-spatial to calculate gait
>>>> parameters from three points: point_a_i (initial swing foot), point_b
>>>> (stance foot), and point_a_f (final swing foot).
>>>>
>>>> from skspatial.objects import Vector, Line
>>>>
>>>> vector_a = Vector.from_points(point_a_i, point_a_f)
>>>> line_a = Line(point=point_a_i, direction=vector_a)
>>>>
>>>> point_b_proj = line_a.project_point(point_b)
>>>>
>>>> stride_length = vector_a.norm()
>>>> absolute_step_length = Vector.from_points(point_b, point_a_f).norm()
>>>> step_length = Vector.from_points(point_b_proj, point_a_f).norm()
>>>> stride_width = line_a.distance_point(point_b)
>>>>
>>>>
>>>> Hopefully that gives an idea as to how the package can be used.
>>>>
>>>> Thanks,
>>>>
>>>> Andrew
>>>>
>>>> P. S. Great job on scikit-image!
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190426/0a10d3c2/attachment-0001.html>

From tyler.je.reddy at gmail.com  Fri Apr 26 19:04:06 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Fri, 26 Apr 2019 16:04:06 -0700
Subject: [SciPy-Dev] [ANN] Release of scikit-spatial package
In-Reply-To: <CAD-yzHZc2WL4kmxJO6_MAUODLDdKio93+jekTYfyyDuf2fC3cQ@mail.gmail.com>
References: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
 <555a5a21-6a0a-4bf5-ba6f-83361c7f840a@www.fastmail.com>
 <CAD-yzHZJSDvJsXQorZtAtqRpgANR35UN9fbE_2gmKKnUm1qkjQ@mail.gmail.com>
 <CAHPuU_aCzr+t1vgP_JaBYLP1gQQLMkBReS-1pvrHoKwdZykoYA@mail.gmail.com>
 <CAD-yzHZc2WL4kmxJO6_MAUODLDdKio93+jekTYfyyDuf2fC3cQ@mail.gmail.com>
Message-ID: <CAHPuU_YA=cWOs2agguvXSmRqn0UhHVbwPSyBLZjiBa9Ztk0+5A@mail.gmail.com>

I've thought a little more about this. I didn't come up with a great first
choice for migrating functionality into scipy.spatial just yet, but this
was my thought process for one of your methods, are_collinear():

- the boolean return value may be useful for assessments of general
position in computational geometry, for rejection of array input to other
algorithms / functions by fiat
- the main problem is that the algorithm is effectively a NumPy one-liner
on array-input: numpy.linalg.matrix_rank(input) <= 1
- before I realized that, I also considered how you might transplant it if
relative simplicity were not an issue for a new public SciPy function
- I would suggest avoiding the object-oriented / ndarray subclassing
approach used in the scikit & matching our scipy.spatial distance-style
approach which generally takes an array-like into a simple function &
operates on it / returns something directly; avoiding ndarray subclassing
will probably reduce the controversy of a PR

So, not sure how helpful that is. I think the initial assessment on
collinear is: 1) very useful; but 2) perhaps a little too simple to justify
an exposed / new SciPy function?

Perhaps that evaluation strategy (usefulness + non-trivial implementation;
avoiding ndarray subclasses) may help you select the right candidate for
migrating over to SciPy? Others may have different thoughts though.

On Wed, 10 Apr 2019 at 19:17, Andrew Hynes <andrewjhynes at gmail.com> wrote:

> Hello Tyler,
>
> Some of the algorithms might be suitable for inclusion. Probably easier if
>> there's a nice paper / source for algorithm citation and it is clear that
>> we don't already have the functionality somewhere in SciPy.
>>
>
> My main reference for the functions has been http://mathworld.wolfram.com/.
> Some of the docstrings have a link to the relevant webpage.
>
> I'd like to try making a pull request for scipy.spatial. Is there an area
> of scikit-spatial that you think would be best to start?
>
> Also, would you prefer that the code is not object-oriented? For example,
> the collinearity function is a method of the Points class, but I can adapt
> it to be a regular function that takes a 2D ndarray as input. Or if you're
> fine with the object oriented style, I can work on a pull request to
> include the Point and Vector classes, which could be imported from a
> scipy.spatial.objects module.
>
> Thanks,
>
> Andrew
>
>
> On Tue, Apr 9, 2019 at 2:05 PM Tyler Reddy <tyler.je.reddy at gmail.com>
> wrote:
>
>> Some of the algorithms might be suitable for inclusion. Probably easier
>> if there's a nice paper / source for algorithm citation and it is clear
>> that we don't already have the functionality somewhere in SciPy.
>>
>> To give one example, just browsing through, I see a collinearity
>> algorithm. Since collinearity is often used in the assessment of general
>> position prior to embarking on an algorithm in computational geometry,
>> it may be sensible to check if the low-level library we vendor for many
>> comp geo routines (Qhull) has a routine for this. Even if it does, it might
>> not be easy to expose directly, but it is a consideration I think.
>>
>> Some of the operations, if ultimately suitable for inclusion, may fit in
>> the scipy.spatial.transform namespace, but probably case-by-case basis is
>> best in terms of assessing broad interest in the algorithm
>> and its suitability for inclusion.
>>
>> On Mon, 8 Apr 2019 at 16:08, Andrew Hynes <andrewjhynes at gmail.com> wrote:
>>
>>> Hi St?fan,
>>>
>>>> This looks neat!  It reminds me a bit of the following book which I
>>>> enjoyed:
>>>>
>>>> http://www.geometricalgebra.net/
>>>>
>>>
>>> Thanks for the link - it looks like a good source for expanding the
>>> package.
>>>
>>> Can you tell us a bit more about how you see these functions typically
>>>> being applied in practice?
>>>>
>>> Sure, I can give an example from my masters project. It involved
>>> clinical gait analysis with a depth camera, so I used some of these
>>> functions to calculate gait parameters from positions in space.
>>>
>>> A basic walking stride consists of three positions: The initial swing
>>> foot, the stance foot, and the final swing foot. The stride length is the
>>> distance from the initial to final swing foot. The stride width is the
>>> length of the projection from the stance foot to the swing path (the line
>>> from the initial swing foot to the final).
>>>
>>> Here's a snippet of code using scikit-spatial to calculate gait
>>> parameters from three points: point_a_i (initial swing foot), point_b
>>> (stance foot), and point_a_f (final swing foot).
>>>
>>> from skspatial.objects import Vector, Line
>>>
>>> vector_a = Vector.from_points(point_a_i, point_a_f)
>>> line_a = Line(point=point_a_i, direction=vector_a)
>>>
>>> point_b_proj = line_a.project_point(point_b)
>>>
>>> stride_length = vector_a.norm()
>>> absolute_step_length = Vector.from_points(point_b, point_a_f).norm()
>>> step_length = Vector.from_points(point_b_proj, point_a_f).norm()
>>> stride_width = line_a.distance_point(point_b)
>>>
>>>
>>> Hopefully that gives an idea as to how the package can be used.
>>>
>>> Thanks,
>>>
>>> Andrew
>>>
>>> P. S. Great job on scikit-image!
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190426/37a8b7da/attachment.html>

From tyler.je.reddy at gmail.com  Fri Apr 26 21:25:19 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Fri, 26 Apr 2019 18:25:19 -0700
Subject: [SciPy-Dev] ANN: SciPy 1.3.0rc1 -- please test
Message-ID: <CAHPuU_Y5wAntg1FnpR1fowzN7J1e+WD7P1RMRh-A3bVBJsb3qQ@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

On behalf of the SciPy development team I'm pleased to announce
the release candidate SciPy 1.3.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.3.0rc1
One of a few ways to install the release candidate with pip:
pip install scipy==1.3.0rc1

==========================
SciPy 1.3.0 Release Notes
==========================

Note: Scipy 1.3.0 is not released yet!

SciPy 1.3.0 is the culmination of 5 months of hard work. It contains
many new features, numerous bug-fixes, improved test coverage and better
documentation. There have been some 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.3.x branch, and on adding new features on the master branch.

This release requires Python 3.5+ and NumPy 1.13.3 or greater.

For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required.

Highlights of this release
--------------------------

- Three new ``stats`` functions, a rewrite of ``pearsonr``, and an exact
  computation of the Kolmogorov-Smirnov two-sample test
- A new Cython API for bounded scalar-function root-finders in `scipy.optimize`
- Substantial ``CSR`` and ``CSC`` sparse matrix indexing performance
  improvements
- Added support for interpolation of rotations with continuous angular
  rate and acceleration in ``RotationSpline``


New features
============

`scipy.interpolate` improvements
--------------------------------

A new class ``CubicHermiteSpline`` is introduced. It is a piecewise-cubic
interpolator which matches observed values and first derivatives. Existing
cubic interpolators ``CubicSpline``, ``PchipInterpolator`` and
``Akima1DInterpolator`` were made subclasses of ``CubicHermiteSpline``.

`scipy.io` improvements
-----------------------

For the Attribute-Relation File Format (ARFF) `scipy.io.arff.loadarff`
now supports relational attributes.

`scipy.io.mmread` can now parse Matrix Market format files with empty lines.

`scipy.linalg` improvements
---------------------------

Added wrappers for ``?syconv`` routines, which convert a symmetric matrix
given by a triangular matrix factorization into two matrices and vice versa.

`scipy.linalg.clarkson_woodruff_transform` now uses an algorithm that leverages
sparsity. This may provide a 60-90 percent speedup for dense input matrices.
Truly sparse input matrices should also benefit from the improved sketch
algorithm, which now correctly runs in ``O(nnz(A))`` time.

Added new functions to calculate symmetric Fiedler matrices and
Fiedler companion matrices, named `scipy.linalg.fiedler` and
`scipy.linalg.fiedler_companion`, respectively. These may be used
for root finding.

`scipy.ndimage` improvements
----------------------------

Gaussian filter performances may improve by an order of magnitude in
some cases, thanks to removal of a dependence on ``np.polynomial``. This
may impact `scipy.ndimage.gaussian_filter` for example.

`scipy.optimize` improvements
-----------------------------

The `scipy.optimize.brute` minimizer obtained a new keyword ``workers``, which
can be used to parallelize computation.

A Cython API for bounded scalar-function root-finders in `scipy.optimize`
is available in a new module `scipy.optimize.cython_optimize` via ``cimport``.
This API may be used with ``nogil`` and ``prange`` to loop
over an array of function arguments to solve for an array of roots more
quickly than with pure Python.

``'interior-point'`` is now the default method for ``linprog``, and
``'interior-point'`` now uses SuiteSparse for sparse problems when the
required scikits  (scikit-umfpack and scikit-sparse) are available.
On benchmark problems (gh-10026), execution time reductions by factors of 2-3
were typical. Also, a new ``method='revised simplex'`` has been added.
It is not as fast or robust as ``method='interior-point'``, but it is a faster,
more robust, and equally accurate substitute for the legacy
``method='simplex'``.

``differential_evolution`` can now use a ``Bounds`` class to specify the
bounds for the optimizing argument of a function.

`scipy.optimize.dual_annealing` performance improvements related to
vectorisation of some internal code.

`scipy.signal` improvements
---------------------------

Two additional methods of discretization are now supported by
`scipy.signal.cont2discrete`: ``impulse`` and ``foh``.

`scipy.signal.firls` now uses faster solvers

`scipy.signal.detrend` now has a lower physical memory footprint in some
cases, which may be leveraged using the new ``overwrite_data`` keyword argument

`scipy.signal.firwin` ``pass_zero`` argument now accepts new string arguments
that allow specification of the desired filter type: ``'bandpass'``,
``'lowpass'``, ``'highpass'``, and ``'bandstop'``

`scipy.signal.sosfilt` may have improved performance due to lower retention
of the global interpreter lock (GIL) in algorithm

`scipy.sparse` improvements
---------------------------

A new keyword was added to ``csgraph.dijsktra`` that
allows users to query the shortest path to ANY of the passed in indices,
as opposed to the shortest path to EVERY passed index.

`scipy.sparse.linalg.lsmr` performance has been improved by roughly 10 percent
on large problems

Improved performance and reduced physical memory footprint of the algorithm
used by `scipy.sparse.linalg.lobpcg`

``CSR`` and ``CSC`` sparse matrix fancy indexing performance has been
improved substantially

`scipy.spatial` improvements
----------------------------

`scipy.spatial.ConvexHull` now has a ``good`` attribute that can be used
alongsize the ``QGn`` Qhull options to determine which external facets of a
convex hull are visible from an external query point.

`scipy.spatial.cKDTree.query_ball_point` has been modernized to use some newer
Cython features, including GIL handling and exception translation. An issue
with ``return_sorted=True`` and scalar queries was fixed, and a new mode named
``return_length`` was added. ``return_length`` only computes the length of the
returned indices list instead of allocating the array every time.

`scipy.spatial.transform.RotationSpline` has been added to enable interpolation
of rotations with continuous angular rates and acceleration

`scipy.stats` improvements
--------------------------

Added a new function to compute the Epps-Singleton test statistic,
`scipy.stats.epps_singleton_2samp`, which can be applied to continuous and
discrete distributions.

New functions `scipy.stats.median_absolute_deviation` and `scipy.stats.gstd`
(geometric standard deviation) were added. The `scipy.stats.combine_pvalues`
method now supports ``pearson``,  ``tippett`` and ``mudholkar_george`` pvalue
combination methods.

The `scipy.stats.ortho_group` and `scipy.stats.special_ortho_group`
``rvs(dim)`` functions' algorithms were updated from a ``O(dim^4)``
implementation to a ``O(dim^3)`` which gives large speed improvements
for ``dim>100``.

A rewrite of `scipy.stats.pearsonr` to use a more robust algorithm,
provide meaningful exceptions and warnings on potentially pathological input,
and fix at least five separate reported issues in the original implementation.

Improved the precision of ``hypergeom.logcdf`` and ``hypergeom.logsf``.

Added exact computation for Kolmogorov-Smirnov (KS) two-sample test, replacing
the previously approximate computation for the two-sided test `stats.ks_2samp`.
Also added a one-sided, two-sample KS test, and a keyword ``alternative`` to
`stats.ks_2samp`.

Backwards incompatible changes
==============================

`scipy.interpolate` changes
---------------------------

Functions from ``scipy.interpolate`` (``spleval``, ``spline``, ``splmake``,
and ``spltopp``) and functions from ``scipy.misc`` (``bytescale``,
``fromimage``, ``imfilter``, ``imread``, ``imresize``, ``imrotate``,
``imsave``, ``imshow``, ``toimage``) have been removed. The former set has
been deprecated since v0.19.0 and the latter has been deprecated since v1.0.0.
Similarly, aliases from ``scipy.misc`` (``comb``, ``factorial``,
``factorial2``, ``factorialk``, ``logsumexp``, ``pade``, ``info``, ``source``,
``who``) which have been deprecated since v1.0.0 are removed.
`SciPy documentation for
v1.1.0 <https://docs.scipy.org/doc/scipy-1.1.0/reference/misc.html>`__
can be used to track the new import locations for the relocated functions.

`scipy.linalg` changes
----------------------

For ``pinv``, ``pinv2``, and ``pinvh``, the default cutoff values are changed
for consistency (see the docs for the actual values).

`scipy.stats` changes
---------------------

Previously, ``ks_2samp(data1, data2)`` would run a two-sided test and return
the approximated p-value. The new signature, ``ks_2samp(data1, data2,
alternative="two-sided", method="auto")``, still runs the two-sided test by
default but returns the exact p-value for small samples and the approximated
value for large samples. ``method="asymp"`` would be equivalent to the
old version but ``auto`` is the better choice.

Other changes
=============

Our tutorial has been expanded with a new section on global optimizers

There has been a rework of the ``stats.distributions`` tutorials.

`scipy.optimize` now correctly sets the convergence flag of the result to
``CONVERR``, a convergence error, for bounded scalar-function root-finders
if the maximum iterations has been exceeded, ``disp`` is false, and
``full_output`` is true.

`scipy.optimize.curve_fit` no longer fails if ``xdata`` and ``ydata`` dtypes
differ; they are both now automatically cast to ``float64``.

`scipy.ndimage` functions including ``binary_erosion``, ``binary_closing``, and
``binary_dilation`` now require an integer value for the number of iterations,
which alleviates a number of reported issues.

Fixed normal approximation in case ``zero_method == "pratt"`` in
`scipy.stats.wilcoxon`.

Fixes for incorrect probabilities, broadcasting issues and thread-safety
related to stats distributions setting member variables inside ``_argcheck()``.

`scipy.optimize.newton` now correctly raises a ``RuntimeError``, when default
arguments are used, in the case that a derivative of value zero is obtained,
which is a special case of failing to converge.

A draft toolchain roadmap is now available, laying out a compatibility plan
including Python versions, C standards, and NumPy versions.


Authors
=======

* ananyashreyjain +
* ApamNapat +
* Scott Calabrese Barton +
* Christoph Baumgarten
* Peter Bell +
* Jacob Blomgren +
* Doctor Bob +
* Mana Borwornpadungkitti +
* Matthew Brett
* Evgeni Burovski
* CJ Carey
* Vega Theil Carstensen +
* Robert Cimrman
* Forrest Collman +
* Pietro Cottone +
* David +
* Idan David +
* Christoph Deil
* Dieter Werthm?ller
* Conner DiPaolo +
* Dowon
* Michael Dunphy +
* Peter Andreas Entschev +
* G?k?en Eraslan +
* Johann Faouzi +
* Yu Feng
* Piotr Figiel +
* Matthew H Flamm
* Franz Forstmayr +
* Christoph Gohlke
* Richard Janis Goldschmidt +
* Ralf Gommers
* Lars Grueter
* Sylvain Gubian
* Matt Haberland
* Yaroslav Halchenko
* Charles Harris
* Lindsey Hiltner
* JakobStruye +
* He Jia +
* Jwink3101 +
* Greg Kiar +
* Julius Bier Kirkegaard
* John Kirkham +
* Thomas Kluyver
* Vladimir Korolev +
* Joseph Kuo +
* Michael Lamparski +
* Eric Larson
* Denis Laxalde
* Katrin Leinweber
* Jesse Livezey
* ludcila +
* Dhruv Madeka +
* Magnus +
* Nikolay Mayorov
* Mark Mikofski
* Jarrod Millman
* Markus Mohrhard +
* Eric Moore
* Andrew Nelson
* Aki Nishimura +
* OGordon100 +
* Petar Mlinari? +
* Stefan Peterson
* Matti Picus +
* Ilhan Polat
* Aaron Pries +
* Matteo Ravasi +
* Tyler Reddy
* Ashton Reimer +
* Joscha Reimer
* rfezzani +
* Riadh +
* Lucas Roberts
* Heshy Roskes +
* Mirko Scholz +
* Taylor D. Scott +
* Srikrishna Sekhar +
* Kevin Sheppard +
* Sourav Singh
* skjerns +
* Kai Striega
* SyedSaifAliAlvi +
* Gopi Manohar T +
* Albert Thomas +
* Timon +
* Paul van Mulbregt
* Jacob Vanderplas
* Daniel Vargas +
* Pauli Virtanen
* VNMabus +
* Stefan van der Walt
* Warren Weckesser
* Josh Wilson
* Nate Yoder +
* Roman Yurchak

A total of 97 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.3.0
-----------------------

* `#1320 <https://github.com/scipy/scipy/issues/1320>`__:
scipy.stats.distribution: problem with self.a, self.b if they...
* `#2002 <https://github.com/scipy/scipy/issues/2002>`__: members set
in scipy.stats.distributions.##._argcheck (Trac #1477)
* `#2823 <https://github.com/scipy/scipy/issues/2823>`__: distribution
methods add tmp
* `#3220 <https://github.com/scipy/scipy/issues/3220>`__:
Scipy.opimize.fmin_powell direc argument syntax unclear
* `#3728 <https://github.com/scipy/scipy/issues/3728>`__:
scipy.stats.pearsonr: possible bug with zero variance input
* `#6805 <https://github.com/scipy/scipy/issues/6805>`__:
error-in-scipy-wilcoxon-signed-rank-test-for-equal-series
* `#6873 <https://github.com/scipy/scipy/issues/6873>`__:
'stats.boxcox' return all same values
* `#7117 <https://github.com/scipy/scipy/issues/7117>`__: Warn users
when using float32 input data to curve_fit and friends
* `#7632 <https://github.com/scipy/scipy/issues/7632>`__: it's not
possible to tell the \`optimize.least_squares\` solver...
* `#7730 <https://github.com/scipy/scipy/issues/7730>`__:
stats.pearsonr: Potential division by zero for dataset of length...
* `#7933 <https://github.com/scipy/scipy/issues/7933>`__:
stats.truncnorm fails when providing values outside truncation...
* `#8033 <https://github.com/scipy/scipy/issues/8033>`__: Add standard
filter types to firwin to set pass_zero intuitively...
* `#8600 <https://github.com/scipy/scipy/issues/8600>`__:
lfilter.c.src zfill has erroneous header
* `#8692 <https://github.com/scipy/scipy/issues/8692>`__: Non-negative
values of \`stats.hypergeom.logcdf\`
* `#8734 <https://github.com/scipy/scipy/issues/8734>`__: Enable pip
build isolation
* `#8861 <https://github.com/scipy/scipy/issues/8861>`__:
scipy.linalg.pinv gives wrong result while scipy.linalg.pinv2...
* `#8915 <https://github.com/scipy/scipy/issues/8915>`__: need to fix
macOS build against older numpy versions
* `#8980 <https://github.com/scipy/scipy/issues/8980>`__:
scipy.stats.pearsonr overflows with high values of x and y
* `#9226 <https://github.com/scipy/scipy/issues/9226>`__: BUG: signal:
SystemError: <built-in function _linear_filter>...
* `#9254 <https://github.com/scipy/scipy/issues/9254>`__: BUG: root
finders brentq, etc, flag says "converged" even if...
* `#9308 <https://github.com/scipy/scipy/issues/9308>`__: Test failure
- test_initial_constraints_as_canonical
* `#9353 <https://github.com/scipy/scipy/issues/9353>`__:
scipy.stats.pearsonr returns r=1 if r_num/r_den = inf
* `#9359 <https://github.com/scipy/scipy/issues/9359>`__: Planck
distribution is a geometric distribution
* `#9381 <https://github.com/scipy/scipy/issues/9381>`__: linregress
should warn user in 2x2 array case
* `#9406 <https://github.com/scipy/scipy/issues/9406>`__: BUG: stats:
In pearsonr, when r is nan, the p-value must also...
* `#9437 <https://github.com/scipy/scipy/issues/9437>`__: Cannot
create sparse matrix from size_t indexes
* `#9518 <https://github.com/scipy/scipy/issues/9518>`__: Relational
attributes in loadarff
* `#9551 <https://github.com/scipy/scipy/issues/9551>`__: BUG:
scipy.optimize.newton says the root of x^2+1 is zero.
* `#9564 <https://github.com/scipy/scipy/issues/9564>`__: rv_sample
accepts invalid input in scipy.stats
* `#9565 <https://github.com/scipy/scipy/issues/9565>`__: improper
handling of multidimensional input in stats.rv_sample
* `#9581 <https://github.com/scipy/scipy/issues/9581>`__:
Least-squares minimization fails silently when x and y data are...
* `#9587 <https://github.com/scipy/scipy/issues/9587>`__: Outdated
value for scipy.constants.au
* `#9611 <https://github.com/scipy/scipy/issues/9611>`__: Overflow
error with new way of p-value calculation in kendall...
* `#9645 <https://github.com/scipy/scipy/issues/9645>`__:
\`scipy.stats.mode\` crashes with variable length arrays
(\`dtype=object\`)
* `#9734 <https://github.com/scipy/scipy/issues/9734>`__:
PendingDeprecationWarning for np.matrix with pytest
* `#9786 <https://github.com/scipy/scipy/issues/9786>`__:
stats.ks_2samp() misleading for small data sets.
* `#9790 <https://github.com/scipy/scipy/issues/9790>`__: Excessive
memory usage on detrend
* `#9801 <https://github.com/scipy/scipy/issues/9801>`__:
dual_annealing does not set the success attribute in OptimizeResult
* `#9833 <https://github.com/scipy/scipy/issues/9833>`__:
IntegrationWarning from mielke.stats() during build of html doc.
* `#9835 <https://github.com/scipy/scipy/issues/9835>`__:
scipy.signal.firls seems to be inefficient versus MATLAB firls
* `#9864 <https://github.com/scipy/scipy/issues/9864>`__: Curve_fit
does not check for empty input data if called with...
* `#9869 <https://github.com/scipy/scipy/issues/9869>`__:
scipy.ndimage.label: Minor documentation issue
* `#9882 <https://github.com/scipy/scipy/issues/9882>`__: format at
the wrong paranthesis in scipy.spatial.transform
* `#9889 <https://github.com/scipy/scipy/issues/9889>`__:
scipy.signal.find_peaks minor documentation issue
* `#9890 <https://github.com/scipy/scipy/issues/9890>`__: Minkowski
p-norm Issues in cKDTree For Values Other Than 2 Or...
* `#9896 <https://github.com/scipy/scipy/issues/9896>`__:
scipy.stats._argcheck sets (not just checks) values
* `#9905 <https://github.com/scipy/scipy/issues/9905>`__: Memory error
in ndimage.binary_erosion
* `#9909 <https://github.com/scipy/scipy/issues/9909>`__:
binary_dilation/erosion/closing crashes when iterations is float
* `#9919 <https://github.com/scipy/scipy/issues/9919>`__: BUG:
\`coo_matrix\` does not validate the \`shape\` argument.
* `#9982 <https://github.com/scipy/scipy/issues/9982>`__: lsq_linear
hangs/infinite loop with 'trf' method
* `#10003 <https://github.com/scipy/scipy/issues/10003>`__:
exponnorm.pdf returns NAN for small K
* `#10011 <https://github.com/scipy/scipy/issues/10011>`__: Incorrect
check for invalid rotation plane in scipy.ndimage.rotate
* `#10024 <https://github.com/scipy/scipy/issues/10024>`__: Fails to
build from git
* `#10048 <https://github.com/scipy/scipy/issues/10048>`__: DOC:
scipy.optimize.root_scalar
* `#10068 <https://github.com/scipy/scipy/issues/10068>`__: DOC:
scipy.interpolate.splev
* `#10074 <https://github.com/scipy/scipy/issues/10074>`__: BUG:
\`expm\` calculates the wrong coefficients in the backward...


Pull requests for 1.3.0
-----------------------

* `#7827 <https://github.com/scipy/scipy/pull/7827>`__: ENH: sparse:
overhaul of sparse matrix indexing
* `#8431 <https://github.com/scipy/scipy/pull/8431>`__: ENH: Cython
optimize zeros api
* `#8743 <https://github.com/scipy/scipy/pull/8743>`__: DOC: Updated
linalg.pinv, .pinv2, .pinvh docstrings
* `#8744 <https://github.com/scipy/scipy/pull/8744>`__: DOC: added
examples to remez docstring
* `#9227 <https://github.com/scipy/scipy/pull/9227>`__: DOC: update
description of "direc" parameter of "fmin_powell"
* `#9263 <https://github.com/scipy/scipy/pull/9263>`__: ENH: optimize:
added "revised simplex" for scipy.optimize.linprog
* `#9325 <https://github.com/scipy/scipy/pull/9325>`__: DEP: Remove
deprecated functions for 1.3.0
* `#9330 <https://github.com/scipy/scipy/pull/9330>`__: Add note on
push and pull affine transformations
* `#9423 <https://github.com/scipy/scipy/pull/9423>`__: DOC: Clearly
state how 2x2 input arrays are handled in stats.linregress
* `#9428 <https://github.com/scipy/scipy/pull/9428>`__: ENH: parallelised brute
* `#9438 <https://github.com/scipy/scipy/pull/9438>`__: BUG:
Initialize coo matrix with size_t indexes
* `#9455 <https://github.com/scipy/scipy/pull/9455>`__: MAINT: Speed
up get_(lapack,blas)_func
* `#9465 <https://github.com/scipy/scipy/pull/9465>`__: MAINT: Clean
up optimize.zeros C solvers interfaces/code.
* `#9477 <https://github.com/scipy/scipy/pull/9477>`__: DOC: linalg:
fix lstsq docstring on residues shape
* `#9478 <https://github.com/scipy/scipy/pull/9478>`__: DOC: Add
docstring examples for rosen functions
* `#9479 <https://github.com/scipy/scipy/pull/9479>`__: DOC: Add
docstring example for ai_zeros and bi_zeros
* `#9480 <https://github.com/scipy/scipy/pull/9480>`__: MAINT: linalg:
lstsq clean up
* `#9489 <https://github.com/scipy/scipy/pull/9489>`__: DOC: roadmap
update for changes over the last year.
* `#9492 <https://github.com/scipy/scipy/pull/9492>`__: MAINT: stats:
Improve implementation of chi2 ppf method.
* `#9497 <https://github.com/scipy/scipy/pull/9497>`__: DOC: Improve
docstrings sparse.linalg.isolve
* `#9499 <https://github.com/scipy/scipy/pull/9499>`__: DOC: Replace
"Scipy" with "SciPy" in the .rst doc files for consistency.
* `#9500 <https://github.com/scipy/scipy/pull/9500>`__: DOC: Document
the toolchain and its roadmap.
* `#9505 <https://github.com/scipy/scipy/pull/9505>`__: DOC: specify
which definition of skewness is used
* `#9511 <https://github.com/scipy/scipy/pull/9511>`__: DEP:
interpolate: remove deprecated interpolate_wrapper
* `#9517 <https://github.com/scipy/scipy/pull/9517>`__: BUG: improve
error handling in stats.iqr
* `#9522 <https://github.com/scipy/scipy/pull/9522>`__: ENH: Add
Fiedler and fiedler companion to special matrices
* `#9526 <https://github.com/scipy/scipy/pull/9526>`__: TST: relax
precision requirements in signal.correlate tests
* `#9529 <https://github.com/scipy/scipy/pull/9529>`__: DOC: fix
missing random seed in optimize.newton example
* `#9533 <https://github.com/scipy/scipy/pull/9533>`__: MAINT: Use
list comprehension when possible
* `#9537 <https://github.com/scipy/scipy/pull/9537>`__: DOC: add a
"big picture" roadmap
* `#9538 <https://github.com/scipy/scipy/pull/9538>`__: DOC: Replace
"Numpy" with "NumPy" in .py, .rst and .txt doc files...
* `#9539 <https://github.com/scipy/scipy/pull/9539>`__: ENH: add
two-sample test (Epps-Singleton) to scipy.stats
* `#9559 <https://github.com/scipy/scipy/pull/9559>`__: DOC: add
section on global optimizers to tutorial
* `#9561 <https://github.com/scipy/scipy/pull/9561>`__: ENH: remove
noprefix.h, change code appropriately
* `#9562 <https://github.com/scipy/scipy/pull/9562>`__: MAINT: stats:
Rewrite pearsonr.
* `#9563 <https://github.com/scipy/scipy/pull/9563>`__: BUG: Minor bug
fix Callback in linprog(method='simplex')
* `#9568 <https://github.com/scipy/scipy/pull/9568>`__: MAINT: raise
runtime error for newton with zeroder if disp true,...
* `#9570 <https://github.com/scipy/scipy/pull/9570>`__: Correct
docstring in show_options in optimize. Fixes #9407
* `#9573 <https://github.com/scipy/scipy/pull/9573>`__: BUG fixes
range of pk variable pre-check
* `#9577 <https://github.com/scipy/scipy/pull/9577>`__: TST: fix minor
issue in a signal.stft test.
* `#9580 <https://github.com/scipy/scipy/pull/9580>`__: Included blank
line before list - Fixes #8658
* `#9582 <https://github.com/scipy/scipy/pull/9582>`__: MAINT: drop
Python 2.7 and 3.4
* `#9588 <https://github.com/scipy/scipy/pull/9588>`__: MAINT: update
\`constants.astronomical_unit\` to new 2012 value.
* `#9592 <https://github.com/scipy/scipy/pull/9592>`__: TST: Add
32-bit testing to CI
* `#9593 <https://github.com/scipy/scipy/pull/9593>`__: DOC: Replace
cumulative density with cumulative distribution
* `#9596 <https://github.com/scipy/scipy/pull/9596>`__: TST: remove VC
9.0 from Azure CI
* `#9599 <https://github.com/scipy/scipy/pull/9599>`__: Hyperlink DOI
to preferred resolver
* `#9601 <https://github.com/scipy/scipy/pull/9601>`__: DEV: try to
limit GC memory use on PyPy
* `#9603 <https://github.com/scipy/scipy/pull/9603>`__: MAINT: improve
logcdf and logsf of hypergeometric distribution
* `#9605 <https://github.com/scipy/scipy/pull/9605>`__: Reference to
pylops in LinearOperator notes and ARPACK example
* `#9617 <https://github.com/scipy/scipy/pull/9617>`__: TST: reduce
max memory usage for sparse.linalg.lgmres test
* `#9619 <https://github.com/scipy/scipy/pull/9619>`__: FIX: Sparse
matrix addition/subtraction eliminates explicit zeros
* `#9621 <https://github.com/scipy/scipy/pull/9621>`__: bugfix in
rv_sample in scipy.stats
* `#9622 <https://github.com/scipy/scipy/pull/9622>`__: MAINT: Raise
error in directed_hausdorff distance
* `#9623 <https://github.com/scipy/scipy/pull/9623>`__: DOC: Build
docs with warnings as errors
* `#9625 <https://github.com/scipy/scipy/pull/9625>`__: Return the
number of calls to 'hessp' (not just 'hess') in trust...
* `#9627 <https://github.com/scipy/scipy/pull/9627>`__: BUG: ignore
empty lines in mmio
* `#9637 <https://github.com/scipy/scipy/pull/9637>`__: Function to
calculate the MAD of an array
* `#9646 <https://github.com/scipy/scipy/pull/9646>`__: BUG: stats:
mode for objects w/ndim > 1
* `#9648 <https://github.com/scipy/scipy/pull/9648>`__: Add
\`stats.contingency\` to refguide-check
* `#9650 <https://github.com/scipy/scipy/pull/9650>`__: ENH: many
lobpcg() algorithm improvements
* `#9652 <https://github.com/scipy/scipy/pull/9652>`__: Move
misc.doccer to _lib.doccer
* `#9660 <https://github.com/scipy/scipy/pull/9660>`__: ENH: add
pearson, tippett, and mudholkar-george to combine_pvalues
* `#9661 <https://github.com/scipy/scipy/pull/9661>`__: BUG: Fix ksone
right-hand endpoint, documentation and tests.
* `#9664 <https://github.com/scipy/scipy/pull/9664>`__: ENH: adding
multi-target dijsktra performance enhancement
* `#9670 <https://github.com/scipy/scipy/pull/9670>`__: MAINT: link
planck and geometric distribution in scipy.stats
* `#9676 <https://github.com/scipy/scipy/pull/9676>`__: ENH: optimize:
change default linprog method to interior-point
* `#9685 <https://github.com/scipy/scipy/pull/9685>`__: Added
reference to ndimage.filters.median_filter
* `#9705 <https://github.com/scipy/scipy/pull/9705>`__: Fix
coefficients in expm helper function
* `#9711 <https://github.com/scipy/scipy/pull/9711>`__: Release the
GIL during sosfilt processing for simple types
* `#9721 <https://github.com/scipy/scipy/pull/9721>`__: ENH:
Convexhull visiblefacets
* `#9723 <https://github.com/scipy/scipy/pull/9723>`__: BLD: Modify
rv_generic._construct_doc to print out failing distribution...
* `#9726 <https://github.com/scipy/scipy/pull/9726>`__: BUG: Fix small
issues with \`signal.lfilter'
* `#9729 <https://github.com/scipy/scipy/pull/9729>`__: BUG: Typecheck
iterations for binary image operations
* `#9730 <https://github.com/scipy/scipy/pull/9730>`__: ENH: reduce
sizeof(NI_WatershedElement) by 20%
* `#9731 <https://github.com/scipy/scipy/pull/9731>`__: ENH: remove
suspicious sequence of type castings
* `#9739 <https://github.com/scipy/scipy/pull/9739>`__: BUG:
qr_updates fails if u is exactly in span Q
* `#9749 <https://github.com/scipy/scipy/pull/9749>`__: BUG:
MapWrapper.__exit__ should terminate
* `#9753 <https://github.com/scipy/scipy/pull/9753>`__: ENH: Added
exact computation for Kolmogorov-Smirnov two-sample...
* `#9755 <https://github.com/scipy/scipy/pull/9755>`__: DOC: Added
example for signal.impulse, copied from impulse2
* `#9756 <https://github.com/scipy/scipy/pull/9756>`__: DOC: Added
docstring example for iirdesign
* `#9757 <https://github.com/scipy/scipy/pull/9757>`__: DOC: Added
examples for step functions
* `#9759 <https://github.com/scipy/scipy/pull/9759>`__: ENH: Allow
pass_zero to act like btype
* `#9760 <https://github.com/scipy/scipy/pull/9760>`__: DOC: Added
docstring for lp2bs
* `#9761 <https://github.com/scipy/scipy/pull/9761>`__: DOC: Added
docstring and example for lp2bp
* `#9764 <https://github.com/scipy/scipy/pull/9764>`__: BUG: Catch
internal warnings for matrix
* `#9766 <https://github.com/scipy/scipy/pull/9766>`__: ENH: Speed up
_gaussian_kernel1d by removing dependence on np.polynomial
* `#9769 <https://github.com/scipy/scipy/pull/9769>`__: BUG: Fix Cubic
Spline Read Only issues
* `#9773 <https://github.com/scipy/scipy/pull/9773>`__: DOC: Several docstrings
* `#9774 <https://github.com/scipy/scipy/pull/9774>`__: TST: bump
Azure CI OpenBLAS version to match wheels
* `#9775 <https://github.com/scipy/scipy/pull/9775>`__: DOC: Improve
clarity of cov_x documentation for scipy.optimize.leastsq
* `#9779 <https://github.com/scipy/scipy/pull/9779>`__: ENH:
dual_annealing vectorise visit_fn
* `#9788 <https://github.com/scipy/scipy/pull/9788>`__: TST, BUG:
f2py-related issues with NumPy < 1.14.0
* `#9791 <https://github.com/scipy/scipy/pull/9791>`__: BUG: fix amax
constraint not enforced in scalar_search_wolfe2
* `#9792 <https://github.com/scipy/scipy/pull/9792>`__: ENH: Allow
inplace copying in place in "detrend" function
* `#9795 <https://github.com/scipy/scipy/pull/9795>`__: DOC:
Fix/update docstring for dstn and dst
* `#9796 <https://github.com/scipy/scipy/pull/9796>`__: MAINT: Allow
None tolerances in least_squares
* `#9798 <https://github.com/scipy/scipy/pull/9798>`__: BUG: fixes
abort trap 6 error in scipy issue 9785 in unit tests
* `#9807 <https://github.com/scipy/scipy/pull/9807>`__: MAINT: improve
doc and add alternative keyword to wilcoxon in...
* `#9808 <https://github.com/scipy/scipy/pull/9808>`__: Fix PPoly
integrate and test for CubicSpline
* `#9810 <https://github.com/scipy/scipy/pull/9810>`__: ENH: Add the
geometric standard deviation function
* `#9811 <https://github.com/scipy/scipy/pull/9811>`__: MAINT: remove
invalid derphi default None value in scalar_search_wolfe2
* `#9813 <https://github.com/scipy/scipy/pull/9813>`__: Adapt hamming
distance in C to support weights
* `#9817 <https://github.com/scipy/scipy/pull/9817>`__: DOC: Copy
solver description to solver modules
* `#9829 <https://github.com/scipy/scipy/pull/9829>`__: ENH: Add FOH
and equivalent impulse response discretizations...
* `#9831 <https://github.com/scipy/scipy/pull/9831>`__: ENH: Implement
RotationSpline
* `#9834 <https://github.com/scipy/scipy/pull/9834>`__: DOC: Change
mielke distribution default parameters to ensure...
* `#9838 <https://github.com/scipy/scipy/pull/9838>`__: ENH: Use
faster solvers for firls
* `#9854 <https://github.com/scipy/scipy/pull/9854>`__: ENH: loadarff
now supports relational attributes.
* `#9856 <https://github.com/scipy/scipy/pull/9856>`__: integrate.bvp
- improve handling of nonlinear boundary conditions
* `#9862 <https://github.com/scipy/scipy/pull/9862>`__: TST: reduce
Appveyor CI load
* `#9874 <https://github.com/scipy/scipy/pull/9874>`__: DOC: Update
requirements in release notes
* `#9883 <https://github.com/scipy/scipy/pull/9883>`__: BUG: fixed
parenthesis in spatial.rotation
* `#9884 <https://github.com/scipy/scipy/pull/9884>`__: ENH: Use
Sparsity in Clarkson-Woodruff Sketch
* `#9888 <https://github.com/scipy/scipy/pull/9888>`__: MAINT: Replace
NumPy aliased functions
* `#9892 <https://github.com/scipy/scipy/pull/9892>`__: BUG: Fix 9890
query_ball_point returns wrong result when p is...
* `#9893 <https://github.com/scipy/scipy/pull/9893>`__: BUG: curve_fit
doesn't check for empty input if called with bounds
* `#9894 <https://github.com/scipy/scipy/pull/9894>`__:
scipy.signal.find_peaks documentation error
* `#9898 <https://github.com/scipy/scipy/pull/9898>`__: BUG: Set
success attribute in OptimizeResult. See #9801
* `#9900 <https://github.com/scipy/scipy/pull/9900>`__: BUG: Restrict
rv_generic._argcheck() and its overrides from setting...
* `#9906 <https://github.com/scipy/scipy/pull/9906>`__: fixed a bug in
kde logpdf
* `#9911 <https://github.com/scipy/scipy/pull/9911>`__: DOC: replace
example for "np.select" with the one from numpy...
* `#9912 <https://github.com/scipy/scipy/pull/9912>`__: BF(DOC): point
to numpy.select instead of plain (python) .select
* `#9914 <https://github.com/scipy/scipy/pull/9914>`__: DOC: change
ValueError message in _validate_pad of signaltools.
* `#9915 <https://github.com/scipy/scipy/pull/9915>`__: cKDTree
query_ball_point improvements
* `#9918 <https://github.com/scipy/scipy/pull/9918>`__: Update
ckdtree.pyx with boxsize argument in docstring
* `#9920 <https://github.com/scipy/scipy/pull/9920>`__: BUG: sparse:
Validate explicit shape if given with dense argument...
* `#9924 <https://github.com/scipy/scipy/pull/9924>`__: BLD: add back
pyproject.toml
* `#9931 <https://github.com/scipy/scipy/pull/9931>`__: Fix empty constraint
* `#9935 <https://github.com/scipy/scipy/pull/9935>`__: DOC: fix
references for stats.f_oneway
* `#9936 <https://github.com/scipy/scipy/pull/9936>`__: Revert
gh-9619: "FIX: Sparse matrix addition/subtraction eliminates...
* `#9937 <https://github.com/scipy/scipy/pull/9937>`__: MAINT: fix
PEP8 issues and update to pycodestyle 2.5.0
* `#9939 <https://github.com/scipy/scipy/pull/9939>`__: DOC: correct
\`structure\` description in \`ndimage.label\` docstring
* `#9940 <https://github.com/scipy/scipy/pull/9940>`__: MAINT: remove
extraneous distutils copies
* `#9945 <https://github.com/scipy/scipy/pull/9945>`__: ENH:
differential_evolution can use Bounds object
* `#9949 <https://github.com/scipy/scipy/pull/9949>`__: Added 'std' to
add doctstrings since it is a \`known_stats\`...
* `#9953 <https://github.com/scipy/scipy/pull/9953>`__: DOC:
Documentation cleanup for stats tutorials.
* `#9962 <https://github.com/scipy/scipy/pull/9962>`__: __repr__ for Bounds
* `#9971 <https://github.com/scipy/scipy/pull/9971>`__: ENH: Improve
performance of lsmr
* `#9987 <https://github.com/scipy/scipy/pull/9987>`__: CI: pin Sphinx
version to 1.8.5
* `#9990 <https://github.com/scipy/scipy/pull/9990>`__: ENH:
constraint violation
* `#9991 <https://github.com/scipy/scipy/pull/9991>`__: BUG: Avoid
inplace modification of input array in newton
* `#9995 <https://github.com/scipy/scipy/pull/9995>`__: MAINT:
sparse.csgraph: Add cdef to stop build warning.
* `#9996 <https://github.com/scipy/scipy/pull/9996>`__: BUG: Make
minimize_quadratic_1d work with infinite bounds correctly
* `#10004 <https://github.com/scipy/scipy/pull/10004>`__: BUG: Fix
unbound local error in linprog - simplex.
* `#10007 <https://github.com/scipy/scipy/pull/10007>`__: BLD: fix
Python 3.7 build with build isolation
* `#10009 <https://github.com/scipy/scipy/pull/10009>`__: BUG: Make
sure that _binary_erosion only accepts an integer number...
* `#10016 <https://github.com/scipy/scipy/pull/10016>`__: Update link
to airspeed-velocity
* `#10017 <https://github.com/scipy/scipy/pull/10017>`__: DOC: Update
\`interpolate.LSQSphereBivariateSpline\` to include...
* `#10018 <https://github.com/scipy/scipy/pull/10018>`__: MAINT:
special: Fix a few warnings that occur when compiling...
* `#10019 <https://github.com/scipy/scipy/pull/10019>`__: TST: Azure
summarizes test failures
* `#10021 <https://github.com/scipy/scipy/pull/10021>`__: ENH:
Introduce CubicHermiteSpline
* `#10022 <https://github.com/scipy/scipy/pull/10022>`__: BENCH:
Increase cython version in asv to fix benchmark builds
* `#10023 <https://github.com/scipy/scipy/pull/10023>`__: BUG: Avoid
exponnorm producing nan for small K values.
* `#10025 <https://github.com/scipy/scipy/pull/10025>`__: BUG:
optimize: tweaked linprog status 4 error message
* `#10026 <https://github.com/scipy/scipy/pull/10026>`__: ENH:
optimize: use SuiteSparse in linprog interior-point when...
* `#10027 <https://github.com/scipy/scipy/pull/10027>`__: MAINT:
cluster: clean up the use of malloc() in the function...
* `#10028 <https://github.com/scipy/scipy/pull/10028>`__: Fix rotate
invalid plane check
* `#10040 <https://github.com/scipy/scipy/pull/10040>`__: MAINT: fix
pratt method of wilcox test in scipy.stats
* `#10041 <https://github.com/scipy/scipy/pull/10041>`__: MAINT:
special: Fix a warning generated when building the AMOS...
* `#10044 <https://github.com/scipy/scipy/pull/10044>`__: DOC: fix up
spatial.transform.Rotation docstrings
* `#10047 <https://github.com/scipy/scipy/pull/10047>`__: MAINT:
interpolate: Fix a few build warnings.
* `#10051 <https://github.com/scipy/scipy/pull/10051>`__: Add
project_urls to setup
* `#10052 <https://github.com/scipy/scipy/pull/10052>`__: don't set
flag to "converged" if max iter exceeded
* `#10054 <https://github.com/scipy/scipy/pull/10054>`__: MAINT:
signal: Fix a few build warnings and modernize some C...
* `#10056 <https://github.com/scipy/scipy/pull/10056>`__: BUG: Ensure
factorial is not too large in kendaltau
* `#10058 <https://github.com/scipy/scipy/pull/10058>`__: Small
speedup in samping from ortho and special_ortho groups
* `#10059 <https://github.com/scipy/scipy/pull/10059>`__: BUG:
optimize: fix #10038 by increasing tol
* `#10061 <https://github.com/scipy/scipy/pull/10061>`__: BLD: DOC:
make building docs easier by parsing python version.
* `#10064 <https://github.com/scipy/scipy/pull/10064>`__: ENH:
Significant speedup for ortho and special ortho group
* `#10065 <https://github.com/scipy/scipy/pull/10065>`__: DOC: Reword
parameter descriptions in \`optimize.root_scalar\`
* `#10066 <https://github.com/scipy/scipy/pull/10066>`__: BUG: signal:
Fix error raised by savgol_coeffs when deriv > polyorder.
* `#10067 <https://github.com/scipy/scipy/pull/10067>`__: MAINT: Fix
the cutoff value inconsistency for pinv2 and pinvh
* `#10072 <https://github.com/scipy/scipy/pull/10072>`__: BUG: stats:
Fix boxcox_llf to avoid loss of precision.
* `#10075 <https://github.com/scipy/scipy/pull/10075>`__: ENH: Add
wrappers for ?syconv routines
* `#10076 <https://github.com/scipy/scipy/pull/10076>`__: BUG:
optimize: fix curve_fit for mixed float32/float64 input
* `#10077 <https://github.com/scipy/scipy/pull/10077>`__: DOC: Replace
undefined \`k\` in \`interpolate.splev\` docstring
* `#10079 <https://github.com/scipy/scipy/pull/10079>`__: DOC: Fixed
typo, rearranged some doc of stats.morestats.wilcoxon.
* `#10080 <https://github.com/scipy/scipy/pull/10080>`__: TST: install
scikit-sparse for full TravisCI tests
* `#10083 <https://github.com/scipy/scipy/pull/10083>`__: Clean
\`\`_clean_inputs\`\` in optimize.linprog
* `#10088 <https://github.com/scipy/scipy/pull/10088>`__: ENH:
optimize: linprog test CHOLMOD/UMFPACK solvers when available
* `#10090 <https://github.com/scipy/scipy/pull/10090>`__: MAINT: Fix
CubicSplinerInterpolator for pandas
* `#10091 <https://github.com/scipy/scipy/pull/10091>`__: MAINT:
improve logcdf and logsf of hypergeometric distribution
* `#10095 <https://github.com/scipy/scipy/pull/10095>`__: MAINT: Clean
\`\`_clean_inputs\`\` in linprog

Checksums
=========

MD5
~~~

5a71a217fa4ff372097f501daf816f3b
scipy-1.3.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_int
el.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
c154ca8eee9ebafe04575b316e41ed85  scipy-1.3.0rc1-cp35-cp35m-manylinux1_i686.whl
36a91fa4ae6eeceeb79bf97b9bd013eb
scipy-1.3.0rc1-cp35-cp35m-manylinux1_x86_64.whl
f1f4259b373332d6edc6bef123b0dc7c  scipy-1.3.0rc1-cp35-cp35m-win32.whl
c81d78bed8e2176cf0168785b7e1b692  scipy-1.3.0rc1-cp35-cp35m-win_amd64.whl
c43dd24f349c9d37a6c996e7c0674141
scipy-1.3.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_int
el.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
8188210e0fd710f4544f314306b76313  scipy-1.3.0rc1-cp36-cp36m-manylinux1_i686.whl
0cf317ee185a8f5736b479d1c8b5f415
scipy-1.3.0rc1-cp36-cp36m-manylinux1_x86_64.whl
e46e5b38288d79321d8d6ffa15a8f54e  scipy-1.3.0rc1-cp36-cp36m-win32.whl
85a79e9be408de72056c6efc1eef7d46  scipy-1.3.0rc1-cp36-cp36m-win_amd64.whl
2436169658f74e03b4037142e51a8f86
scipy-1.3.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_int
el.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
1b9e2caa5994ee227b4ad8e46b45ad7e  scipy-1.3.0rc1-cp37-cp37m-manylinux1_i686.whl
05a51b40471abdf4e9020183ad449bf2
scipy-1.3.0rc1-cp37-cp37m-manylinux1_x86_64.whl
debecbc0e54fe4e737971b0a6d9f24f5  scipy-1.3.0rc1-cp37-cp37m-win32.whl
79c725144fa59566d8ebd3bf556533aa  scipy-1.3.0rc1-cp37-cp37m-win_amd64.whl
0b9fa3583bcf2c8190b277cddb287132  scipy-1.3.0rc1.tar.gz
d22a40e138ecd6bb26990e22d4a1ac1b  scipy-1.3.0rc1.tar.xz
9cc12f26980587900befabafaac2078b  scipy-1.3.0rc1.zip


SHA256
                      ~~~~~~


3491e5453acec48ff8bc1e96980a9ca225bf653eb8e2fad2efe44ca54fd61230
scipy-1.3.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl


b04fed432d0d2b7aa52fb83c87390f22e34407baa404385e6c804c6d2f9fe3dc
scipy-1.3.0rc1-cp35-cp35m-manylinux1_i686.whl

71c236d8b036caa84a018b056c6ced101bcb3efb160fab18957daf5a41c7319c
scipy-1.3.0rc1-cp35-cp35m-manylinux1_x86_64.whl

6fa6a341ab6920f9233ce5da16572e3e403540f90c17269e27a7a7451e05d40e
scipy-1.3.0rc1-cp35-cp35m-win32.whl

7ec09797276d26c74234c056415234a7168e536011767af984b1700410806699
scipy-1.3.0rc1-cp35-cp35m-win_amd64.whl

55fcdd1ea9bb3d5461477391d924e24c56c8fa3cb3aba98c2ee2c47e3ccd6ce2
scipy-1.3.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl


b149d330d0a8219b68d2839cc49a37df163b0ec0b56194f8f0aa6878c1e7c2a4
scipy-1.3.0rc1-cp36-cp36m-manylinux1_i686.whl

9fed021210077c2e183f621d84bef428762b0b226f8f6da2b03a7d93628e3089
scipy-1.3.0rc1-cp36-cp36m-manylinux1_x86_64.whl

5c9c9a47e914fbf8edc9a1da1e10a9f5204b3dfc89c93b721b658290884bfe45
scipy-1.3.0rc1-cp36-cp36m-win32.whl

09b2c3e099b6274b142e7e05132e79efbbe4daa9dd593a226a3bc9820adf966a
scipy-1.3.0rc1-cp36-cp36m-win_amd64.whl

4e93edc6d4c1296ac39ae4be2e8d9336a37a3e5c6e104801a288db0f18d5dbd1
scipy-1.3.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl


1edafef721c859848b8575e7313fba062903f3c256661304f488b96fff4f759d
scipy-1.3.0rc1-cp37-cp37m-manylinux1_i686.whl

2fe186fff442d3f54f8e6950e809c571ea29db8333ed30608c4074a843d5cdf1
scipy-1.3.0rc1-cp37-cp37m-manylinux1_x86_64.whl

7c59ec7d5148538978da6c66059c9e3240ae9cf17b803b15354fffc8d3320961
scipy-1.3.0rc1-cp37-cp37m-win32.whl
2ab6d6f940b6b09cbee6d7cb2de5914a50f459cbc612b4328b033f67452fd1d6
scipy-1.3.0rc1-cp37-cp37m-win_amd64.whl
d09e6fae7434aa9e1422d95bbee28f0b66ba97ab770fec24f31c75a873823cd6
scipy-1.3.0rc1.tar.gz
ba49645a693f6e70e690cf6e2175865b7bf0182cf59bdce872968f47546f4269
scipy-1.3.0rc1.tar.xz
f1cdb4651f3d150f5c145dc930a627f09aa2afc5275c6c5da97a9a5df274c531
scipy-1.3.0rc1.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJcw54gAAoJELD/41ZX0J71zbEQAKaapoUb0gbLvljeLL+FZmaZ
Ha8OecYf7Fsdgj9kiGk2kKgrvz5nkoRyJDpxi4BOzPua+HBUhECoH3DBL5kA6sbv
VsMAhTb5HFPiKmC78LHEUNSY1fPJrdK7s99pIgedjQFR5diODHqqtB54awbRsTOs
Vdq45I7JoCd+DUMqQWIA3TZyjrZzw2V1KBFS8mHFdcop71Q1RqRNf3rVw7Rpydob
uegbae42cJ2Hej4+viU8hsCM+JIgkCuZaQEN2wp4W9pmHsDCzJcoyQjulTjZQAeG
W3L/F5O1p9A9nHIPk+wvS3D2ageKOhYmVSgB6dznXnFRsjwIKH4O4k0TCzYAamsd
HvcKnncGAzc+95o2k+v46575O3pBPRYCmOKz6LlFfFGNr/PWkxPYuG49nGIwQZU+
/w0RYvu2NIPyd05gQQfwyEAATmwbYQfCelbQtHtPehDrtwMINZF4ZCqVg8D7d2ns
c2mUUC72Iq62R17CdQOjp/zkvU4Xo6KGm0TPQY7xuJwXOaiM5cJ49iY+/Z6eBfBM
JS0MoIZ8PRzhzQ6gKTPt4exil75ybNpCeL/Ny/LY5dgkfaOdTuplmxwxgngxaECG
W4SaGw4P0SiATwyz7hMprv/Xkq59iK6IsF6Ki7uxPuMps+nbYhvVIUXqh8Y5iVxx
piFfF2ct8rgxkVm3qBmN
=KK2K
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190426/bdd35867/attachment-0001.html>

From warren.weckesser at gmail.com  Fri Apr 26 22:48:45 2019
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Fri, 26 Apr 2019 22:48:45 -0400
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CAHPuU_aRLWVZUmiJG5fNy6muW3c-0t-pUmKJc3Z1OhwbnXyPxA@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
 <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
 <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>
 <CAEqRcW27eWa_ypS9wU-2UXuQ7mZDCyhBpHzvWOpHDS2Aza19Nw@mail.gmail.com>
 <CADuxUixwV-9G8-PaLnL+M=TSsyE7_nPWMTdGe+k34pXN=tHm5w@mail.gmail.com>
 <CAEqRcW1R5jCuP51aJe3N-s+YaGuCA-FVjK-bYL2_N8V7Y=PqHw@mail.gmail.com>
 <CABL7CQjzT+nZDK8cZSMWHc8QAc_NrGA8CCzFTgGHL2EoYi+Q-Q@mail.gmail.com>
 <CAHPuU_bGtsX=DLn8=G_p+31vwwrxuwBTWS5gdpy3o5h9j=PymA@mail.gmail.com>
 <CAHPuU_a0fMpLp-pA9w7KRx0hEdAnS7ukgMgsk32iJL6OwDxkEw@mail.gmail.com>
 <CAHPuU_Y68Varm-rvOFzsKE0hA3xEtvjtNE7pDcyUf-U-FGRQEw@mail.gmail.com>
 <CAHPuU_aXcwo45Pwp_cCPyWxYq2dkr2Qafb5Gf1zNkzBoyLXQwA@mail.gmail.com>
 <CAHPuU_YEzhD5optup7jF+ZfF9B+KCL47S5e+kq9=urMHfpvRHQ@mail.gmail.com>
 <CAHPuU_aRLWVZUmiJG5fNy6muW3c-0t-pUmKJc3Z1OhwbnXyPxA@mail.gmail.com>
Message-ID: <CAGzF1ufQDg9U92v_q6H-MhcHycYVWE=71J7Ubccpk9HaneHZ4A@mail.gmail.com>

On 4/26/19, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:
> SciPy 1.3.x was branched (not released) at 9:40 am Pacific on April 26/
> 2019
> Master branch is now open for the development of SciPy 1.4.0


Tyler, thanks for all the great work you've been doing on the release!
 Hopefully the release candidate will go smoothly and we'll soon have
a shiny new 1.3.0.

Warren


>
> On Thu, 25 Apr 2019 at 21:50, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:
>
>> There have been some helpful comments on the release notes, but there are
>> sufficient revisions requested that I'll likely delay completion / merge
>> of
>> that PR until morning of April 26 (tomorrow). Please be mindful merging
>> PRs
>> until the notes get merged & I cut the branch, thanks :)
>>
>> On Thu, 25 Apr 2019 at 16:18, Tyler Reddy <tyler.je.reddy at gmail.com>
>> wrote:
>>
>>> The release notes / mailmap PR is open, please do have a look at your
>>> attribution as appropriate: https://github.com/scipy/scipy/pull/10097
>>>
>>> On Thu, 25 Apr 2019 at 10:59, Tyler Reddy <tyler.je.reddy at gmail.com>
>>> wrote:
>>>
>>>> There should be no open issues / PRs with the 1.3.0 milestone now. I'm
>>>> going to work on improving the release notes for a while & open a PR
>>>> for
>>>> that soon-ish.
>>>>
>>>> On Tue, 23 Apr 2019 at 15:31, Tyler Reddy <tyler.je.reddy at gmail.com>
>>>> wrote:
>>>>
>>>>> Down to 5 open PRs with the 1.3.0 milestone:
>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0
>>>>>
>>>>>
>>>>>
>>>>> On Fri, 19 Apr 2019 at 17:54, Tyler Reddy <tyler.je.reddy at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> We are sitting at 20 open PRs with the 1.3.0 milestone:
>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0
>>>>>>
>>>>>> We were close to 30 recently, so let's try to keep it < 20 over the
>>>>>> weekend / moving into next week.
>>>>>>
>>>>>> On Fri, 19 Apr 2019 at 02:48, Ralf Gommers <ralf.gommers at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Apr 19, 2019 at 9:34 AM Mark Mikofski
>>>>>>> <mikofski at berkeley.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Tyler,
>>>>>>>>
>>>>>>>> Thanks again for taking on the release management.
>>>>>>>>
>>>>>>>> Is there anything that we (as contributors) can do to help? Should
>>>>>>>> we be reviewing the 1.3.0 milestone PR's? What would be most
>>>>>>>> helpful
>>>>>>>> specifically?
>>>>>>>>
>>>>>>>
>>>>>>> Help with reviewing can be a very valuable contribution, not just
>>>>>>> for
>>>>>>> a particular release but in general. I think many contributors are
>>>>>>> under
>>>>>>> the impression that you need to be a maintainer to review - this
>>>>>>> definitely
>>>>>>> isn't the case, as long as you have the knowledge to understand the
>>>>>>> code in
>>>>>>> a PR you can help a lot. In particular this is the case for larger
>>>>>>> PRs that
>>>>>>> propose new features, because those are often a lot of work to review
>>>>>>> and
>>>>>>> require domain-specific knowledge. Here is an example (also tagged
>>>>>>> for
>>>>>>> 1.3.0): https://github.com/scipy/scipy/pull/7310, adding a
>>>>>>> logarithmic FFT implementation. Two kinds of things would be
>>>>>>> helpful:
>>>>>>> - someone who understands FFTs well and can review the
>>>>>>> implementation
>>>>>>> - someone who needs the feature, and can test it and confirm that
>>>>>>> everything works as expected
>>>>>>>
>>>>>>> A couple more in the same vein:
>>>>>>> - peak declustering for scipy.signal:
>>>>>>> https://github.com/scipy/scipy/pull/9513
>>>>>>> - RotationSpline for scipy.spatial.transform:
>>>>>>> https://github.com/scipy/scipy/pull/9831
>>>>>>> - support for ARFF relational attributes in scipy.io:
>>>>>>> https://github.com/scipy/scipy/pull/9854
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ralf
>>>>>>>
>>>>>>>
>>>>>>>> I read through the dev guide (
>>>>>>>> https://docs.scipy.org/doc/scipy/reference/dev/index.html) and
>>>>>>>> hacking guidelines (
>>>>>>>> https://docs.scipy.org/doc/scipy/reference/hacking.html), and I
>>>>>>>> looked at the 1.3.0 milestones, and it seems like reviewing PR's
>>>>>>>> with the
>>>>>>>> fewest comments might be the best approach. Would that help?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> On Sun, Apr 14, 2019 at 5:42 PM Matt Haberland <haberland at ucla.edu>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I'd like to get #10026 in there, too. SuiteSparse seems to
>>>>>>>>> routinely speed up `linprog` by a factor of 2-4 (when available).
>>>>>>>>>
>>>>>>>>> On Sun, Apr 14, 2019 at 7:40 AM Mark Alexander Mikofski <
>>>>>>>>> mikofski at berkeley.edu> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Tyler,
>>>>>>>>>>
>>>>>>>>>> Thanks for managing the release again! This is a very important
>>>>>>>>>> service for the SciPy community, and I'm very grateful!
>>>>>>>>>>
>>>>>>>>>> Do you think we could try to add #9568 and #10052 assuming
>>>>>>>>>> everyone agrees they are good?
>>>>>>>>>>
>>>>>>>>>> thanks again!
>>>>>>>>>> Mark
>>>>>>>>>>
>>>>>>>>>> On Sun, Apr 14, 2019 at 2:13 AM Ralf Gommers <
>>>>>>>>>> ralf.gommers at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Apr 14, 2019 at 12:27 AM Andrew Nelson <
>>>>>>>>>>> andyfaff at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Would it be possible to add 9990 and 10002 to 1.3.0, or is that
>>>>>>>>>>>> too ambitious?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Those look like they're in good shape, should be doable. I've
>>>>>>>>>>> added them to the milestone. Tyler can always remove them again
>>>>>>>>>>> if we run
>>>>>>>>>>> out of time.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <
>>>>>>>>>>>> tyler.je.reddy at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is almost 4 months after the (slightly-delayed) 1.2.0
>>>>>>>>>>>>> release on December 17/ 2018, so probably time to plan the
>>>>>>>>>>>>> 1.3.0 release.
>>>>>>>>>>>>> It would be a good idea to look over the PRs with a 1.3.0
>>>>>>>>>>>>> milestone, and
>>>>>>>>>>>>> tag anything else that should have this milestone
>>>>>>>>>>>>> appropriately.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd like to propose the following schedule:
>>>>>>>>>>>>>
>>>>>>>>>>>>> April 25: branch 1.3.x
>>>>>>>>>>>>> April 28: rc1
>>>>>>>>>>>>> May 11: rc2 (if needed)
>>>>>>>>>>>>> May 20: final release
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> That works for me. There may be a few items in
>>>>>>>>>>> https://github.com/scipy/scipy/milestone/37 that we won't get
>>>>>>>>>>> to, but the only real blocker (py37 build issue) on that list is
>>>>>>>>>>> ready to
>>>>>>>>>>> merge.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Ralf
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Mark Mikofski, PhD (2005)
>>>>>>>>>> *Fiat Lux*
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Haberland
>>>>>>>>> Assistant Adjunct Professor in the Program in Computing
>>>>>>>>> Department of Mathematics
>>>>>>>>> 6617A Math Sciences Building, UCLA
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Mark Mikofski, PhD (2005)
>>>>>>>> *Fiat Lux*
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>>
>

From ralf.gommers at gmail.com  Sat Apr 27 05:19:30 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 27 Apr 2019 11:19:30 +0200
Subject: [SciPy-Dev] Proposed SciPy 1.3.0 Release Schedule
In-Reply-To: <CAHPuU_aRLWVZUmiJG5fNy6muW3c-0t-pUmKJc3Z1OhwbnXyPxA@mail.gmail.com>
References: <CAHPuU_Z8Zs2HPmRRkeK1RQvWJ5pynX8kBrTWS5UxDGU0tkb=Mw@mail.gmail.com>
 <CAAbtOZfwnY_VX+gbAR78wxFwn58HK3hxJJNvr3KfYSeGrto=yw@mail.gmail.com>
 <CABL7CQg5bpt+h0tH3dGr0T9G71gk+4Rxs1BYtc10bh3VuXEXKQ@mail.gmail.com>
 <CAEqRcW27eWa_ypS9wU-2UXuQ7mZDCyhBpHzvWOpHDS2Aza19Nw@mail.gmail.com>
 <CADuxUixwV-9G8-PaLnL+M=TSsyE7_nPWMTdGe+k34pXN=tHm5w@mail.gmail.com>
 <CAEqRcW1R5jCuP51aJe3N-s+YaGuCA-FVjK-bYL2_N8V7Y=PqHw@mail.gmail.com>
 <CABL7CQjzT+nZDK8cZSMWHc8QAc_NrGA8CCzFTgGHL2EoYi+Q-Q@mail.gmail.com>
 <CAHPuU_bGtsX=DLn8=G_p+31vwwrxuwBTWS5gdpy3o5h9j=PymA@mail.gmail.com>
 <CAHPuU_a0fMpLp-pA9w7KRx0hEdAnS7ukgMgsk32iJL6OwDxkEw@mail.gmail.com>
 <CAHPuU_Y68Varm-rvOFzsKE0hA3xEtvjtNE7pDcyUf-U-FGRQEw@mail.gmail.com>
 <CAHPuU_aXcwo45Pwp_cCPyWxYq2dkr2Qafb5Gf1zNkzBoyLXQwA@mail.gmail.com>
 <CAHPuU_YEzhD5optup7jF+ZfF9B+KCL47S5e+kq9=urMHfpvRHQ@mail.gmail.com>
 <CAHPuU_aRLWVZUmiJG5fNy6muW3c-0t-pUmKJc3Z1OhwbnXyPxA@mail.gmail.com>
Message-ID: <CABL7CQhCWz5yUUxWGjumi0+CRGBZDOWObPCMprc4rHf0_V5wtw@mail.gmail.com>

On Sat, Apr 27, 2019 at 3:13 AM Tyler Reddy <tyler.je.reddy at gmail.com>
wrote:

> SciPy 1.3.x was branched (not released) at 9:40 am Pacific on April 26/
> 2019
> Master branch is now open for the development of SciPy 1.4.0
>

Great, thanks Tyler!



> On Thu, 25 Apr 2019 at 21:50, Tyler Reddy <tyler.je.reddy at gmail.com>
> wrote:
>
>> There have been some helpful comments on the release notes, but there are
>> sufficient revisions requested that I'll likely delay completion / merge of
>> that PR until morning of April 26 (tomorrow). Please be mindful merging PRs
>> until the notes get merged & I cut the branch, thanks :)
>>
>> On Thu, 25 Apr 2019 at 16:18, Tyler Reddy <tyler.je.reddy at gmail.com>
>> wrote:
>>
>>> The release notes / mailmap PR is open, please do have a look at your
>>> attribution as appropriate: https://github.com/scipy/scipy/pull/10097
>>>
>>> On Thu, 25 Apr 2019 at 10:59, Tyler Reddy <tyler.je.reddy at gmail.com>
>>> wrote:
>>>
>>>> There should be no open issues / PRs with the 1.3.0 milestone now. I'm
>>>> going to work on improving the release notes for a while & open a PR for
>>>> that soon-ish.
>>>>
>>>> On Tue, 23 Apr 2019 at 15:31, Tyler Reddy <tyler.je.reddy at gmail.com>
>>>> wrote:
>>>>
>>>>> Down to 5 open PRs with the 1.3.0 milestone:
>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0
>>>>>
>>>>>
>>>>>
>>>>> On Fri, 19 Apr 2019 at 17:54, Tyler Reddy <tyler.je.reddy at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> We are sitting at 20 open PRs with the 1.3.0 milestone:
>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0
>>>>>>
>>>>>> We were close to 30 recently, so let's try to keep it < 20 over the
>>>>>> weekend / moving into next week.
>>>>>>
>>>>>> On Fri, 19 Apr 2019 at 02:48, Ralf Gommers <ralf.gommers at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Apr 19, 2019 at 9:34 AM Mark Mikofski <mikofski at berkeley.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Tyler,
>>>>>>>>
>>>>>>>> Thanks again for taking on the release management.
>>>>>>>>
>>>>>>>> Is there anything that we (as contributors) can do to help? Should
>>>>>>>> we be reviewing the 1.3.0 milestone PR's? What would be most helpful
>>>>>>>> specifically?
>>>>>>>>
>>>>>>>
>>>>>>> Help with reviewing can be a very valuable contribution, not just
>>>>>>> for a particular release but in general. I think many contributors are
>>>>>>> under the impression that you need to be a maintainer to review - this
>>>>>>> definitely isn't the case, as long as you have the knowledge to understand
>>>>>>> the code in a PR you can help a lot. In particular this is the case for
>>>>>>> larger PRs that propose new features, because those are often a lot of work
>>>>>>> to review and require domain-specific knowledge. Here is an example (also
>>>>>>> tagged for 1.3.0): https://github.com/scipy/scipy/pull/7310, adding
>>>>>>> a logarithmic FFT implementation. Two kinds of things would be helpful:
>>>>>>> - someone who understands FFTs well and can review the implementation
>>>>>>> - someone who needs the feature, and can test it and confirm that
>>>>>>> everything works as expected
>>>>>>>
>>>>>>> A couple more in the same vein:
>>>>>>> - peak declustering for scipy.signal:
>>>>>>> https://github.com/scipy/scipy/pull/9513
>>>>>>> - RotationSpline for scipy.spatial.transform:
>>>>>>> https://github.com/scipy/scipy/pull/9831
>>>>>>> - support for ARFF relational attributes in scipy.io:
>>>>>>> https://github.com/scipy/scipy/pull/9854
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ralf
>>>>>>>
>>>>>>>
>>>>>>>> I read through the dev guide (
>>>>>>>> https://docs.scipy.org/doc/scipy/reference/dev/index.html) and
>>>>>>>> hacking guidelines (
>>>>>>>> https://docs.scipy.org/doc/scipy/reference/hacking.html), and I
>>>>>>>> looked at the 1.3.0 milestones, and it seems like reviewing PR's with the
>>>>>>>> fewest comments might be the best approach. Would that help?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> On Sun, Apr 14, 2019 at 5:42 PM Matt Haberland <haberland at ucla.edu>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I'd like to get #10026 in there, too. SuiteSparse seems to
>>>>>>>>> routinely speed up `linprog` by a factor of 2-4 (when available).
>>>>>>>>>
>>>>>>>>> On Sun, Apr 14, 2019 at 7:40 AM Mark Alexander Mikofski <
>>>>>>>>> mikofski at berkeley.edu> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Tyler,
>>>>>>>>>>
>>>>>>>>>> Thanks for managing the release again! This is a very important
>>>>>>>>>> service for the SciPy community, and I'm very grateful!
>>>>>>>>>>
>>>>>>>>>> Do you think we could try to add #9568 and #10052 assuming
>>>>>>>>>> everyone agrees they are good?
>>>>>>>>>>
>>>>>>>>>> thanks again!
>>>>>>>>>> Mark
>>>>>>>>>>
>>>>>>>>>> On Sun, Apr 14, 2019 at 2:13 AM Ralf Gommers <
>>>>>>>>>> ralf.gommers at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Apr 14, 2019 at 12:27 AM Andrew Nelson <
>>>>>>>>>>> andyfaff at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Would it be possible to add 9990 and 10002 to 1.3.0, or is that
>>>>>>>>>>>> too ambitious?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Those look like they're in good shape, should be doable. I've
>>>>>>>>>>> added them to the milestone. Tyler can always remove them again if we run
>>>>>>>>>>> out of time.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Sun., 14 Apr. 2019, 07:20 Tyler Reddy, <
>>>>>>>>>>>> tyler.je.reddy at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is almost 4 months after the (slightly-delayed) 1.2.0
>>>>>>>>>>>>> release on December 17/ 2018, so probably time to plan the 1.3.0 release.
>>>>>>>>>>>>> It would be a good idea to look over the PRs with a 1.3.0 milestone, and
>>>>>>>>>>>>> tag anything else that should have this milestone appropriately.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd like to propose the following schedule:
>>>>>>>>>>>>>
>>>>>>>>>>>>> April 25: branch 1.3.x
>>>>>>>>>>>>> April 28: rc1
>>>>>>>>>>>>> May 11: rc2 (if needed)
>>>>>>>>>>>>> May 20: final release
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> That works for me. There may be a few items in
>>>>>>>>>>> https://github.com/scipy/scipy/milestone/37 that we won't get
>>>>>>>>>>> to, but the only real blocker (py37 build issue) on that list is ready to
>>>>>>>>>>> merge.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Ralf
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Mark Mikofski, PhD (2005)
>>>>>>>>>> *Fiat Lux*
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Haberland
>>>>>>>>> Assistant Adjunct Professor in the Program in Computing
>>>>>>>>> Department of Mathematics
>>>>>>>>> 6617A Math Sciences Building, UCLA
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Mark Mikofski, PhD (2005)
>>>>>>>> *Fiat Lux*
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190427/809644cf/attachment-0001.html>

From mikofski at berkeley.edu  Sat Apr 27 14:46:21 2019
From: mikofski at berkeley.edu (Mark Mikofski)
Date: Sat, 27 Apr 2019 11:46:21 -0700
Subject: [SciPy-Dev] ANN: SciPy 1.3.0rc1 -- please test
In-Reply-To: <CAHPuU_Y5wAntg1FnpR1fowzN7J1e+WD7P1RMRh-A3bVBJsb3qQ@mail.gmail.com>
References: <CAHPuU_Y5wAntg1FnpR1fowzN7J1e+WD7P1RMRh-A3bVBJsb3qQ@mail.gmail.com>
Message-ID: <CAEqRcW3r7banwuXteXUzMQSjVDNgDC2bc-GX8400g1qx-BNcgw@mail.gmail.com>

Hi Tyler,

I just tested scipy.optimize.cython_optimize using the jupyter notebooks in
this gist:
https://gist.github.com/mikofski/ac30065073d0d32d6ea3569f6e24e5ec
and it seems to be working fine.

procedure:
1. download the scipy-1.3.0rc1 asset for my platform (macosx py37)
https://github.com/scipy/scipy/releases/tag/v1.3.0rc1
2. download a tarball and extract (or clone) the gist of the jupyter
notebook
3. create virtualenv, activate, and install downloaded scipy-1.3.0rc1 wheel
4. also pip install cython, ipython, and jupyter into new venv
5. start jupyter notebook ($ juptyer notebook) navigate to gist, open and
run all

the benchmark times for 1e5 length array on my early 2011 pentium-i5 mac
with 16gb were:

cython loop:   39.2ms
cython prange: 25.3ms
python map:   122ms
no-cython:   3120ms

so best case in this scenario was 100X speedup

thanks!


On Sat, Apr 27, 2019 at 4:35 AM Tyler Reddy <tyler.je.reddy at gmail.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> On behalf of the SciPy development team I'm pleased to announce
> the release candidate SciPy 1.3.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.3.0rc1
> One of a few ways to install the release candidate with pip:
> pip install scipy==1.3.0rc1
>
> ==========================
> SciPy 1.3.0 Release Notes
> ==========================
>
> Note: Scipy 1.3.0 is not released yet!
>
> SciPy 1.3.0 is the culmination of 5 months of hard work. It contains
> many new features, numerous bug-fixes, improved test coverage and better
> documentation. There have been some 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.3.x branch, and on adding new features on the master branch.
>
> This release requires Python 3.5+ and NumPy 1.13.3 or greater.
>
> For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required.
>
> Highlights of this release
> --------------------------
>
> - Three new ``stats`` functions, a rewrite of ``pearsonr``, and an exact
>   computation of the Kolmogorov-Smirnov two-sample test
> - A new Cython API for bounded scalar-function root-finders in `scipy.optimize`
> - Substantial ``CSR`` and ``CSC`` sparse matrix indexing performance
>   improvements
> - Added support for interpolation of rotations with continuous angular
>   rate and acceleration in ``RotationSpline``
>
>
> New features
> ============
>
> `scipy.interpolate` improvements
> --------------------------------
>
> A new class ``CubicHermiteSpline`` is introduced. It is a piecewise-cubic
> interpolator which matches observed values and first derivatives. Existing
> cubic interpolators ``CubicSpline``, ``PchipInterpolator`` and
> ``Akima1DInterpolator`` were made subclasses of ``CubicHermiteSpline``.
>
> `scipy.io` improvements
> -----------------------
>
> For the Attribute-Relation File Format (ARFF) `scipy.io.arff.loadarff`
> now supports relational attributes.
>
> `scipy.io.mmread` can now parse Matrix Market format files with empty lines.
>
> `scipy.linalg` improvements
> ---------------------------
>
> Added wrappers for ``?syconv`` routines, which convert a symmetric matrix
> given by a triangular matrix factorization into two matrices and vice versa.
>
> `scipy.linalg.clarkson_woodruff_transform` now uses an algorithm that leverages
> sparsity. This may provide a 60-90 percent speedup for dense input matrices.
> Truly sparse input matrices should also benefit from the improved sketch
> algorithm, which now correctly runs in ``O(nnz(A))`` time.
>
> Added new functions to calculate symmetric Fiedler matrices and
> Fiedler companion matrices, named `scipy.linalg.fiedler` and
> `scipy.linalg.fiedler_companion`, respectively. These may be used
> for root finding.
>
> `scipy.ndimage` improvements
> ----------------------------
>
> Gaussian filter performances may improve by an order of magnitude in
> some cases, thanks to removal of a dependence on ``np.polynomial``. This
> may impact `scipy.ndimage.gaussian_filter` for example.
>
> `scipy.optimize` improvements
> -----------------------------
>
> The `scipy.optimize.brute` minimizer obtained a new keyword ``workers``, which
> can be used to parallelize computation.
>
> A Cython API for bounded scalar-function root-finders in `scipy.optimize`
> is available in a new module `scipy.optimize.cython_optimize` via ``cimport``.
> This API may be used with ``nogil`` and ``prange`` to loop
> over an array of function arguments to solve for an array of roots more
> quickly than with pure Python.
>
> ``'interior-point'`` is now the default method for ``linprog``, and
> ``'interior-point'`` now uses SuiteSparse for sparse problems when the
> required scikits  (scikit-umfpack and scikit-sparse) are available.
> On benchmark problems (gh-10026), execution time reductions by factors of 2-3
> were typical. Also, a new ``method='revised simplex'`` has been added.
> It is not as fast or robust as ``method='interior-point'``, but it is a faster,
> more robust, and equally accurate substitute for the legacy
> ``method='simplex'``.
>
> ``differential_evolution`` can now use a ``Bounds`` class to specify the
> bounds for the optimizing argument of a function.
>
> `scipy.optimize.dual_annealing` performance improvements related to
> vectorisation of some internal code.
>
> `scipy.signal` improvements
> ---------------------------
>
> Two additional methods of discretization are now supported by
> `scipy.signal.cont2discrete`: ``impulse`` and ``foh``.
>
> `scipy.signal.firls` now uses faster solvers
>
> `scipy.signal.detrend` now has a lower physical memory footprint in some
> cases, which may be leveraged using the new ``overwrite_data`` keyword argument
>
> `scipy.signal.firwin` ``pass_zero`` argument now accepts new string arguments
> that allow specification of the desired filter type: ``'bandpass'``,
> ``'lowpass'``, ``'highpass'``, and ``'bandstop'``
>
> `scipy.signal.sosfilt` may have improved performance due to lower retention
> of the global interpreter lock (GIL) in algorithm
>
> `scipy.sparse` improvements
> ---------------------------
>
> A new keyword was added to ``csgraph.dijsktra`` that
> allows users to query the shortest path to ANY of the passed in indices,
> as opposed to the shortest path to EVERY passed index.
>
> `scipy.sparse.linalg.lsmr` performance has been improved by roughly 10 percent
> on large problems
>
> Improved performance and reduced physical memory footprint of the algorithm
> used by `scipy.sparse.linalg.lobpcg`
>
> ``CSR`` and ``CSC`` sparse matrix fancy indexing performance has been
> improved substantially
>
> `scipy.spatial` improvements
> ----------------------------
>
> `scipy.spatial.ConvexHull` now has a ``good`` attribute that can be used
> alongsize the ``QGn`` Qhull options to determine which external facets of a
> convex hull are visible from an external query point.
>
> `scipy.spatial.cKDTree.query_ball_point` has been modernized to use some newer
> Cython features, including GIL handling and exception translation. An issue
> with ``return_sorted=True`` and scalar queries was fixed, and a new mode named
> ``return_length`` was added. ``return_length`` only computes the length of the
> returned indices list instead of allocating the array every time.
>
> `scipy.spatial.transform.RotationSpline` has been added to enable interpolation
> of rotations with continuous angular rates and acceleration
>
> `scipy.stats` improvements
> --------------------------
>
> Added a new function to compute the Epps-Singleton test statistic,
> `scipy.stats.epps_singleton_2samp`, which can be applied to continuous and
> discrete distributions.
>
> New functions `scipy.stats.median_absolute_deviation` and `scipy.stats.gstd`
> (geometric standard deviation) were added. The `scipy.stats.combine_pvalues`
> method now supports ``pearson``,  ``tippett`` and ``mudholkar_george`` pvalue
> combination methods.
>
> The `scipy.stats.ortho_group` and `scipy.stats.special_ortho_group`
> ``rvs(dim)`` functions' algorithms were updated from a ``O(dim^4)``
> implementation to a ``O(dim^3)`` which gives large speed improvements
> for ``dim>100``.
>
> A rewrite of `scipy.stats.pearsonr` to use a more robust algorithm,
> provide meaningful exceptions and warnings on potentially pathological input,
> and fix at least five separate reported issues in the original implementation.
>
> Improved the precision of ``hypergeom.logcdf`` and ``hypergeom.logsf``.
>
> Added exact computation for Kolmogorov-Smirnov (KS) two-sample test, replacing
> the previously approximate computation for the two-sided test `stats.ks_2samp`.
> Also added a one-sided, two-sample KS test, and a keyword ``alternative`` to
> `stats.ks_2samp`.
>
> Backwards incompatible changes
> ==============================
>
> `scipy.interpolate` changes
> ---------------------------
>
> Functions from ``scipy.interpolate`` (``spleval``, ``spline``, ``splmake``,
> and ``spltopp``) and functions from ``scipy.misc`` (``bytescale``,
> ``fromimage``, ``imfilter``, ``imread``, ``imresize``, ``imrotate``,
> ``imsave``, ``imshow``, ``toimage``) have been removed. The former set has
> been deprecated since v0.19.0 and the latter has been deprecated since v1.0.0.
> Similarly, aliases from ``scipy.misc`` (``comb``, ``factorial``,
> ``factorial2``, ``factorialk``, ``logsumexp``, ``pade``, ``info``, ``source``,
> ``who``) which have been deprecated since v1.0.0 are removed.
> `SciPy documentation for
> v1.1.0 <https://docs.scipy.org/doc/scipy-1.1.0/reference/misc.html>`__
> can be used to track the new import locations for the relocated functions.
>
> `scipy.linalg` changes
> ----------------------
>
> For ``pinv``, ``pinv2``, and ``pinvh``, the default cutoff values are changed
> for consistency (see the docs for the actual values).
>
> `scipy.stats` changes
> ---------------------
>
> Previously, ``ks_2samp(data1, data2)`` would run a two-sided test and return
> the approximated p-value. The new signature, ``ks_2samp(data1, data2,
> alternative="two-sided", method="auto")``, still runs the two-sided test by
> default but returns the exact p-value for small samples and the approximated
> value for large samples. ``method="asymp"`` would be equivalent to the
> old version but ``auto`` is the better choice.
>
> Other changes
> =============
>
> Our tutorial has been expanded with a new section on global optimizers
>
> There has been a rework of the ``stats.distributions`` tutorials.
>
> `scipy.optimize` now correctly sets the convergence flag of the result to
> ``CONVERR``, a convergence error, for bounded scalar-function root-finders
> if the maximum iterations has been exceeded, ``disp`` is false, and
> ``full_output`` is true.
>
> `scipy.optimize.curve_fit` no longer fails if ``xdata`` and ``ydata`` dtypes
> differ; they are both now automatically cast to ``float64``.
>
> `scipy.ndimage` functions including ``binary_erosion``, ``binary_closing``, and
> ``binary_dilation`` now require an integer value for the number of iterations,
> which alleviates a number of reported issues.
>
> Fixed normal approximation in case ``zero_method == "pratt"`` in
> `scipy.stats.wilcoxon`.
>
> Fixes for incorrect probabilities, broadcasting issues and thread-safety
> related to stats distributions setting member variables inside ``_argcheck()``.
>
> `scipy.optimize.newton` now correctly raises a ``RuntimeError``, when default
> arguments are used, in the case that a derivative of value zero is obtained,
> which is a special case of failing to converge.
>
> A draft toolchain roadmap is now available, laying out a compatibility plan
> including Python versions, C standards, and NumPy versions.
>
>
> Authors
> =======
>
> * ananyashreyjain +
> * ApamNapat +
> * Scott Calabrese Barton +
> * Christoph Baumgarten
> * Peter Bell +
> * Jacob Blomgren +
> * Doctor Bob +
> * Mana Borwornpadungkitti +
> * Matthew Brett
> * Evgeni Burovski
> * CJ Carey
> * Vega Theil Carstensen +
> * Robert Cimrman
> * Forrest Collman +
> * Pietro Cottone +
> * David +
> * Idan David +
> * Christoph Deil
> * Dieter Werthm?ller
> * Conner DiPaolo +
> * Dowon
> * Michael Dunphy +
> * Peter Andreas Entschev +
> * G?k?en Eraslan +
> * Johann Faouzi +
> * Yu Feng
> * Piotr Figiel +
> * Matthew H Flamm
> * Franz Forstmayr +
> * Christoph Gohlke
> * Richard Janis Goldschmidt +
> * Ralf Gommers
> * Lars Grueter
> * Sylvain Gubian
> * Matt Haberland
> * Yaroslav Halchenko
> * Charles Harris
> * Lindsey Hiltner
> * JakobStruye +
> * He Jia +
> * Jwink3101 +
> * Greg Kiar +
> * Julius Bier Kirkegaard
> * John Kirkham +
> * Thomas Kluyver
> * Vladimir Korolev +
> * Joseph Kuo +
> * Michael Lamparski +
> * Eric Larson
> * Denis Laxalde
> * Katrin Leinweber
> * Jesse Livezey
> * ludcila +
> * Dhruv Madeka +
> * Magnus +
> * Nikolay Mayorov
> * Mark Mikofski
> * Jarrod Millman
> * Markus Mohrhard +
> * Eric Moore
> * Andrew Nelson
> * Aki Nishimura +
> * OGordon100 +
> * Petar Mlinari? +
> * Stefan Peterson
> * Matti Picus +
> * Ilhan Polat
> * Aaron Pries +
> * Matteo Ravasi +
> * Tyler Reddy
> * Ashton Reimer +
> * Joscha Reimer
> * rfezzani +
> * Riadh +
> * Lucas Roberts
> * Heshy Roskes +
> * Mirko Scholz +
> * Taylor D. Scott +
> * Srikrishna Sekhar +
> * Kevin Sheppard +
> * Sourav Singh
> * skjerns +
> * Kai Striega
> * SyedSaifAliAlvi +
> * Gopi Manohar T +
> * Albert Thomas +
> * Timon +
> * Paul van Mulbregt
> * Jacob Vanderplas
> * Daniel Vargas +
> * Pauli Virtanen
> * VNMabus +
> * Stefan van der Walt
> * Warren Weckesser
> * Josh Wilson
> * Nate Yoder +
> * Roman Yurchak
>
> A total of 97 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.3.0
> -----------------------
>
> * `#1320 <https://github.com/scipy/scipy/issues/1320>`__: scipy.stats.distribution: problem with self.a, self.b if they...
> * `#2002 <https://github.com/scipy/scipy/issues/2002>`__: members set in scipy.stats.distributions.##._argcheck (Trac #1477)
> * `#2823 <https://github.com/scipy/scipy/issues/2823>`__: distribution methods add tmp
> * `#3220 <https://github.com/scipy/scipy/issues/3220>`__: Scipy.opimize.fmin_powell direc argument syntax unclear
> * `#3728 <https://github.com/scipy/scipy/issues/3728>`__: scipy.stats.pearsonr: possible bug with zero variance input
> * `#6805 <https://github.com/scipy/scipy/issues/6805>`__: error-in-scipy-wilcoxon-signed-rank-test-for-equal-series
> * `#6873 <https://github.com/scipy/scipy/issues/6873>`__: 'stats.boxcox' return all same values
> * `#7117 <https://github.com/scipy/scipy/issues/7117>`__: Warn users when using float32 input data to curve_fit and friends
> * `#7632 <https://github.com/scipy/scipy/issues/7632>`__: it's not possible to tell the \`optimize.least_squares\` solver...
> * `#7730 <https://github.com/scipy/scipy/issues/7730>`__: stats.pearsonr: Potential division by zero for dataset of length...
> * `#7933 <https://github.com/scipy/scipy/issues/7933>`__: stats.truncnorm fails when providing values outside truncation...
> * `#8033 <https://github.com/scipy/scipy/issues/8033>`__: Add standard filter types to firwin to set pass_zero intuitively...
> * `#8600 <https://github.com/scipy/scipy/issues/8600>`__: lfilter.c.src zfill has erroneous header
> * `#8692 <https://github.com/scipy/scipy/issues/8692>`__: Non-negative values of \`stats.hypergeom.logcdf\`
> * `#8734 <https://github.com/scipy/scipy/issues/8734>`__: Enable pip build isolation
> * `#8861 <https://github.com/scipy/scipy/issues/8861>`__: scipy.linalg.pinv gives wrong result while scipy.linalg.pinv2...
> * `#8915 <https://github.com/scipy/scipy/issues/8915>`__: need to fix macOS build against older numpy versions
> * `#8980 <https://github.com/scipy/scipy/issues/8980>`__: scipy.stats.pearsonr overflows with high values of x and y
> * `#9226 <https://github.com/scipy/scipy/issues/9226>`__: BUG: signal: SystemError: <built-in function _linear_filter>...
> * `#9254 <https://github.com/scipy/scipy/issues/9254>`__: BUG: root finders brentq, etc, flag says "converged" even if...
> * `#9308 <https://github.com/scipy/scipy/issues/9308>`__: Test failure - test_initial_constraints_as_canonical
> * `#9353 <https://github.com/scipy/scipy/issues/9353>`__: scipy.stats.pearsonr returns r=1 if r_num/r_den = inf
> * `#9359 <https://github.com/scipy/scipy/issues/9359>`__: Planck distribution is a geometric distribution
> * `#9381 <https://github.com/scipy/scipy/issues/9381>`__: linregress should warn user in 2x2 array case
> * `#9406 <https://github.com/scipy/scipy/issues/9406>`__: BUG: stats: In pearsonr, when r is nan, the p-value must also...
> * `#9437 <https://github.com/scipy/scipy/issues/9437>`__: Cannot create sparse matrix from size_t indexes
> * `#9518 <https://github.com/scipy/scipy/issues/9518>`__: Relational attributes in loadarff
> * `#9551 <https://github.com/scipy/scipy/issues/9551>`__: BUG: scipy.optimize.newton says the root of x^2+1 is zero.
> * `#9564 <https://github.com/scipy/scipy/issues/9564>`__: rv_sample accepts invalid input in scipy.stats
> * `#9565 <https://github.com/scipy/scipy/issues/9565>`__: improper handling of multidimensional input in stats.rv_sample
> * `#9581 <https://github.com/scipy/scipy/issues/9581>`__: Least-squares minimization fails silently when x and y data are...
> * `#9587 <https://github.com/scipy/scipy/issues/9587>`__: Outdated value for scipy.constants.au
> * `#9611 <https://github.com/scipy/scipy/issues/9611>`__: Overflow error with new way of p-value calculation in kendall...
> * `#9645 <https://github.com/scipy/scipy/issues/9645>`__: \`scipy.stats.mode\` crashes with variable length arrays (\`dtype=object\`)
> * `#9734 <https://github.com/scipy/scipy/issues/9734>`__: PendingDeprecationWarning for np.matrix with pytest
> * `#9786 <https://github.com/scipy/scipy/issues/9786>`__: stats.ks_2samp() misleading for small data sets.
> * `#9790 <https://github.com/scipy/scipy/issues/9790>`__: Excessive memory usage on detrend
> * `#9801 <https://github.com/scipy/scipy/issues/9801>`__: dual_annealing does not set the success attribute in OptimizeResult
> * `#9833 <https://github.com/scipy/scipy/issues/9833>`__: IntegrationWarning from mielke.stats() during build of html doc.
> * `#9835 <https://github.com/scipy/scipy/issues/9835>`__: scipy.signal.firls seems to be inefficient versus MATLAB firls
> * `#9864 <https://github.com/scipy/scipy/issues/9864>`__: Curve_fit does not check for empty input data if called with...
> * `#9869 <https://github.com/scipy/scipy/issues/9869>`__: scipy.ndimage.label: Minor documentation issue
> * `#9882 <https://github.com/scipy/scipy/issues/9882>`__: format at the wrong paranthesis in scipy.spatial.transform
> * `#9889 <https://github.com/scipy/scipy/issues/9889>`__: scipy.signal.find_peaks minor documentation issue
> * `#9890 <https://github.com/scipy/scipy/issues/9890>`__: Minkowski p-norm Issues in cKDTree For Values Other Than 2 Or...
> * `#9896 <https://github.com/scipy/scipy/issues/9896>`__: scipy.stats._argcheck sets (not just checks) values
> * `#9905 <https://github.com/scipy/scipy/issues/9905>`__: Memory error in ndimage.binary_erosion
> * `#9909 <https://github.com/scipy/scipy/issues/9909>`__: binary_dilation/erosion/closing crashes when iterations is float
> * `#9919 <https://github.com/scipy/scipy/issues/9919>`__: BUG: \`coo_matrix\` does not validate the \`shape\` argument.
> * `#9982 <https://github.com/scipy/scipy/issues/9982>`__: lsq_linear hangs/infinite loop with 'trf' method
> * `#10003 <https://github.com/scipy/scipy/issues/10003>`__: exponnorm.pdf returns NAN for small K
> * `#10011 <https://github.com/scipy/scipy/issues/10011>`__: Incorrect check for invalid rotation plane in scipy.ndimage.rotate
> * `#10024 <https://github.com/scipy/scipy/issues/10024>`__: Fails to build from git
> * `#10048 <https://github.com/scipy/scipy/issues/10048>`__: DOC: scipy.optimize.root_scalar
> * `#10068 <https://github.com/scipy/scipy/issues/10068>`__: DOC: scipy.interpolate.splev
> * `#10074 <https://github.com/scipy/scipy/issues/10074>`__: BUG: \`expm\` calculates the wrong coefficients in the backward...
>
>
> Pull requests for 1.3.0
> -----------------------
>
> * `#7827 <https://github.com/scipy/scipy/pull/7827>`__: ENH: sparse: overhaul of sparse matrix indexing
> * `#8431 <https://github.com/scipy/scipy/pull/8431>`__: ENH: Cython optimize zeros api
> * `#8743 <https://github.com/scipy/scipy/pull/8743>`__: DOC: Updated linalg.pinv, .pinv2, .pinvh docstrings
> * `#8744 <https://github.com/scipy/scipy/pull/8744>`__: DOC: added examples to remez docstring
> * `#9227 <https://github.com/scipy/scipy/pull/9227>`__: DOC: update description of "direc" parameter of "fmin_powell"
> * `#9263 <https://github.com/scipy/scipy/pull/9263>`__: ENH: optimize: added "revised simplex" for scipy.optimize.linprog
> * `#9325 <https://github.com/scipy/scipy/pull/9325>`__: DEP: Remove deprecated functions for 1.3.0
> * `#9330 <https://github.com/scipy/scipy/pull/9330>`__: Add note on push and pull affine transformations
> * `#9423 <https://github.com/scipy/scipy/pull/9423>`__: DOC: Clearly state how 2x2 input arrays are handled in stats.linregress
> * `#9428 <https://github.com/scipy/scipy/pull/9428>`__: ENH: parallelised brute
> * `#9438 <https://github.com/scipy/scipy/pull/9438>`__: BUG: Initialize coo matrix with size_t indexes
> * `#9455 <https://github.com/scipy/scipy/pull/9455>`__: MAINT: Speed up get_(lapack,blas)_func
> * `#9465 <https://github.com/scipy/scipy/pull/9465>`__: MAINT: Clean up optimize.zeros C solvers interfaces/code.
> * `#9477 <https://github.com/scipy/scipy/pull/9477>`__: DOC: linalg: fix lstsq docstring on residues shape
> * `#9478 <https://github.com/scipy/scipy/pull/9478>`__: DOC: Add docstring examples for rosen functions
> * `#9479 <https://github.com/scipy/scipy/pull/9479>`__: DOC: Add docstring example for ai_zeros and bi_zeros
> * `#9480 <https://github.com/scipy/scipy/pull/9480>`__: MAINT: linalg: lstsq clean up
> * `#9489 <https://github.com/scipy/scipy/pull/9489>`__: DOC: roadmap update for changes over the last year.
> * `#9492 <https://github.com/scipy/scipy/pull/9492>`__: MAINT: stats: Improve implementation of chi2 ppf method.
> * `#9497 <https://github.com/scipy/scipy/pull/9497>`__: DOC: Improve docstrings sparse.linalg.isolve
> * `#9499 <https://github.com/scipy/scipy/pull/9499>`__: DOC: Replace "Scipy" with "SciPy" in the .rst doc files for consistency.
> * `#9500 <https://github.com/scipy/scipy/pull/9500>`__: DOC: Document the toolchain and its roadmap.
> * `#9505 <https://github.com/scipy/scipy/pull/9505>`__: DOC: specify which definition of skewness is used
> * `#9511 <https://github.com/scipy/scipy/pull/9511>`__: DEP: interpolate: remove deprecated interpolate_wrapper
> * `#9517 <https://github.com/scipy/scipy/pull/9517>`__: BUG: improve error handling in stats.iqr
> * `#9522 <https://github.com/scipy/scipy/pull/9522>`__: ENH: Add Fiedler and fiedler companion to special matrices
> * `#9526 <https://github.com/scipy/scipy/pull/9526>`__: TST: relax precision requirements in signal.correlate tests
> * `#9529 <https://github.com/scipy/scipy/pull/9529>`__: DOC: fix missing random seed in optimize.newton example
> * `#9533 <https://github.com/scipy/scipy/pull/9533>`__: MAINT: Use list comprehension when possible
> * `#9537 <https://github.com/scipy/scipy/pull/9537>`__: DOC: add a "big picture" roadmap
> * `#9538 <https://github.com/scipy/scipy/pull/9538>`__: DOC: Replace "Numpy" with "NumPy" in .py, .rst and .txt doc files...
> * `#9539 <https://github.com/scipy/scipy/pull/9539>`__: ENH: add two-sample test (Epps-Singleton) to scipy.stats
> * `#9559 <https://github.com/scipy/scipy/pull/9559>`__: DOC: add section on global optimizers to tutorial
> * `#9561 <https://github.com/scipy/scipy/pull/9561>`__: ENH: remove noprefix.h, change code appropriately
> * `#9562 <https://github.com/scipy/scipy/pull/9562>`__: MAINT: stats: Rewrite pearsonr.
> * `#9563 <https://github.com/scipy/scipy/pull/9563>`__: BUG: Minor bug fix Callback in linprog(method='simplex')
> * `#9568 <https://github.com/scipy/scipy/pull/9568>`__: MAINT: raise runtime error for newton with zeroder if disp true,...
> * `#9570 <https://github.com/scipy/scipy/pull/9570>`__: Correct docstring in show_options in optimize. Fixes #9407
> * `#9573 <https://github.com/scipy/scipy/pull/9573>`__: BUG fixes range of pk variable pre-check
> * `#9577 <https://github.com/scipy/scipy/pull/9577>`__: TST: fix minor issue in a signal.stft test.
> * `#9580 <https://github.com/scipy/scipy/pull/9580>`__: Included blank line before list - Fixes #8658
> * `#9582 <https://github.com/scipy/scipy/pull/9582>`__: MAINT: drop Python 2.7 and 3.4
> * `#9588 <https://github.com/scipy/scipy/pull/9588>`__: MAINT: update \`constants.astronomical_unit\` to new 2012 value.
> * `#9592 <https://github.com/scipy/scipy/pull/9592>`__: TST: Add 32-bit testing to CI
> * `#9593 <https://github.com/scipy/scipy/pull/9593>`__: DOC: Replace cumulative density with cumulative distribution
> * `#9596 <https://github.com/scipy/scipy/pull/9596>`__: TST: remove VC 9.0 from Azure CI
> * `#9599 <https://github.com/scipy/scipy/pull/9599>`__: Hyperlink DOI to preferred resolver
> * `#9601 <https://github.com/scipy/scipy/pull/9601>`__: DEV: try to limit GC memory use on PyPy
> * `#9603 <https://github.com/scipy/scipy/pull/9603>`__: MAINT: improve logcdf and logsf of hypergeometric distribution
> * `#9605 <https://github.com/scipy/scipy/pull/9605>`__: Reference to pylops in LinearOperator notes and ARPACK example
> * `#9617 <https://github.com/scipy/scipy/pull/9617>`__: TST: reduce max memory usage for sparse.linalg.lgmres test
> * `#9619 <https://github.com/scipy/scipy/pull/9619>`__: FIX: Sparse matrix addition/subtraction eliminates explicit zeros
> * `#9621 <https://github.com/scipy/scipy/pull/9621>`__: bugfix in rv_sample in scipy.stats
> * `#9622 <https://github.com/scipy/scipy/pull/9622>`__: MAINT: Raise error in directed_hausdorff distance
> * `#9623 <https://github.com/scipy/scipy/pull/9623>`__: DOC: Build docs with warnings as errors
> * `#9625 <https://github.com/scipy/scipy/pull/9625>`__: Return the number of calls to 'hessp' (not just 'hess') in trust...
> * `#9627 <https://github.com/scipy/scipy/pull/9627>`__: BUG: ignore empty lines in mmio
> * `#9637 <https://github.com/scipy/scipy/pull/9637>`__: Function to calculate the MAD of an array
> * `#9646 <https://github.com/scipy/scipy/pull/9646>`__: BUG: stats: mode for objects w/ndim > 1
> * `#9648 <https://github.com/scipy/scipy/pull/9648>`__: Add \`stats.contingency\` to refguide-check
> * `#9650 <https://github.com/scipy/scipy/pull/9650>`__: ENH: many lobpcg() algorithm improvements
> * `#9652 <https://github.com/scipy/scipy/pull/9652>`__: Move misc.doccer to _lib.doccer
> * `#9660 <https://github.com/scipy/scipy/pull/9660>`__: ENH: add pearson, tippett, and mudholkar-george to combine_pvalues
> * `#9661 <https://github.com/scipy/scipy/pull/9661>`__: BUG: Fix ksone right-hand endpoint, documentation and tests.
> * `#9664 <https://github.com/scipy/scipy/pull/9664>`__: ENH: adding multi-target dijsktra performance enhancement
> * `#9670 <https://github.com/scipy/scipy/pull/9670>`__: MAINT: link planck and geometric distribution in scipy.stats
> * `#9676 <https://github.com/scipy/scipy/pull/9676>`__: ENH: optimize: change default linprog method to interior-point
> * `#9685 <https://github.com/scipy/scipy/pull/9685>`__: Added reference to ndimage.filters.median_filter
> * `#9705 <https://github.com/scipy/scipy/pull/9705>`__: Fix coefficients in expm helper function
> * `#9711 <https://github.com/scipy/scipy/pull/9711>`__: Release the GIL during sosfilt processing for simple types
> * `#9721 <https://github.com/scipy/scipy/pull/9721>`__: ENH: Convexhull visiblefacets
> * `#9723 <https://github.com/scipy/scipy/pull/9723>`__: BLD: Modify rv_generic._construct_doc to print out failing distribution...
> * `#9726 <https://github.com/scipy/scipy/pull/9726>`__: BUG: Fix small issues with \`signal.lfilter'
> * `#9729 <https://github.com/scipy/scipy/pull/9729>`__: BUG: Typecheck iterations for binary image operations
> * `#9730 <https://github.com/scipy/scipy/pull/9730>`__: ENH: reduce sizeof(NI_WatershedElement) by 20%
> * `#9731 <https://github.com/scipy/scipy/pull/9731>`__: ENH: remove suspicious sequence of type castings
> * `#9739 <https://github.com/scipy/scipy/pull/9739>`__: BUG: qr_updates fails if u is exactly in span Q
> * `#9749 <https://github.com/scipy/scipy/pull/9749>`__: BUG: MapWrapper.__exit__ should terminate
> * `#9753 <https://github.com/scipy/scipy/pull/9753>`__: ENH: Added exact computation for Kolmogorov-Smirnov two-sample...
> * `#9755 <https://github.com/scipy/scipy/pull/9755>`__: DOC: Added example for signal.impulse, copied from impulse2
> * `#9756 <https://github.com/scipy/scipy/pull/9756>`__: DOC: Added docstring example for iirdesign
> * `#9757 <https://github.com/scipy/scipy/pull/9757>`__: DOC: Added examples for step functions
> * `#9759 <https://github.com/scipy/scipy/pull/9759>`__: ENH: Allow pass_zero to act like btype
> * `#9760 <https://github.com/scipy/scipy/pull/9760>`__: DOC: Added docstring for lp2bs
> * `#9761 <https://github.com/scipy/scipy/pull/9761>`__: DOC: Added docstring and example for lp2bp
> * `#9764 <https://github.com/scipy/scipy/pull/9764>`__: BUG: Catch internal warnings for matrix
> * `#9766 <https://github.com/scipy/scipy/pull/9766>`__: ENH: Speed up _gaussian_kernel1d by removing dependence on np.polynomial
> * `#9769 <https://github.com/scipy/scipy/pull/9769>`__: BUG: Fix Cubic Spline Read Only issues
> * `#9773 <https://github.com/scipy/scipy/pull/9773>`__: DOC: Several docstrings
> * `#9774 <https://github.com/scipy/scipy/pull/9774>`__: TST: bump Azure CI OpenBLAS version to match wheels
> * `#9775 <https://github.com/scipy/scipy/pull/9775>`__: DOC: Improve clarity of cov_x documentation for scipy.optimize.leastsq
> * `#9779 <https://github.com/scipy/scipy/pull/9779>`__: ENH: dual_annealing vectorise visit_fn
> * `#9788 <https://github.com/scipy/scipy/pull/9788>`__: TST, BUG: f2py-related issues with NumPy < 1.14.0
> * `#9791 <https://github.com/scipy/scipy/pull/9791>`__: BUG: fix amax constraint not enforced in scalar_search_wolfe2
> * `#9792 <https://github.com/scipy/scipy/pull/9792>`__: ENH: Allow inplace copying in place in "detrend" function
> * `#9795 <https://github.com/scipy/scipy/pull/9795>`__: DOC: Fix/update docstring for dstn and dst
> * `#9796 <https://github.com/scipy/scipy/pull/9796>`__: MAINT: Allow None tolerances in least_squares
> * `#9798 <https://github.com/scipy/scipy/pull/9798>`__: BUG: fixes abort trap 6 error in scipy issue 9785 in unit tests
> * `#9807 <https://github.com/scipy/scipy/pull/9807>`__: MAINT: improve doc and add alternative keyword to wilcoxon in...
> * `#9808 <https://github.com/scipy/scipy/pull/9808>`__: Fix PPoly integrate and test for CubicSpline
> * `#9810 <https://github.com/scipy/scipy/pull/9810>`__: ENH: Add the geometric standard deviation function
> * `#9811 <https://github.com/scipy/scipy/pull/9811>`__: MAINT: remove invalid derphi default None value in scalar_search_wolfe2
> * `#9813 <https://github.com/scipy/scipy/pull/9813>`__: Adapt hamming distance in C to support weights
> * `#9817 <https://github.com/scipy/scipy/pull/9817>`__: DOC: Copy solver description to solver modules
> * `#9829 <https://github.com/scipy/scipy/pull/9829>`__: ENH: Add FOH and equivalent impulse response discretizations...
> * `#9831 <https://github.com/scipy/scipy/pull/9831>`__: ENH: Implement RotationSpline
> * `#9834 <https://github.com/scipy/scipy/pull/9834>`__: DOC: Change mielke distribution default parameters to ensure...
> * `#9838 <https://github.com/scipy/scipy/pull/9838>`__: ENH: Use faster solvers for firls
> * `#9854 <https://github.com/scipy/scipy/pull/9854>`__: ENH: loadarff now supports relational attributes.
> * `#9856 <https://github.com/scipy/scipy/pull/9856>`__: integrate.bvp - improve handling of nonlinear boundary conditions
> * `#9862 <https://github.com/scipy/scipy/pull/9862>`__: TST: reduce Appveyor CI load
> * `#9874 <https://github.com/scipy/scipy/pull/9874>`__: DOC: Update requirements in release notes
> * `#9883 <https://github.com/scipy/scipy/pull/9883>`__: BUG: fixed parenthesis in spatial.rotation
> * `#9884 <https://github.com/scipy/scipy/pull/9884>`__: ENH: Use Sparsity in Clarkson-Woodruff Sketch
> * `#9888 <https://github.com/scipy/scipy/pull/9888>`__: MAINT: Replace NumPy aliased functions
> * `#9892 <https://github.com/scipy/scipy/pull/9892>`__: BUG: Fix 9890 query_ball_point returns wrong result when p is...
> * `#9893 <https://github.com/scipy/scipy/pull/9893>`__: BUG: curve_fit doesn't check for empty input if called with bounds
> * `#9894 <https://github.com/scipy/scipy/pull/9894>`__: scipy.signal.find_peaks documentation error
> * `#9898 <https://github.com/scipy/scipy/pull/9898>`__: BUG: Set success attribute in OptimizeResult. See #9801
> * `#9900 <https://github.com/scipy/scipy/pull/9900>`__: BUG: Restrict rv_generic._argcheck() and its overrides from setting...
> * `#9906 <https://github.com/scipy/scipy/pull/9906>`__: fixed a bug in kde logpdf
> * `#9911 <https://github.com/scipy/scipy/pull/9911>`__: DOC: replace example for "np.select" with the one from numpy...
> * `#9912 <https://github.com/scipy/scipy/pull/9912>`__: BF(DOC): point to numpy.select instead of plain (python) .select
> * `#9914 <https://github.com/scipy/scipy/pull/9914>`__: DOC: change ValueError message in _validate_pad of signaltools.
> * `#9915 <https://github.com/scipy/scipy/pull/9915>`__: cKDTree query_ball_point improvements
> * `#9918 <https://github.com/scipy/scipy/pull/9918>`__: Update ckdtree.pyx with boxsize argument in docstring
> * `#9920 <https://github.com/scipy/scipy/pull/9920>`__: BUG: sparse: Validate explicit shape if given with dense argument...
> * `#9924 <https://github.com/scipy/scipy/pull/9924>`__: BLD: add back pyproject.toml
> * `#9931 <https://github.com/scipy/scipy/pull/9931>`__: Fix empty constraint
> * `#9935 <https://github.com/scipy/scipy/pull/9935>`__: DOC: fix references for stats.f_oneway
> * `#9936 <https://github.com/scipy/scipy/pull/9936>`__: Revert gh-9619: "FIX: Sparse matrix addition/subtraction eliminates...
> * `#9937 <https://github.com/scipy/scipy/pull/9937>`__: MAINT: fix PEP8 issues and update to pycodestyle 2.5.0
> * `#9939 <https://github.com/scipy/scipy/pull/9939>`__: DOC: correct \`structure\` description in \`ndimage.label\` docstring
> * `#9940 <https://github.com/scipy/scipy/pull/9940>`__: MAINT: remove extraneous distutils copies
> * `#9945 <https://github.com/scipy/scipy/pull/9945>`__: ENH: differential_evolution can use Bounds object
> * `#9949 <https://github.com/scipy/scipy/pull/9949>`__: Added 'std' to add doctstrings since it is a \`known_stats\`...
> * `#9953 <https://github.com/scipy/scipy/pull/9953>`__: DOC: Documentation cleanup for stats tutorials.
> * `#9962 <https://github.com/scipy/scipy/pull/9962>`__: __repr__ for Bounds
> * `#9971 <https://github.com/scipy/scipy/pull/9971>`__: ENH: Improve performance of lsmr
> * `#9987 <https://github.com/scipy/scipy/pull/9987>`__: CI: pin Sphinx version to 1.8.5
> * `#9990 <https://github.com/scipy/scipy/pull/9990>`__: ENH: constraint violation
> * `#9991 <https://github.com/scipy/scipy/pull/9991>`__: BUG: Avoid inplace modification of input array in newton
> * `#9995 <https://github.com/scipy/scipy/pull/9995>`__: MAINT: sparse.csgraph: Add cdef to stop build warning.
> * `#9996 <https://github.com/scipy/scipy/pull/9996>`__: BUG: Make minimize_quadratic_1d work with infinite bounds correctly
> * `#10004 <https://github.com/scipy/scipy/pull/10004>`__: BUG: Fix unbound local error in linprog - simplex.
> * `#10007 <https://github.com/scipy/scipy/pull/10007>`__: BLD: fix Python 3.7 build with build isolation
> * `#10009 <https://github.com/scipy/scipy/pull/10009>`__: BUG: Make sure that _binary_erosion only accepts an integer number...
> * `#10016 <https://github.com/scipy/scipy/pull/10016>`__: Update link to airspeed-velocity
> * `#10017 <https://github.com/scipy/scipy/pull/10017>`__: DOC: Update \`interpolate.LSQSphereBivariateSpline\` to include...
> * `#10018 <https://github.com/scipy/scipy/pull/10018>`__: MAINT: special: Fix a few warnings that occur when compiling...
> * `#10019 <https://github.com/scipy/scipy/pull/10019>`__: TST: Azure summarizes test failures
> * `#10021 <https://github.com/scipy/scipy/pull/10021>`__: ENH: Introduce CubicHermiteSpline
> * `#10022 <https://github.com/scipy/scipy/pull/10022>`__: BENCH: Increase cython version in asv to fix benchmark builds
> * `#10023 <https://github.com/scipy/scipy/pull/10023>`__: BUG: Avoid exponnorm producing nan for small K values.
> * `#10025 <https://github.com/scipy/scipy/pull/10025>`__: BUG: optimize: tweaked linprog status 4 error message
> * `#10026 <https://github.com/scipy/scipy/pull/10026>`__: ENH: optimize: use SuiteSparse in linprog interior-point when...
> * `#10027 <https://github.com/scipy/scipy/pull/10027>`__: MAINT: cluster: clean up the use of malloc() in the function...
> * `#10028 <https://github.com/scipy/scipy/pull/10028>`__: Fix rotate invalid plane check
> * `#10040 <https://github.com/scipy/scipy/pull/10040>`__: MAINT: fix pratt method of wilcox test in scipy.stats
> * `#10041 <https://github.com/scipy/scipy/pull/10041>`__: MAINT: special: Fix a warning generated when building the AMOS...
> * `#10044 <https://github.com/scipy/scipy/pull/10044>`__: DOC: fix up spatial.transform.Rotation docstrings
> * `#10047 <https://github.com/scipy/scipy/pull/10047>`__: MAINT: interpolate: Fix a few build warnings.
> * `#10051 <https://github.com/scipy/scipy/pull/10051>`__: Add project_urls to setup
> * `#10052 <https://github.com/scipy/scipy/pull/10052>`__: don't set flag to "converged" if max iter exceeded
> * `#10054 <https://github.com/scipy/scipy/pull/10054>`__: MAINT: signal: Fix a few build warnings and modernize some C...
> * `#10056 <https://github.com/scipy/scipy/pull/10056>`__: BUG: Ensure factorial is not too large in kendaltau
> * `#10058 <https://github.com/scipy/scipy/pull/10058>`__: Small speedup in samping from ortho and special_ortho groups
> * `#10059 <https://github.com/scipy/scipy/pull/10059>`__: BUG: optimize: fix #10038 by increasing tol
> * `#10061 <https://github.com/scipy/scipy/pull/10061>`__: BLD: DOC: make building docs easier by parsing python version.
> * `#10064 <https://github.com/scipy/scipy/pull/10064>`__: ENH: Significant speedup for ortho and special ortho group
> * `#10065 <https://github.com/scipy/scipy/pull/10065>`__: DOC: Reword parameter descriptions in \`optimize.root_scalar\`
> * `#10066 <https://github.com/scipy/scipy/pull/10066>`__: BUG: signal: Fix error raised by savgol_coeffs when deriv > polyorder.
> * `#10067 <https://github.com/scipy/scipy/pull/10067>`__: MAINT: Fix the cutoff value inconsistency for pinv2 and pinvh
> * `#10072 <https://github.com/scipy/scipy/pull/10072>`__: BUG: stats: Fix boxcox_llf to avoid loss of precision.
> * `#10075 <https://github.com/scipy/scipy/pull/10075>`__: ENH: Add wrappers for ?syconv routines
> * `#10076 <https://github.com/scipy/scipy/pull/10076>`__: BUG: optimize: fix curve_fit for mixed float32/float64 input
> * `#10077 <https://github.com/scipy/scipy/pull/10077>`__: DOC: Replace undefined \`k\` in \`interpolate.splev\` docstring
> * `#10079 <https://github.com/scipy/scipy/pull/10079>`__: DOC: Fixed typo, rearranged some doc of stats.morestats.wilcoxon.
> * `#10080 <https://github.com/scipy/scipy/pull/10080>`__: TST: install scikit-sparse for full TravisCI tests
> * `#10083 <https://github.com/scipy/scipy/pull/10083>`__: Clean \`\`_clean_inputs\`\` in optimize.linprog
> * `#10088 <https://github.com/scipy/scipy/pull/10088>`__: ENH: optimize: linprog test CHOLMOD/UMFPACK solvers when available
> * `#10090 <https://github.com/scipy/scipy/pull/10090>`__: MAINT: Fix CubicSplinerInterpolator for pandas
> * `#10091 <https://github.com/scipy/scipy/pull/10091>`__: MAINT: improve logcdf and logsf of hypergeometric distribution
> * `#10095 <https://github.com/scipy/scipy/pull/10095>`__: MAINT: Clean \`\`_clean_inputs\`\` in linprog
>
> Checksums
> =========
>
> MD5
> ~~~
>
> 5a71a217fa4ff372097f501daf816f3b  scipy-1.3.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_int
> el.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> c154ca8eee9ebafe04575b316e41ed85  scipy-1.3.0rc1-cp35-cp35m-manylinux1_i686.whl
> 36a91fa4ae6eeceeb79bf97b9bd013eb  scipy-1.3.0rc1-cp35-cp35m-manylinux1_x86_64.whl
> f1f4259b373332d6edc6bef123b0dc7c  scipy-1.3.0rc1-cp35-cp35m-win32.whl
> c81d78bed8e2176cf0168785b7e1b692  scipy-1.3.0rc1-cp35-cp35m-win_amd64.whl
> c43dd24f349c9d37a6c996e7c0674141  scipy-1.3.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_int
> el.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> 8188210e0fd710f4544f314306b76313  scipy-1.3.0rc1-cp36-cp36m-manylinux1_i686.whl
> 0cf317ee185a8f5736b479d1c8b5f415  scipy-1.3.0rc1-cp36-cp36m-manylinux1_x86_64.whl
> e46e5b38288d79321d8d6ffa15a8f54e  scipy-1.3.0rc1-cp36-cp36m-win32.whl
> 85a79e9be408de72056c6efc1eef7d46  scipy-1.3.0rc1-cp36-cp36m-win_amd64.whl
> 2436169658f74e03b4037142e51a8f86  scipy-1.3.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_int
> el.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> 1b9e2caa5994ee227b4ad8e46b45ad7e  scipy-1.3.0rc1-cp37-cp37m-manylinux1_i686.whl
> 05a51b40471abdf4e9020183ad449bf2  scipy-1.3.0rc1-cp37-cp37m-manylinux1_x86_64.whl
> debecbc0e54fe4e737971b0a6d9f24f5  scipy-1.3.0rc1-cp37-cp37m-win32.whl
> 79c725144fa59566d8ebd3bf556533aa  scipy-1.3.0rc1-cp37-cp37m-win_amd64.whl
> 0b9fa3583bcf2c8190b277cddb287132  scipy-1.3.0rc1.tar.gz
> d22a40e138ecd6bb26990e22d4a1ac1b  scipy-1.3.0rc1.tar.xz
> 9cc12f26980587900befabafaac2078b  scipy-1.3.0rc1.zip
>
>
> SHA256                                                                                       ~~~~~~                                                                                                                                                                                    3491e5453acec48ff8bc1e96980a9ca225bf653eb8e2fad2efe44ca54fd61230  scipy-1.3.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl                                                                                          b04fed432d0d2b7aa52fb83c87390f22e34407baa404385e6c804c6d2f9fe3dc  scipy-1.3.0rc1-cp35-cp35m-manylinux1_i686.whl                                                                           71c236d8b036caa84a018b056c6ced101bcb3efb160fab18957daf5a41c7319c  scipy-1.3.0rc1-cp35-cp35m-manylinux1_x86_64.whl                                                                         6fa6a341ab6920f9233ce5da16572e3e403540f90c17269e27a7a7451e05d40e  scipy-1.3.0rc1-cp35-cp35m-win32.whl                                                                                     7ec09797276d26c74234c056415234a7168e536011767af984b1700410806699  scipy-1.3.0rc1-cp35-cp35m-win_amd64.whl                                                                                 55fcdd1ea9bb3d5461477391d924e24c56c8fa3cb3aba98c2ee2c47e3ccd6ce2  scipy-1.3.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl                                                                                          b149d330d0a8219b68d2839cc49a37df163b0ec0b56194f8f0aa6878c1e7c2a4  scipy-1.3.0rc1-cp36-cp36m-manylinux1_i686.whl                                                                           9fed021210077c2e183f621d84bef428762b0b226f8f6da2b03a7d93628e3089  scipy-1.3.0rc1-cp36-cp36m-manylinux1_x86_64.whl                                                                         5c9c9a47e914fbf8edc9a1da1e10a9f5204b3dfc89c93b721b658290884bfe45  scipy-1.3.0rc1-cp36-cp36m-win32.whl                                                                                     09b2c3e099b6274b142e7e05132e79efbbe4daa9dd593a226a3bc9820adf966a  scipy-1.3.0rc1-cp36-cp36m-win_amd64.whl                                                                                 4e93edc6d4c1296ac39ae4be2e8d9336a37a3e5c6e104801a288db0f18d5dbd1  scipy-1.3.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl                                                                                          1edafef721c859848b8575e7313fba062903f3c256661304f488b96fff4f759d  scipy-1.3.0rc1-cp37-cp37m-manylinux1_i686.whl                                                                           2fe186fff442d3f54f8e6950e809c571ea29db8333ed30608c4074a843d5cdf1  scipy-1.3.0rc1-cp37-cp37m-manylinux1_x86_64.whl                                                                         7c59ec7d5148538978da6c66059c9e3240ae9cf17b803b15354fffc8d3320961  scipy-1.3.0rc1-cp37-cp37m-win32.whl
> 2ab6d6f940b6b09cbee6d7cb2de5914a50f459cbc612b4328b033f67452fd1d6  scipy-1.3.0rc1-cp37-cp37m-win_amd64.whl
> d09e6fae7434aa9e1422d95bbee28f0b66ba97ab770fec24f31c75a873823cd6  scipy-1.3.0rc1.tar.gz
> ba49645a693f6e70e690cf6e2175865b7bf0182cf59bdce872968f47546f4269  scipy-1.3.0rc1.tar.xz
> f1cdb4651f3d150f5c145dc930a627f09aa2afc5275c6c5da97a9a5df274c531  scipy-1.3.0rc1.zip
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJcw54gAAoJELD/41ZX0J71zbEQAKaapoUb0gbLvljeLL+FZmaZ
> Ha8OecYf7Fsdgj9kiGk2kKgrvz5nkoRyJDpxi4BOzPua+HBUhECoH3DBL5kA6sbv
> VsMAhTb5HFPiKmC78LHEUNSY1fPJrdK7s99pIgedjQFR5diODHqqtB54awbRsTOs
> Vdq45I7JoCd+DUMqQWIA3TZyjrZzw2V1KBFS8mHFdcop71Q1RqRNf3rVw7Rpydob
> uegbae42cJ2Hej4+viU8hsCM+JIgkCuZaQEN2wp4W9pmHsDCzJcoyQjulTjZQAeG
> W3L/F5O1p9A9nHIPk+wvS3D2ageKOhYmVSgB6dznXnFRsjwIKH4O4k0TCzYAamsd
> HvcKnncGAzc+95o2k+v46575O3pBPRYCmOKz6LlFfFGNr/PWkxPYuG49nGIwQZU+
> /w0RYvu2NIPyd05gQQfwyEAATmwbYQfCelbQtHtPehDrtwMINZF4ZCqVg8D7d2ns
> c2mUUC72Iq62R17CdQOjp/zkvU4Xo6KGm0TPQY7xuJwXOaiM5cJ49iY+/Z6eBfBM
> JS0MoIZ8PRzhzQ6gKTPt4exil75ybNpCeL/Ny/LY5dgkfaOdTuplmxwxgngxaECG
> W4SaGw4P0SiATwyz7hMprv/Xkq59iK6IsF6Ki7uxPuMps+nbYhvVIUXqh8Y5iVxx
> piFfF2ct8rgxkVm3qBmN
> =KK2K
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>


-- 
Mark Mikofski, PhD (2005)
*Fiat Lux*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190427/cbc6a4ec/attachment-0001.html>

From ralf.gommers at gmail.com  Sat Apr 27 17:11:21 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 27 Apr 2019 23:11:21 +0200
Subject: [SciPy-Dev] SciPy now fiscally sponsored by NumFOCUS
In-Reply-To: <CABL7CQjPUdaVKGKTDBokkwyA7EzMFRyjz3izemA96=8+Q4mtKg@mail.gmail.com>
References: <CABL7CQiokKra-iKYUT4ASTshf9PYThQ5VkbB5mSGmpTt+uGz8A@mail.gmail.com>
 <CAFMmPGNqktQp+XRqMsFpPALRDFyR-4nT0hH+pb79d8LCGoOCwA@mail.gmail.com>
 <CABL7CQjPUdaVKGKTDBokkwyA7EzMFRyjz3izemA96=8+Q4mtKg@mail.gmail.com>
Message-ID: <CABL7CQiwH8t7jBy85+23NUPkzRS5L41ykfbsjgTYShCnePWQ9w@mail.gmail.com>

Hi all,

Changes are in:
https://github.com/scipy/scipy.org/pull/290
https://github.com/scipy/scipy-sphinx-theme/pull/11

Please review or comment if you have any concerns or additions. I plan to
merge those PRs in two days.

Cheers,
Ralf



On Thu, Apr 18, 2019 at 11:47 PM Ralf Gommers <ralf.gommers at gmail.com>
wrote:

>
>
> On Thu, Apr 18, 2019 at 9:38 PM Travis Oliphant <teoliphant at gmail.com>
> wrote:
>
>> This is exciting news.  Thanks for all the work on this.
>>
>> As you are putting up historical institutional sponsors for the work, I
>> would appreciate mention Mayo Clinic (1998-2001) and BYU (2001-2007) where
>> I was a paid graduate student and professor and worked on what became SciPy
>> and then SciPy.
>>
>
> Thanks for the input Travis. That's a fair request, and I will include
> those two institutions.
>
> A further thought on this: going forward I think we should only list
> Institutional Partners, for which we have a clear definition:
> http://scipy.github.io/devdocs/dev/governance/governance.html#institutional-partners-and-funding.
> The key point of that is: work on SciPy has to be part of the official
> duties of the employee. However going back in time I think we should be
> inclusive, also when other past contributors have done large amounts of
> work "in the boss's time" and make a similar requests.
>
> Cheers,
> Ralf
>
>
>
>
>> Thanks,
>>
>> -Travis
>>
>>
>>
>>
>> On Thu, Apr 18, 2019 at 3:35 AM Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I'm happy to tell you that, finally, SciPy is now fiscally sponsored by
>>> NumFOCUS. We signed a "Fiscal Sponsorship Agreement" between the SciPy
>>> Steering Council and NumFOCUS, see
>>> https://numfocus.org/information-fiscal-sponsorship (comprehensive
>>> model).
>>>
>>> What this means is basically that we can have access to services like
>>> administrative, legal, marketing support, and can through NumFOCUS accept
>>> donations, grants, etc. and use those funds to further improve SciPy. Until
>>> now we were only an "affiliated project", which didn't give us our own
>>> account or the right to use funds that were donated to NumFOCUS dedicated
>>> to SciPy (note that we did get some financial support before, e.g. the
>>> small grants for optimize.linprog and pydata/sparse).
>>>
>>> One thing we do need to do is clarify the situation around sponsors on
>>> scipy.org. Right now it says "sponsored by Enthought" fairly
>>> prominently on every page, and all other sponsors are hidden away at
>>> https://scipy.org/scipylib/donations.html#infrastructure-non-financial-support.
>>> NumFOCUS asked that we fix this. The situation is:
>>> 1. NumFOCUS is our fiscal sponsor
>>> 2. We have a number of former and current sponsors (both money and
>>> things like free infrastructure or services). Those all need to be
>>> acknowledged in a fair and visible way.
>>>
>>> I will work on an update to scipy.org (aiming for next week) to fix
>>> this. A more comprehensive overhaul of scipy.org would also be nice at
>>> some point, but that's for later.
>>>
>>> Cheers,
>>> Ralf
>>>
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190427/a23c7bb2/attachment.html>

From ralf.gommers at gmail.com  Sat Apr 27 17:49:03 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 27 Apr 2019 23:49:03 +0200
Subject: [SciPy-Dev] scipy.org logo original?
Message-ID: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>

Hi,

Does anyone have the original files from which the current logo on scipy.org
(it has the scipy symbol, white letter scipy.org and "sponsored by
Enthough") was created? The quality is not great, and editing a tiny gif
doesn't make it better ....

Thanks,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190427/d0b7f0fd/attachment.html>

From andrewjhynes at gmail.com  Sun Apr 28 17:09:44 2019
From: andrewjhynes at gmail.com (Andrew Hynes)
Date: Sun, 28 Apr 2019 17:09:44 -0400
Subject: [SciPy-Dev] [ANN] Release of scikit-spatial package
In-Reply-To: <CAHPuU_b2MSPrqUyff+eEB8C6yjPWhWtoLyZFvr+JXvpVAccD0Q@mail.gmail.com>
References: <CAD-yzHYJVDQqtqH1=AGweM8adqxfQ0xn-1y8wCxtFkkLdiwiKw@mail.gmail.com>
 <555a5a21-6a0a-4bf5-ba6f-83361c7f840a@www.fastmail.com>
 <CAD-yzHZJSDvJsXQorZtAtqRpgANR35UN9fbE_2gmKKnUm1qkjQ@mail.gmail.com>
 <CAHPuU_aCzr+t1vgP_JaBYLP1gQQLMkBReS-1pvrHoKwdZykoYA@mail.gmail.com>
 <CAD-yzHZc2WL4kmxJO6_MAUODLDdKio93+jekTYfyyDuf2fC3cQ@mail.gmail.com>
 <CAHPuU_YA=cWOs2agguvXSmRqn0UhHVbwPSyBLZjiBa9Ztk0+5A@mail.gmail.com>
 <CAHPuU_b2MSPrqUyff+eEB8C6yjPWhWtoLyZFvr+JXvpVAccD0Q@mail.gmail.com>
Message-ID: <CAD-yzHYfRsOsKQ2_+34=KrsaDyYKw1ku0+fMqo2xsa_Cm4p9Wg@mail.gmail.com>

Hello Tyler,

Thanks for your detailed comments. I'll keep working on the scikit for now,
but if I find something that I think meets the criteria you mentioned, I
can start a new thread on this mailing list to ask about adding it to scipy.

That ability with are_collinear() sounds very useful, but unfortunately I
don't know how it could be done.

Regards,

Andrew

On Sat, Apr 27, 2019 at 4:30 PM Tyler Reddy <tyler.je.reddy at gmail.com>
wrote:

> One more follow-up thought -- are_collinear() appears to provide a simple
> bool return value for a set of coordinates in your Points class. But what
> if you had an array of 2 million points and you wanted to know the
> *indices* of *any* points that were collinear with any other?
>
> That might be interesting if it could be done more efficiently than brute
> force? Then you could exclude said collinear points and feed them into a
> comp geo algorithm. Someone must have thought of this already.
>
>
>
> On Fri, 26 Apr 2019 at 16:04, Tyler Reddy <tyler.je.reddy at gmail.com>
> wrote:
>
>> I've thought a little more about this. I didn't come up with a great
>> first choice for migrating functionality into scipy.spatial just yet, but
>> this was my thought process for one of your methods, are_collinear():
>>
>> - the boolean return value may be useful for assessments of general
>> position in computational geometry, for rejection of array input to other
>> algorithms / functions by fiat
>> - the main problem is that the algorithm is effectively a NumPy one-liner
>> on array-input: numpy.linalg.matrix_rank(input) <= 1
>> - before I realized that, I also considered how you might transplant it
>> if relative simplicity were not an issue for a new public SciPy function
>> - I would suggest avoiding the object-oriented / ndarray subclassing
>> approach used in the scikit & matching our scipy.spatial distance-style
>> approach which generally takes an array-like into a simple function &
>> operates on it / returns something directly; avoiding ndarray subclassing
>> will probably reduce the controversy of a PR
>>
>> So, not sure how helpful that is. I think the initial assessment on
>> collinear is: 1) very useful; but 2) perhaps a little too simple to justify
>> an exposed / new SciPy function?
>>
>> Perhaps that evaluation strategy (usefulness + non-trivial
>> implementation; avoiding ndarray subclasses) may help you select the right
>> candidate for migrating over to SciPy? Others may have different thoughts
>> though.
>>
>> On Wed, 10 Apr 2019 at 19:17, Andrew Hynes <andrewjhynes at gmail.com>
>> wrote:
>>
>>> Hello Tyler,
>>>
>>> Some of the algorithms might be suitable for inclusion. Probably easier
>>>> if there's a nice paper / source for algorithm citation and it is clear
>>>> that we don't already have the functionality somewhere in SciPy.
>>>>
>>>
>>> My main reference for the functions has been
>>> http://mathworld.wolfram.com/. Some of the docstrings have a link to
>>> the relevant webpage.
>>>
>>> I'd like to try making a pull request for scipy.spatial. Is there an
>>> area of scikit-spatial that you think would be best to start?
>>>
>>> Also, would you prefer that the code is not object-oriented? For
>>> example, the collinearity function is a method of the Points class, but I
>>> can adapt it to be a regular function that takes a 2D ndarray as input. Or
>>> if you're fine with the object oriented style, I can work on a pull request
>>> to include the Point and Vector classes, which could be imported from a
>>> scipy.spatial.objects module.
>>>
>>> Thanks,
>>>
>>> Andrew
>>>
>>>
>>> On Tue, Apr 9, 2019 at 2:05 PM Tyler Reddy <tyler.je.reddy at gmail.com>
>>> wrote:
>>>
>>>> Some of the algorithms might be suitable for inclusion. Probably easier
>>>> if there's a nice paper / source for algorithm citation and it is clear
>>>> that we don't already have the functionality somewhere in SciPy.
>>>>
>>>> To give one example, just browsing through, I see a collinearity
>>>> algorithm. Since collinearity is often used in the assessment of general
>>>> position prior to embarking on an algorithm in computational geometry,
>>>> it may be sensible to check if the low-level library we vendor for many
>>>> comp geo routines (Qhull) has a routine for this. Even if it does, it might
>>>> not be easy to expose directly, but it is a consideration I think.
>>>>
>>>> Some of the operations, if ultimately suitable for inclusion, may fit
>>>> in the scipy.spatial.transform namespace, but probably case-by-case basis
>>>> is best in terms of assessing broad interest in the algorithm
>>>> and its suitability for inclusion.
>>>>
>>>> On Mon, 8 Apr 2019 at 16:08, Andrew Hynes <andrewjhynes at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi St?fan,
>>>>>
>>>>>> This looks neat!  It reminds me a bit of the following book which I
>>>>>> enjoyed:
>>>>>>
>>>>>> http://www.geometricalgebra.net/
>>>>>>
>>>>>
>>>>> Thanks for the link - it looks like a good source for expanding the
>>>>> package.
>>>>>
>>>>> Can you tell us a bit more about how you see these functions typically
>>>>>> being applied in practice?
>>>>>>
>>>>> Sure, I can give an example from my masters project. It involved
>>>>> clinical gait analysis with a depth camera, so I used some of these
>>>>> functions to calculate gait parameters from positions in space.
>>>>>
>>>>> A basic walking stride consists of three positions: The initial swing
>>>>> foot, the stance foot, and the final swing foot. The stride length is the
>>>>> distance from the initial to final swing foot. The stride width is the
>>>>> length of the projection from the stance foot to the swing path (the line
>>>>> from the initial swing foot to the final).
>>>>>
>>>>> Here's a snippet of code using scikit-spatial to calculate gait
>>>>> parameters from three points: point_a_i (initial swing foot), point_b
>>>>> (stance foot), and point_a_f (final swing foot).
>>>>>
>>>>> from skspatial.objects import Vector, Line
>>>>>
>>>>> vector_a = Vector.from_points(point_a_i, point_a_f)
>>>>> line_a = Line(point=point_a_i, direction=vector_a)
>>>>>
>>>>> point_b_proj = line_a.project_point(point_b)
>>>>>
>>>>> stride_length = vector_a.norm()
>>>>> absolute_step_length = Vector.from_points(point_b, point_a_f).norm()
>>>>> step_length = Vector.from_points(point_b_proj, point_a_f).norm()
>>>>> stride_width = line_a.distance_point(point_b)
>>>>>
>>>>>
>>>>> Hopefully that gives an idea as to how the package can be used.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Andrew
>>>>>
>>>>> P. S. Great job on scikit-image!
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190428/fdba15fd/attachment.html>

From stefanv at berkeley.edu  Mon Apr 29 13:26:00 2019
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Mon, 29 Apr 2019 10:26:00 -0700
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
Message-ID: <20190429172600.tykgkl325xdygw74@carbo>

On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
> Does anyone have the original files from which the current logo on scipy.org
> (it has the scipy symbol, white letter scipy.org and "sponsored by
> Enthough") was created? The quality is not great, and editing a tiny gif
> doesn't make it better ....

I don't have the vector art, but I have a higher resolution render:
https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png

St?fan

From stefanv at berkeley.edu  Mon Apr 29 13:41:03 2019
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Mon, 29 Apr 2019 10:41:03 -0700
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <20190429172600.tykgkl325xdygw74@carbo>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
Message-ID: <20190429174103.7xbkfyndweuv24ts@carbo>

Found it and uploaded to GitHub:

https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg

On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
> On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
> > Does anyone have the original files from which the current logo on scipy.org
> > (it has the scipy symbol, white letter scipy.org and "sponsored by
> > Enthough") was created? The quality is not great, and editing a tiny gif
> > doesn't make it better ....
> 
> I don't have the vector art, but I have a higher resolution render:
> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
> 
> St?fan

From ilhanpolat at gmail.com  Mon Apr 29 14:09:46 2019
From: ilhanpolat at gmail.com (Ilhan Polat)
Date: Mon, 29 Apr 2019 20:09:46 +0200
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <20190429174103.7xbkfyndweuv24ts@carbo>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
Message-ID: <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>

Perfect! Thanks.

On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <stefanv at berkeley.edu>
wrote:

> Found it and uploaded to GitHub:
>
> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>
> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
> > > Does anyone have the original files from which the current logo on
> scipy.org
> > > (it has the scipy symbol, white letter scipy.org and "sponsored by
> > > Enthough") was created? The quality is not great, and editing a tiny
> gif
> > > doesn't make it better ....
> >
> > I don't have the vector art, but I have a higher resolution render:
> >
> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
> >
> > St?fan
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190429/8f1799a7/attachment.html>

From ilhanpolat at gmail.com  Mon Apr 29 16:44:25 2019
From: ilhanpolat at gmail.com (Ilhan Polat)
Date: Mon, 29 Apr 2019 22:44:25 +0200
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
Message-ID: <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>

By the way does anyone know what the font logo is? Just by eyeballing it
looks like Franklin Gothic but I am not sure. However, if there is a more
able typography connoisseur among us, here is the logo ready to be compiled
by Xe/LuaLatex.

\documentclass[tikz]{standalone}
\usepackage{fontspec}
\setsansfont{Franklin Gothic Medium}
\usetikzlibrary{svg.path}
\definecolor{scipylogo}{HTML}{8CAAE6}

\begin{document}
\begin{tikzpicture}[x=1pt, y=-1pt]

\fill[scipylogo] (-50,-75) rectangle (1825, 575)
svg[yscale=-1] {
M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};

\node[anchor=east,
      text=white,
      font=\sffamily,
      scale=30,
      outer sep=0pt,
      inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
\end{tikzpicture}
\end{document}

This code gives on my system

[image: image.png]

"i" and "P" needs a slight nudge to each other but that means the font is
correct. Hence my question. Also you can play around and enjoy some TeX
kerning/positioning/scaling bonanza yourself. I'll let Ralf to be the judge
:)

Best,
ilhan

On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <ilhanpolat at gmail.com> wrote:

> Perfect! Thanks.
>
> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <stefanv at berkeley.edu>
> wrote:
>
>> Found it and uploaded to GitHub:
>>
>>
>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>
>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>> > > Does anyone have the original files from which the current logo on
>> scipy.org
>> > > (it has the scipy symbol, white letter scipy.org and "sponsored by
>> > > Enthough") was created? The quality is not great, and editing a tiny
>> gif
>> > > doesn't make it better ....
>> >
>> > I don't have the vector art, but I have a higher resolution render:
>> >
>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>> >
>> > St?fan
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190429/52fde0e7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32300 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190429/52fde0e7/attachment-0001.png>

From ralf.gommers at gmail.com  Tue Apr 30 08:58:24 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 30 Apr 2019 14:58:24 +0200
Subject: [SciPy-Dev] ANN: NumPy and SciPy accepted in Summer of Docs,
 technical writer exploration phase open
In-Reply-To: <aac7c948-d19f-48d5-a3d8-9ea1151abe24@googlegroups.com>
References: <aac7c948-d19f-48d5-a3d8-9ea1151abe24@googlegroups.com>
Message-ID: <CABL7CQjq9wX3nBTOOHiqHKbR3tPbLYWa=rXv_rnOkQ8arrUVCg@mail.gmail.com>

Hi all,

Good news: NumPy and SciPy both were accepted as participating
organizations for Google Summer of Docs!

This could potentially be very interesting and impactful. If you have any
tech writer friends that could be interested or that may have friends,
colleagues or a community that may be: please point them to the
announcement!

Links for program details below. Our ideas pages are at:
https://github.com/numfocus/gsod/blob/master/2019/NumPy_ideas_list.md
https://github.com/numfocus/gsod/blob/master/2019/SciPy_ideas_list.md

Cheers,
Ralf



---------- Forwarded message ---------
From: 'Andrew Chen' via Season of Docs - Announce <
season-of-docs-announce at googlegroups.com>
Date: Tue, Apr 30, 2019 at 2:30 PM
Subject: [Season of Docs - Announcements] Participating organizations
announced and technical writer exploration phase open
To: Season of Docs - Announce <season-of-docs-announce at googlegroups.com>


Thank you for your enthusiasm and support for Season of Docs. We received
nearly 200 organization applications! There were many high quality
applications, so the selection of organizations was not easy.

The list of 50 participating open source organizations for Season of Docs
2019 is now available at
https://developers.google.com/season-of-docs/docs/participants/.

Are you a technical writer interested in taking part in Season of Docs?
Please explore the list of participating organizations and their project
ideas. If any of the projects interest you, you can contact the open source
organization now to start fleshing out your project proposal. You can
explore more than one project, and when the technical writer application
phase opens you can submit more than one project proposal, but only one
proposal will be accepted.

The exploration phase runs from April 30 to May 28. Take a look at the
technical
writer guidelines
<https://developers.google.com/season-of-docs/docs/tech-writer-guide#tech-writer-explore>
for this phase. You can submit your project proposals to Season of Docs
when the technical writer application phase opens on May 29. See the full
timeline <https://developers.google.com/season-of-docs/docs/timeline> on
the Season of Docs website.

We hope you enjoy exploring the available open source projects and choosing
the project you?d like to work with!

If you have any questions about the program, please email the Season of
Docs team at season-of-docs-support at googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups
"Season of Docs - Announce" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to season-of-docs-announce+unsubscribe at googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/season-of-docs-announce/aac7c948-d19f-48d5-a3d8-9ea1151abe24%40googlegroups.com
<https://groups.google.com/d/msgid/season-of-docs-announce/aac7c948-d19f-48d5-a3d8-9ea1151abe24%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190430/2b20b3a6/attachment.html>

From ralf.gommers at gmail.com  Tue Apr 30 09:10:00 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 30 Apr 2019 15:10:00 +0200
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
Message-ID: <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>

Thanks Stefan & Ilhan!

Scikit-image has the right idea I think with a separate branding repo.
Shall we create one for SciPy as well?

Ilhan, that looks really good! Would you be able to make a web-sized image
and add it to scipy-sphinx-theme? The current image is a 2.4kb gif, I think
it can be larger but as small as possible while still looking good would be
nice. Because it gets downloaded millions of times a month, and also
directly adds to the size of the numpy and scipy sdists.

Cheers,
Ralf


On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <ilhanpolat at gmail.com> wrote:

> By the way does anyone know what the font logo is? Just by eyeballing it
> looks like Franklin Gothic but I am not sure. However, if there is a more
> able typography connoisseur among us, here is the logo ready to be compiled
> by Xe/LuaLatex.
>
> \documentclass[tikz]{standalone}
> \usepackage{fontspec}
> \setsansfont{Franklin Gothic Medium}
> \usetikzlibrary{svg.path}
> \definecolor{scipylogo}{HTML}{8CAAE6}
>
> \begin{document}
> \begin{tikzpicture}[x=1pt, y=-1pt]
>
> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
> svg[yscale=-1] {
> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>
> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>
> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>
> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>
> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>
> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>
> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>
> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>
> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>
> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>
> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>
> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>
> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>
> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>
> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>
> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>
> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>
> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>
> \node[anchor=east,
>       text=white,
>       font=\sffamily,
>       scale=30,
>       outer sep=0pt,
>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
> \end{tikzpicture}
> \end{document}
>
> This code gives on my system
>
> [image: image.png]
>
> "i" and "P" needs a slight nudge to each other but that means the font is
> correct. Hence my question. Also you can play around and enjoy some TeX
> kerning/positioning/scaling bonanza yourself. I'll let Ralf to be the judge
> :)
>
> Best,
> ilhan
>
> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>
>> Perfect! Thanks.
>>
>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <stefanv at berkeley.edu>
>> wrote:
>>
>>> Found it and uploaded to GitHub:
>>>
>>>
>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>
>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>> > > Does anyone have the original files from which the current logo on
>>> scipy.org
>>> > > (it has the scipy symbol, white letter scipy.org and "sponsored by
>>> > > Enthough") was created? The quality is not great, and editing a tiny
>>> gif
>>> > > doesn't make it better ....
>>> >
>>> > I don't have the vector art, but I have a higher resolution render:
>>> >
>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>> >
>>> > St?fan
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190430/80e9ff6f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32300 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190430/80e9ff6f/attachment-0001.png>