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.
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@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:
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@python.org
https://mail.python.org/mailman/listinfo/scipy-dev
SciPy-Dev mailing list
SciPy-Dev@python.org
https://mail.python.org/mailman/listinfo/scipy-dev