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
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@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@python.org https://mail.python.org/mailman/listinfo/scipy-dev
On Fri, Mar 29, 2019 at 4:12 AM Anany Shrey Jain < f20170920@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@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
participants (3)
-
Anany Shrey Jain -
Eric Larson -
Gregory Lee