From deathcoderx at gmail.com  Sun Mar  3 04:19:01 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Sun, 3 Mar 2019 14:49:01 +0530
Subject: [SciPy-Dev] GSoC 2019
Message-ID: <CADYNDzi=VUB3GXJ7-KZYL9FU=md0CuXf6x0Tc_JEQ4OebTuf+Q@mail.gmail.com>

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190303/b027daf5/attachment.html>

From saifalialvi at gmail.com  Sun Mar  3 08:15:26 2019
From: saifalialvi at gmail.com (saif ali)
Date: Sun, 3 Mar 2019 18:45:26 +0530
Subject: [SciPy-Dev] GSOC 2019
Message-ID: <CACRsw_AwE0F3QXTgRa5kgo4k8CWB=vaj4bTM=UShFP-R1UudvQ@mail.gmail.com>

I want to contribute to SciPy in GSOC 2019. I have started bug fixing. I
want to implement an idea in Scipy and I want to know how do I connect with
the mentors for that ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190303/04d5b0ab/attachment.html>

From deathcoderx at gmail.com  Sun Mar  3 08:20:46 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Sun, 3 Mar 2019 18:50:46 +0530
Subject: [SciPy-Dev] GSOC 2019
In-Reply-To: <CACRsw_AwE0F3QXTgRa5kgo4k8CWB=vaj4bTM=UShFP-R1UudvQ@mail.gmail.com>
References: <CACRsw_AwE0F3QXTgRa5kgo4k8CWB=vaj4bTM=UShFP-R1UudvQ@mail.gmail.com>
Message-ID: <CADYNDzg43gNSnnoRfSw1nJYcwR+uZQJjuwGUUvHoWE9ER-9y5Q@mail.gmail.com>

Go to the SciPy page in organization list on GSoC's website. You will find
all the relevant info there.

On Sun, Mar 3, 2019 at 6:46 PM saif ali <saifalialvi at gmail.com> wrote:

> I want to contribute to SciPy in GSOC 2019. I have started bug fixing. I
> want to implement an idea in Scipy and I want to know how do I connect with
> the mentors for that ?
> _______________________________________________
> 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/20190303/aa1c4401/attachment.html>

From grlee77 at gmail.com  Sun Mar  3 11:54:54 2019
From: grlee77 at gmail.com (Gregory Lee)
Date: Sun, 3 Mar 2019 11:54:54 -0500
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CADYNDzi=VUB3GXJ7-KZYL9FU=md0CuXf6x0Tc_JEQ4OebTuf+Q@mail.gmail.com>
References: <CADYNDzi=VUB3GXJ7-KZYL9FU=md0CuXf6x0Tc_JEQ4OebTuf+Q@mail.gmail.com>
Message-ID: <CAJR3sXcnSHv3Fxp=XOcq2jZLNU03A56Tn_bEp5o6V1V7AFcr-Q@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190303/56acdfda/attachment.html>

From grlee77 at gmail.com  Sun Mar  3 11:56:56 2019
From: grlee77 at gmail.com (Gregory Lee)
Date: Sun, 3 Mar 2019 11:56:56 -0500
Subject: [SciPy-Dev] GSOC 2019
In-Reply-To: <CADYNDzg43gNSnnoRfSw1nJYcwR+uZQJjuwGUUvHoWE9ER-9y5Q@mail.gmail.com>
References: <CACRsw_AwE0F3QXTgRa5kgo4k8CWB=vaj4bTM=UShFP-R1UudvQ@mail.gmail.com>
 <CADYNDzg43gNSnnoRfSw1nJYcwR+uZQJjuwGUUvHoWE9ER-9y5Q@mail.gmail.com>
Message-ID: <CAJR3sXftB5pC3UzUh8p1j6KKz_LO6-yTuCLM-k2J6-8UGDD0gA@mail.gmail.com>

> On Sun, Mar 3, 2019 at 6:46 PM saif ali <saifalialvi at gmail.com> wrote:
>
>> I want to contribute to SciPy in GSOC 2019. I have started bug fixing. I
>> want to implement an idea in Scipy and I want to know how do I connect with
>> the mentors for that ?
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>
>

Hi Saif,

I wrote a the following response to Gopi just now, but am copying it here
as well.  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190303/80bbb7cc/attachment-0001.html>

From deathcoderx at gmail.com  Sun Mar  3 12:09:14 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Sun, 3 Mar 2019 22:39:14 +0530
Subject: [SciPy-Dev] GSOC 2019
In-Reply-To: <CAJR3sXftB5pC3UzUh8p1j6KKz_LO6-yTuCLM-k2J6-8UGDD0gA@mail.gmail.com>
References: <CACRsw_AwE0F3QXTgRa5kgo4k8CWB=vaj4bTM=UShFP-R1UudvQ@mail.gmail.com>
 <CADYNDzg43gNSnnoRfSw1nJYcwR+uZQJjuwGUUvHoWE9ER-9y5Q@mail.gmail.com>
 <CAJR3sXftB5pC3UzUh8p1j6KKz_LO6-yTuCLM-k2J6-8UGDD0gA@mail.gmail.com>
Message-ID: <CADYNDzgNyruNa5-QUsWLoCZVRZAoD+QJj_Po9eqaoeZR_9ZP+g@mail.gmail.com>

Thanks for your guidance. I will go through the idea thoroughly and will
try my best to figure out the best way to proceed.

On Sun, Mar 3, 2019 at 10:27 PM Gregory Lee <grlee77 at gmail.com> wrote:

>
> On Sun, Mar 3, 2019 at 6:46 PM saif ali <saifalialvi at gmail.com> wrote:
>>
>>> I want to contribute to SciPy in GSOC 2019. I have started bug fixing. I
>>> want to implement an idea in Scipy and I want to know how do I connect with
>>> the mentors for that ?
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>>
>>
>
> Hi Saif,
>
> I wrote a the following response to Gopi just now, but am copying it here
> as well.  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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190303/68bae762/attachment.html>

From deathcoderx at gmail.com  Sun Mar  3 12:28:05 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Sun, 3 Mar 2019 22:58:05 +0530
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CAJR3sXcnSHv3Fxp=XOcq2jZLNU03A56Tn_bEp5o6V1V7AFcr-Q@mail.gmail.com>
References: <CADYNDzi=VUB3GXJ7-KZYL9FU=md0CuXf6x0Tc_JEQ4OebTuf+Q@mail.gmail.com>
 <CAJR3sXcnSHv3Fxp=XOcq2jZLNU03A56Tn_bEp5o6V1V7AFcr-Q@mail.gmail.com>
Message-ID: <CADYNDzi5CdieoA3hdfyd0ZTU+fePMctBFzkRPHUxxaNeK0X5Fg@mail.gmail.com>

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?
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?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190303/7093c242/attachment.html>

From grlee77 at gmail.com  Sun Mar  3 23:00:40 2019
From: grlee77 at gmail.com (Gregory Lee)
Date: Sun, 3 Mar 2019 23:00:40 -0500
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CADYNDzi5CdieoA3hdfyd0ZTU+fePMctBFzkRPHUxxaNeK0X5Fg@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>
Message-ID: <CAJR3sXe+Cf45QaV+V=ciozo8+0M4YNkjCy-7SxCGbYct3nZKsQ@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190303/4cd1eeef/attachment-0001.html>

From deathcoderx at gmail.com  Sun Mar  3 23:58:42 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Mon, 4 Mar 2019 10:28:42 +0530
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CAJR3sXe+Cf45QaV+V=ciozo8+0M4YNkjCy-7SxCGbYct3nZKsQ@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>
Message-ID: <CADYNDzg8SEEuG_QTxt57TXsi4s3j-Pe_0X1ovrPSOoGxN+UVYw@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190304/ea497b2f/attachment.html>

From saifalialvi at gmail.com  Mon Mar  4 00:22:54 2019
From: saifalialvi at gmail.com (saif ali)
Date: Mon, 4 Mar 2019 10:52:54 +0530
Subject: [SciPy-Dev] SciPy GSOC 2019
Message-ID: <CACRsw_C2cD2HSBNciR+UqQocHpr=J_k=xJ5bz8zMq0=R0usGsg@mail.gmail.com>

Thanks to all, till now my all doubts have been cleared so I will start
working on the project and proposal, I will surely ask if I encounter
further problems.

Cheers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190304/167d1e68/attachment.html>

From larson.eric.d at gmail.com  Mon Mar  4 18:19:01 2019
From: larson.eric.d at gmail.com (Eric Larson)
Date: Mon, 4 Mar 2019 18:19:01 -0500
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CADYNDzg8SEEuG_QTxt57TXsi4s3j-Pe_0X1ovrPSOoGxN+UVYw@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>
Message-ID: <CAGu2niWoLJ5u-Ux=jb3HFBBfN18L6fsdMcwb4OLH36044PEJ0g@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190304/e7f970c6/attachment.html>

From deathcoderx at gmail.com  Mon Mar  4 22:09:01 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Tue, 5 Mar 2019 08:39:01 +0530
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CAGu2niWoLJ5u-Ux=jb3HFBBfN18L6fsdMcwb4OLH36044PEJ0g@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>
Message-ID: <CADYNDzi1xQokrvVPkPhS2smJYRrm96fu_TB=DTYZb=hXJheUZg@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190305/775b82cf/attachment-0001.html>

From larson.eric.d at gmail.com  Tue Mar  5 17:11:36 2019
From: larson.eric.d at gmail.com (Eric Larson)
Date: Tue, 5 Mar 2019 17:11:36 -0500
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CADYNDzi1xQokrvVPkPhS2smJYRrm96fu_TB=DTYZb=hXJheUZg@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>
Message-ID: <CAGu2niXhVZQPBe23a_ftypwp3oqq2ui14P9TnVc9MEXD5mu1SA@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190305/20c88dc6/attachment.html>

From deathcoderx at gmail.com  Wed Mar  6 04:55:00 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Wed, 6 Mar 2019 15:25:00 +0530
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CAGu2niXhVZQPBe23a_ftypwp3oqq2ui14P9TnVc9MEXD5mu1SA@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>
Message-ID: <CADYNDzh=M2yTnEE0C2HNuCDARXJhHhbHC8UkYnXUgeTA8fdx=Q@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190306/6a274634/attachment-0001.html>

From larson.eric.d at gmail.com  Thu Mar  7 13:09:29 2019
From: larson.eric.d at gmail.com (Eric Larson)
Date: Thu, 7 Mar 2019 13:09:29 -0500
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CADYNDzh=M2yTnEE0C2HNuCDARXJhHhbHC8UkYnXUgeTA8fdx=Q@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>
Message-ID: <CAGu2niUmN=3w=4TAsp0Nc4QN5z5D2p9XA6Ji_6JRAw1MvG1Pmw@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190307/cc11fd88/attachment-0001.html>

From ralf.gommers at gmail.com  Tue Mar 12 01:44:18 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 11 Mar 2019 22:44:18 -0700
Subject: [SciPy-Dev] Fwd: Announcement and thanks to Season of Docs survey
 respondents: Season of Docs has launched
In-Reply-To: <CAEyDeRss0W_O3yE6mr7p_iAD_d3Wxv=zNpin6sTbezKCS5SboQ@mail.gmail.com>
References: <CAEyDeRss0W_O3yE6mr7p_iAD_d3Wxv=zNpin6sTbezKCS5SboQ@mail.gmail.com>
Message-ID: <CABL7CQg_NN6Y4OT0ivXZ7hkQSKaveNNwfnHSKidXSobFQNhEEQ@mail.gmail.com>

It's official, Season of Docs is happening! Does look very interesting, I'd
love to see NumPy and SciPy participate.

Ralf



---------- Forwarded message ---------
From: Sarah Maddox <sarahmaddox at google.com>
Date: Mon, Mar 11, 2019 at 2:56 PM
Subject: Announcement and thanks to Season of Docs survey respondents:
Season of Docs has launched
To:


Thank you for your feedback on the initial proposal of Google?s Season of
Docs program! You?re receiving this email because you indicated that you?d
like us to send you updates about the program.

We?re delighted to announce that we?ve launched the 2019 pilot of Season of
Docs. Details are on our website: g.co/seasonofdocs
<https://developers.google.com/season-of-docs/>.

Season of Docs is a Google program that fosters collaboration between open
source projects and technical writers. It?s similar to Summer of Code, but
with a focus on documentation and technical writers.

Would you like to take part as a mentor in the inaugural year of Season of
Docs? Organization applications open on April 2, 2019. See the full timeline
<https://developers.google.com/season-of-docs/docs/timeline> and join the
announcement group at season-of-docs-announce
<https://groups.google.com/group/season-of-docs-announce> to stay informed.

Please do tweet and blog about Season of Docs if you?d like to share the
news. We want as many people to know about it as possible. We?ve provided
logos that you can download and some example content on the press page
<https://developers.google.com/season-of-docs/docs/press>.

If you have any questions, please email
season-of-docs-support at googlegroups.com.

Many thanks again for your valuable feedback on the initial proposal.

Sarah Maddox, Andrew Chen, and the Season of Docs team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190311/c9ce6bd9/attachment.html>

From larson.eric.d at gmail.com  Tue Mar 12 11:09:23 2019
From: larson.eric.d at gmail.com (Eric Larson)
Date: Tue, 12 Mar 2019 11:09:23 -0400
Subject: [SciPy-Dev] Fwd: Announcement and thanks to Season of Docs
 survey respondents: Season of Docs has launched
In-Reply-To: <CABL7CQg_NN6Y4OT0ivXZ7hkQSKaveNNwfnHSKidXSobFQNhEEQ@mail.gmail.com>
References: <CAEyDeRss0W_O3yE6mr7p_iAD_d3Wxv=zNpin6sTbezKCS5SboQ@mail.gmail.com>
 <CABL7CQg_NN6Y4OT0ivXZ7hkQSKaveNNwfnHSKidXSobFQNhEEQ@mail.gmail.com>
Message-ID: <CAGu2niV5eYn=DzWP0kp29O8oOCP3SNsznqmcEzoFWeVzHRF=hg@mail.gmail.com>

Any idea if PSF is going to be an umbrella org for this, as they are for
GSoC?

Eric


On Tue, Mar 12, 2019 at 1:46 AM Ralf Gommers <ralf.gommers at gmail.com> wrote:

> It's official, Season of Docs is happening! Does look very interesting,
> I'd love to see NumPy and SciPy participate.
>
> Ralf
>
>
>
> ---------- Forwarded message ---------
> From: Sarah Maddox <sarahmaddox at google.com>
> Date: Mon, Mar 11, 2019 at 2:56 PM
> Subject: Announcement and thanks to Season of Docs survey respondents:
> Season of Docs has launched
> To:
>
>
> Thank you for your feedback on the initial proposal of Google?s Season of
> Docs program! You?re receiving this email because you indicated that you?d
> like us to send you updates about the program.
>
> We?re delighted to announce that we?ve launched the 2019 pilot of Season
> of Docs. Details are on our website: g.co/seasonofdocs
> <https://developers.google.com/season-of-docs/>.
>
> Season of Docs is a Google program that fosters collaboration between open
> source projects and technical writers. It?s similar to Summer of Code, but
> with a focus on documentation and technical writers.
>
> Would you like to take part as a mentor in the inaugural year of Season of
> Docs? Organization applications open on April 2, 2019. See the full
> timeline <https://developers.google.com/season-of-docs/docs/timeline> and
> join the announcement group at season-of-docs-announce
> <https://groups.google.com/group/season-of-docs-announce> to stay
> informed.
>
> Please do tweet and blog about Season of Docs if you?d like to share the
> news. We want as many people to know about it as possible. We?ve provided
> logos that you can download and some example content on the press page
> <https://developers.google.com/season-of-docs/docs/press>.
>
> If you have any questions, please email
> season-of-docs-support at googlegroups.com.
>
> Many thanks again for your valuable feedback on the initial proposal.
>
> Sarah Maddox, Andrew Chen, and the Season of Docs team
>
> _______________________________________________
> 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/20190312/dd2ea15a/attachment-0001.html>

From ralf.gommers at gmail.com  Tue Mar 12 14:21:44 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 12 Mar 2019 11:21:44 -0700
Subject: [SciPy-Dev] Fwd: Announcement and thanks to Season of Docs
 survey respondents: Season of Docs has launched
In-Reply-To: <CAGu2niV5eYn=DzWP0kp29O8oOCP3SNsznqmcEzoFWeVzHRF=hg@mail.gmail.com>
References: <CAEyDeRss0W_O3yE6mr7p_iAD_d3Wxv=zNpin6sTbezKCS5SboQ@mail.gmail.com>
 <CABL7CQg_NN6Y4OT0ivXZ7hkQSKaveNNwfnHSKidXSobFQNhEEQ@mail.gmail.com>
 <CAGu2niV5eYn=DzWP0kp29O8oOCP3SNsznqmcEzoFWeVzHRF=hg@mail.gmail.com>
Message-ID: <CABL7CQj0un1iGwQQnPA_pF0vrHr_32tTP4N3o+N=BSC+aZKE2A@mail.gmail.com>

No idea yet. I suspect that either the PSF or NumFOCUS (or both) will
though.

On Tue, Mar 12, 2019 at 8:09 AM Eric Larson <larson.eric.d at gmail.com> wrote:

> Any idea if PSF is going to be an umbrella org for this, as they are for
> GSoC?
>
> Eric
>
>
> On Tue, Mar 12, 2019 at 1:46 AM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>> It's official, Season of Docs is happening! Does look very interesting,
>> I'd love to see NumPy and SciPy participate.
>>
>> Ralf
>>
>>
>>
>> ---------- Forwarded message ---------
>> From: Sarah Maddox <sarahmaddox at google.com>
>> Date: Mon, Mar 11, 2019 at 2:56 PM
>> Subject: Announcement and thanks to Season of Docs survey respondents:
>> Season of Docs has launched
>> To:
>>
>>
>> Thank you for your feedback on the initial proposal of Google?s Season of
>> Docs program! You?re receiving this email because you indicated that you?d
>> like us to send you updates about the program.
>>
>> We?re delighted to announce that we?ve launched the 2019 pilot of Season
>> of Docs. Details are on our website: g.co/seasonofdocs
>> <https://developers.google.com/season-of-docs/>.
>>
>> Season of Docs is a Google program that fosters collaboration between
>> open source projects and technical writers. It?s similar to Summer of Code,
>> but with a focus on documentation and technical writers.
>>
>> Would you like to take part as a mentor in the inaugural year of Season
>> of Docs? Organization applications open on April 2, 2019. See the full
>> timeline <https://developers.google.com/season-of-docs/docs/timeline>
>> and join the announcement group at season-of-docs-announce
>> <https://groups.google.com/group/season-of-docs-announce> to stay
>> informed.
>>
>> Please do tweet and blog about Season of Docs if you?d like to share the
>> news. We want as many people to know about it as possible. We?ve provided
>> logos that you can download and some example content on the press page
>> <https://developers.google.com/season-of-docs/docs/press>.
>>
>> If you have any questions, please email
>> season-of-docs-support at googlegroups.com.
>>
>> Many thanks again for your valuable feedback on the initial proposal.
>>
>> Sarah Maddox, Andrew Chen, and the Season of Docs team
>>
>> _______________________________________________
>> 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/20190312/08781edf/attachment.html>

From andyfaff at gmail.com  Thu Mar 14 21:25:21 2019
From: andyfaff at gmail.com (Andrew Nelson)
Date: Fri, 15 Mar 2019 12:25:21 +1100
Subject: [SciPy-Dev] Non linear constraints for differential evolution
Message-ID: <CAAbtOZejhQWADufCcNnz_LFJXPhJ5D5ig2EjJMgb0qoner3H5Q@mail.gmail.com>

Dear list,
I've been musing on the implementation of non-linear constraints for
`scipy.optimize.differential_evolution`. There are various ways of doing
this (search for "nonlinear constraint function differential evolution" on
Google). There is a version by Lampinen (2002) that seems fairly
straightforward. It is described at:
https://pdfs.semanticscholar.org/088e/60df2694230e8e9e841e19ec218cddba54fe.pdf
The paper has been cited 263 times, which indicates its usefulness. These
kinds of constraints have been implemented in the R version (as indicated
by the documentation).

Does anyone else have any thoughts as to whether they'd find such an
approach useful in scipy?

Andrew.


-- 
_____________________________________
Dr. Andrew Nelson


_____________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190315/79ac7b04/attachment.html>

From haberland at ucla.edu  Mon Mar 18 21:58:42 2019
From: haberland at ucla.edu (Matt Haberland)
Date: Mon, 18 Mar 2019 18:58:42 -0700
Subject: [SciPy-Dev] Non linear constraints for differential evolution
In-Reply-To: <CAAbtOZejhQWADufCcNnz_LFJXPhJ5D5ig2EjJMgb0qoner3H5Q@mail.gmail.com>
References: <CAAbtOZejhQWADufCcNnz_LFJXPhJ5D5ig2EjJMgb0qoner3H5Q@mail.gmail.com>
Message-ID: <CADuxUixfpp=SsnWrFzW8b+gbMcYe5okifDtOETMxGhfqQriFCg@mail.gmail.com>

I haven't used the global optimization routines, but if I were to use them,
the problem would have constraints. So this sounds useful to me.

On Thu, Mar 14, 2019 at 6:26 PM Andrew Nelson <andyfaff at gmail.com> wrote:

> Dear list,
> I've been musing on the implementation of non-linear constraints for
> `scipy.optimize.differential_evolution`. There are various ways of doing
> this (search for "nonlinear constraint function differential evolution" on
> Google). There is a version by Lampinen (2002) that seems fairly
> straightforward. It is described at:
> https://pdfs.semanticscholar.org/088e/60df2694230e8e9e841e19ec218cddba54fe.pdf
> The paper has been cited 263 times, which indicates its usefulness. These
> kinds of constraints have been implemented in the R version (as indicated
> by the documentation).
>
> Does anyone else have any thoughts as to whether they'd find such an
> approach useful in scipy?
>
> Andrew.
>
>
> --
> _____________________________________
> Dr. Andrew Nelson
>
>
> _____________________________________
> _______________________________________________
> 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/20190318/efa520a0/attachment.html>

From christoph.baumgarten at gmail.com  Thu Mar 21 15:10:28 2019
From: christoph.baumgarten at gmail.com (Christoph Baumgarten)
Date: Thu, 21 Mar 2019 20:10:28 +0100
Subject: [SciPy-Dev] Google Season of Docs
Message-ID: <CABXY2qAKDhT=0K+EbUYXCpKWtjKOTVGKb_Q8TDX-mM=nGvZJHw@mail.gmail.com>

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?

Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190321/6e94004b/attachment.html>

From ralf.gommers at gmail.com  Fri Mar 22 15:07:57 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Fri, 22 Mar 2019 12:07:57 -0700
Subject: [SciPy-Dev] Google Season of Docs
In-Reply-To: <CABXY2qAKDhT=0K+EbUYXCpKWtjKOTVGKb_Q8TDX-mM=nGvZJHw@mail.gmail.com>
References: <CABXY2qAKDhT=0K+EbUYXCpKWtjKOTVGKb_Q8TDX-mM=nGvZJHw@mail.gmail.com>
Message-ID: <CABL7CQg43qU1RhtFUp_5C2RZ5nHLAx+6bBSs=6Q0QAKne4G0EA@mail.gmail.com>

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.

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

From cimrman3 at ntc.zcu.cz  Tue Mar 26 09:41:14 2019
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Tue, 26 Mar 2019 14:41:14 +0100
Subject: [SciPy-Dev] ANN: SfePy 2019.1
Message-ID: <8c391e1e-5cc6-dbb6-864a-65e49d5874cf@ntc.zcu.cz>

I am pleased to announce release 2019.1 of SfePy.

Description
-----------

SfePy (simple finite elements in Python) is a software for solving systems of
coupled partial differential equations by the finite element method or by the
isogeometric analysis (limited support). It is distributed under the new BSD
license.

Home page: http://sfepy.org
Mailing list: https://mail.python.org/mm3/mailman3/lists/sfepy.python.org/
Git (source) repository, issue tracker: https://github.com/sfepy/sfepy

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

- automatic fallback for linear solvers
- quadratic eigenvalue problem solver

For full release notes see [1].

Cheers,
Robert Cimrman

[1] http://docs.sfepy.org/doc/release_notes.html#id1

---

Contributors to this release in alphabetical order:

Robert Cimrman
Lubos Kejzlar
Vladimir Lukes

From deathcoderx at gmail.com  Tue Mar 26 15:37:32 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Wed, 27 Mar 2019 01:07:32 +0530
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CAGu2niUmN=3w=4TAsp0Nc4QN5z5D2p9XA6Ji_6JRAw1MvG1Pmw@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>
Message-ID: <CADYNDzh5td0x4sK50VvFw6YQD+Nhc=+hqrYTai4kfYv+F4ttpQ@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190327/12879d2e/attachment-0001.html>

From larson.eric.d at gmail.com  Wed Mar 27 11:12:25 2019
From: larson.eric.d at gmail.com (Eric Larson)
Date: Wed, 27 Mar 2019 11:12:25 -0400
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CADYNDzh5td0x4sK50VvFw6YQD+Nhc=+hqrYTai4kfYv+F4ttpQ@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>
Message-ID: <CAGu2niU3NRhWyCpuMw8WMjfC0sLgq7=PtO8PZJDrsYLSR8V81w@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190327/affea710/attachment-0001.html>

From naalexeev at alaska.edu  Thu Mar 28 19:33:43 2019
From: naalexeev at alaska.edu (Nicholas Alexeev)
Date: Thu, 28 Mar 2019 15:33:43 -0800
Subject: [SciPy-Dev] genfromtxt
Message-ID: <CAN5vGDNB1k5n1Epa6cF1uZWcRCnSracMei6xnQuPvopJc=U3Rg@mail.gmail.com>

I noticed that the genfromtxt() function is slow and it consumes a large
amount of memory. I am trying to improve it. Does anyone have any tips?
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190328/1e0dbc1c/attachment.html>

From ralf.gommers at gmail.com  Thu Mar 28 19:38:34 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Fri, 29 Mar 2019 00:38:34 +0100
Subject: [SciPy-Dev] genfromtxt
In-Reply-To: <CAN5vGDNB1k5n1Epa6cF1uZWcRCnSracMei6xnQuPvopJc=U3Rg@mail.gmail.com>
References: <CAN5vGDNB1k5n1Epa6cF1uZWcRCnSracMei6xnQuPvopJc=U3Rg@mail.gmail.com>
Message-ID: <CABL7CQiFXWSFLyOxrKeYd7H1G4-+C61EVZ8jOARsLzvtqfjh8A@mail.gmail.com>

On Fri, Mar 29, 2019 at 12:34 AM Nicholas Alexeev <naalexeev at alaska.edu>
wrote:

> I noticed that the genfromtxt() function is slow and it consumes a large
> amount of memory. I am trying to improve it. Does anyone have any tips?
> Thanks.
>

If your data can be read by pandas.read_csv, that's a lot faster



> _______________________________________________
> 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/20190329/ad49e8a7/attachment.html>

From andyfaff at gmail.com  Thu Mar 28 19:43:09 2019
From: andyfaff at gmail.com (Andrew Nelson)
Date: Fri, 29 Mar 2019 10:43:09 +1100
Subject: [SciPy-Dev] Add `is_feasible` and `violated_excess` to
 PreparedConstraint
Message-ID: <CAAbtOZfLh7m=j0diS6YnKN5yFyc9Ka8YJuP4y5Hc=bee-XvO2g@mail.gmail.com>

As part of an idea to add constraints to differential_evolution I'd like to
add an `is_feasible` and `violated_excess` method to
`optimize._constaints.PreparedConstraint`. The `is_feasible` method would
return the truth of whether a given solution satisfies the constraint.
The `violated_excess` method would give the total amount that the
constraint is violated by; for example if ub=[5, 6] and the constraint
evaluates to [5.5, 10], then the total excess would be 4.5.

I fully appreciate that `violated_excess` is a silly name, and welcome
suggestions for an alternative.

-- 
_____________________________________
Dr. Andrew Nelson


_____________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190329/813d2223/attachment.html>

From derek at astro.physik.uni-goettingen.de  Thu Mar 28 20:12:36 2019
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Fri, 29 Mar 2019 01:12:36 +0100
Subject: [SciPy-Dev] genfromtxt
In-Reply-To: <CABL7CQiFXWSFLyOxrKeYd7H1G4-+C61EVZ8jOARsLzvtqfjh8A@mail.gmail.com>
References: <CAN5vGDNB1k5n1Epa6cF1uZWcRCnSracMei6xnQuPvopJc=U3Rg@mail.gmail.com>
 <CABL7CQiFXWSFLyOxrKeYd7H1G4-+C61EVZ8jOARsLzvtqfjh8A@mail.gmail.com>
Message-ID: <1CFA762D-D573-442F-A124-DD7A82FB6636@astro.physik.uni-goettingen.de>

On 29 Mar 2019, at 12:38 am, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> 
> On Fri, Mar 29, 2019 at 12:34 AM Nicholas Alexeev <naalexeev at alaska.edu> wrote:
> I noticed that the genfromtxt() function is slow and it consumes a large amount of memory. I am trying to improve it. Does anyone have any tips? Thanks.
> 
> If your data can be read by pandas.read_csv, that's a lot faster
> 
Astropy also has a similar implementation of an ASCII file parser written in C - 
fastbasic.py, cparser.pyx and src/tokenizer.* here:
https://github.com/astropy/astropy/tree/master/astropy/io/ascii


From f20170920 at goa.bits-pilani.ac.in  Fri Mar 29 04:12:09 2019
From: f20170920 at goa.bits-pilani.ac.in (Anany Shrey Jain)
Date: Fri, 29 Mar 2019 13:42:09 +0530
Subject: [SciPy-Dev] GSoC 2019
Message-ID: <CAG7Qgjgq+NVt5usa38aiPw0h6pOtA4waPTYEX2u4_h5800sQ=g@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190329/9deb0c01/attachment.html>

From deathcoderx at gmail.com  Thu Mar 28 23:56:47 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Fri, 29 Mar 2019 09:26:47 +0530
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CAGu2niU3NRhWyCpuMw8WMjfC0sLgq7=PtO8PZJDrsYLSR8V81w@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>
Message-ID: <CADYNDzipyXrOeDxbx+ngL0G06LdYpAq32qk2jEO+75=JUREedw@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190329/f03741f7/attachment-0001.html>

From larson.eric.d at gmail.com  Sat Mar 30 13:27:03 2019
From: larson.eric.d at gmail.com (Eric Larson)
Date: Sat, 30 Mar 2019 13:27:03 -0400
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CADYNDzipyXrOeDxbx+ngL0G06LdYpAq32qk2jEO+75=JUREedw@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>
Message-ID: <CAGu2niXLZvwDCGgD15Ka47vFgA=AmuCPiVoKqi4=+jfjkndHgA@mail.gmail.com>

I think from the user perspective, being able to use `scipy.fftpack`
namespace, just with a different backend under the hood after calling some
function (either in SciPy or the third party library via some agreed API
standard) to tell it to switch, would be nicer than creating a new
namespace on the fly via this newAPI function.

Eric


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/6828aed7/attachment-0001.html>

From larson.eric.d at gmail.com  Sat Mar 30 13:31:51 2019
From: larson.eric.d at gmail.com (Eric Larson)
Date: Sat, 30 Mar 2019 13:31:51 -0400
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CAG7Qgjgq+NVt5usa38aiPw0h6pOtA4waPTYEX2u4_h5800sQ=g@mail.gmail.com>
References: <CAG7Qgjgq+NVt5usa38aiPw0h6pOtA4waPTYEX2u4_h5800sQ=g@mail.gmail.com>
Message-ID: <CAGu2niVWsKrMukfWcAWAtj-1NBm2utCeh3BOnNku7jNoAcx-kw@mail.gmail.com>

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

From grlee77 at gmail.com  Sat Mar 30 19:38:41 2019
From: grlee77 at gmail.com (Gregory Lee)
Date: Sat, 30 Mar 2019 19:38:41 -0400
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CAG7Qgjgq+NVt5usa38aiPw0h6pOtA4waPTYEX2u4_h5800sQ=g@mail.gmail.com>
References: <CAG7Qgjgq+NVt5usa38aiPw0h6pOtA4waPTYEX2u4_h5800sQ=g@mail.gmail.com>
Message-ID: <CAJR3sXfnnr-0JO87gLbhh-7b-w=KjaNpac+F+FHTeFt2K=_QMw@mail.gmail.com>

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

From grlee77 at gmail.com  Sat Mar 30 19:53:02 2019
From: grlee77 at gmail.com (Gregory Lee)
Date: Sat, 30 Mar 2019 19:53:02 -0400
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CADYNDzipyXrOeDxbx+ngL0G06LdYpAq32qk2jEO+75=JUREedw@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>
Message-ID: <CAJR3sXdcPMAn_DETF8W-=MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw@mail.gmail.com>

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-0001.html>

From deathcoderx at gmail.com  Sat Mar 30 16:30:28 2019
From: deathcoderx at gmail.com (Gopi Manohar Tatiraju)
Date: Sun, 31 Mar 2019 02:00:28 +0530
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <CAJR3sXdcPMAn_DETF8W-=MWnGbkJMpQ2hK1ni20zoLbgf6S0Yw@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>
Message-ID: <CADYNDzgcYEQ4Wy9Yd2J+MCPE+q+k1bjYTR=X31qNd=MwmDC8ag@mail.gmail.com>

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/20190331/0b55d17b/attachment-0001.html>

From f20170920 at goa.bits-pilani.ac.in  Sun Mar 31 19:00:24 2019
From: f20170920 at goa.bits-pilani.ac.in (Anany Shrey Jain)
Date: Mon, 1 Apr 2019 04:30:24 +0530
Subject: [SciPy-Dev] GSoC 2019
In-Reply-To: <mailman.99.1553989995.2938.scipy-dev@python.org>
References: <mailman.99.1553989995.2938.scipy-dev@python.org>
Message-ID: <CAG7Qgjh5bwiCfDkKMMzEndZzfEDRicXxOq3c+YHk9Wv1Op35mA@mail.gmail.com>

Hey,
Thanks Greg and Eric for the new ideas and suggestions about the
implementation of API. I have updated the page with greater details about
the implementation of each approach. I have started it with explaining each
approach and in the end I tried to club all these approaches to get
something better. Please have a look:
https://github.com/ananyashreyjain/Gsoc-Scipy/wiki/Gsoc-2019:-Scipy

cheers,
Anany Jain.

On Sun, Mar 31, 2019 at 5:23 AM <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: GSoC 2019 (Eric Larson)
>    2. Re: GSoC 2019 (Gregory Lee)
>    3. Re: GSoC 2019 (Gregory Lee)
>
>
> ----------------------------------------------------------------------
>
> 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/20190401/baa2fa8d/attachment-0001.html>