Preparing project proposal for GSoC 2019
Hello, I am writing the mail regarding project proposal for GSoC 2019. I am interested in working with SciPy for the upcoming Google Summer of Code and I am interested in either working on enhancing the randomized numerical linear algebra functionality or fixing the scipy.fftpack module. I understand that it is quite early to talk, since the organization proposals haven't started yet, but I would like to know if a project proposal can be started right now so that the proposals can be better fleshed out by the time the application period starts? Regards, Sourav
Hi Sourav, On Mon, Nov 19, 2018 at 5:47 AM Sourav Singh <ssouravsingh12@gmail.com> wrote:
Hello,
I am writing the mail regarding project proposal for GSoC 2019.
I am interested in working with SciPy for the upcoming Google Summer of Code and I am interested in either working on enhancing the randomized numerical linear algebra functionality or fixing the scipy.fftpack module.
I understand that it is quite early to talk, since the organization proposals haven't started yet, but I would like to know if a project proposal can be started right now so that the proposals can be better fleshed out by the time the application period starts?
That's the earliest start I've seen (which is a good thing)! I suspect that we'll have trouble finding a mentor for the randomized linear algebra, however fftpack could be a good topic. Have you seen https://github.com/numpy/numpy/pull/11888? I suspect that by the time GSoC starts, we'll have merged that into NumPy, and would like to take it over for SciPy. A related topic would be to add a backend system for fft implementations (pyfftw, mkl-fft) Cheers, Ralf
Regards,
Sourav _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
On Sat, Nov 24, 2018 at 11:26 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi Sourav,
On Mon, Nov 19, 2018 at 5:47 AM Sourav Singh <ssouravsingh12@gmail.com> wrote:
Hello,
I am writing the mail regarding project proposal for GSoC 2019.
I am interested in working with SciPy for the upcoming Google Summer of Code and I am interested in either working on enhancing the randomized numerical linear algebra functionality or fixing the scipy.fftpack module.
I understand that it is quite early to talk, since the organization proposals haven't started yet, but I would like to know if a project proposal can be started right now so that the proposals can be better fleshed out by the time the application period starts?
That's the earliest start I've seen (which is a good thing)!
I suspect that we'll have trouble finding a mentor for the randomized linear algebra, however fftpack could be a good topic. Have you seen https://github.com/numpy/numpy/pull/11888? I suspect that by the time GSoC starts, we'll have merged that into NumPy, and would like to take it over for SciPy. A related topic would be to add a backend system for fft implementations (pyfftw, mkl-fft).
And a third topic would be to make the APIs of numpy.fft and scipy.fftpack agree. That would be the lowest on my list because it's hard (requiring lots of discussion on impact on users if we deprecate things etc.), but it's an important one as well. Ralf
Cheers, Ralf
Regards,
Sourav _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
Hello,
On Sat, Nov 24, 2018 at 11:26 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi Sourav,
On Mon, Nov 19, 2018 at 5:47 AM Sourav Singh <ssouravsingh12@gmail.com> wrote:
Hello,
I am writing the mail regarding project proposal for GSoC 2019.
I am interested in working with SciPy for the upcoming Google Summer of Code and I am interested in either working on enhancing the randomized numerical linear algebra functionality or fixing the scipy.fftpack module.
I understand that it is quite early to talk, since the organization proposals haven't started yet, but I would like to know if a project proposal can be started right now so that the proposals can be better fleshed out by the time the application period starts?
That's the earliest start I've seen (which is a good thing)!
I suspect that we'll have trouble finding a mentor for the randomized linear algebra, however fftpack could be a good topic. Have you seen https://github.com/numpy/numpy/pull/11888? I suspect that by the time GSoC starts, we'll have merged that into NumPy, and would like to take it over for SciPy. A related topic would be to add a backend system for fft implementations (pyfftw, mkl-fft).
And a third topic would be to make the APIs of numpy.fft and scipy.fftpack agree. That would be the lowest on my list because it's hard (requiring lots of discussion on impact on users if we deprecate things etc.), but it's an important one as well.
I am interested in adding pocketfft to scipy, which is linked in the numpy PR. Would it be possible to combine this with the backend system project for scipy? Regards, Sourav
On Sun, Nov 25, 2018 at 5:22 AM Sourav Singh <ssouravsingh12@gmail.com> wrote:
Hello,
On Sat, Nov 24, 2018 at 11:26 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi Sourav,
On Mon, Nov 19, 2018 at 5:47 AM Sourav Singh <ssouravsingh12@gmail.com> wrote:
Hello,
I am writing the mail regarding project proposal for GSoC 2019.
I am interested in working with SciPy for the upcoming Google Summer of Code and I am interested in either working on enhancing the randomized numerical linear algebra functionality or fixing the scipy.fftpack module.
I understand that it is quite early to talk, since the organization proposals haven't started yet, but I would like to know if a project proposal can be started right now so that the proposals can be better fleshed out by the time the application period starts?
That's the earliest start I've seen (which is a good thing)!
I suspect that we'll have trouble finding a mentor for the randomized linear algebra, however fftpack could be a good topic. Have you seen https://github.com/numpy/numpy/pull/11888? I suspect that by the time GSoC starts, we'll have merged that into NumPy, and would like to take it over for SciPy. A related topic would be to add a backend system for fft implementations (pyfftw, mkl-fft).
And a third topic would be to make the APIs of numpy.fft and scipy.fftpack agree. That would be the lowest on my list because it's hard (requiring lots of discussion on impact on users if we deprecate things etc.), but it's an important one as well.
I am interested in adding pocketfft to scipy, which is linked in the numpy PR. Would it be possible to combine this with the backend system project for scipy?
Yes, this would be possible - that certainly should fit in a single GSoC. It's also possible that Pocketfft will already be merged by then, given that the author of Pocketfft is quite proactive. The NumPy PR is only waiting for the branching of the 1.16.x release, after which it can in principle be merged (C99 is the blocker now). In that case, implementing a backend system + working on matching signatures for numpy and scipy would still be a nice project. Cheers, Ralf
On Fri, Nov 30, 2018 at 1:39 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Nov 25, 2018 at 5:22 AM Sourav Singh <ssouravsingh12@gmail.com> wrote:
Hello,
On Sat, Nov 24, 2018 at 11:26 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi Sourav,
On Mon, Nov 19, 2018 at 5:47 AM Sourav Singh <ssouravsingh12@gmail.com> wrote:
Hello,
I am writing the mail regarding project proposal for GSoC 2019.
I am interested in working with SciPy for the upcoming Google Summer of Code and I am interested in either working on enhancing the randomized numerical linear algebra functionality or fixing the scipy.fftpack module.
I understand that it is quite early to talk, since the organization proposals haven't started yet, but I would like to know if a project proposal can be started right now so that the proposals can be better fleshed out by the time the application period starts?
That's the earliest start I've seen (which is a good thing)!
I suspect that we'll have trouble finding a mentor for the randomized linear algebra, however fftpack could be a good topic. Have you seen https://github.com/numpy/numpy/pull/11888? I suspect that by the time GSoC starts, we'll have merged that into NumPy, and would like to take it over for SciPy. A related topic would be to add a backend system for fft implementations (pyfftw, mkl-fft).
And a third topic would be to make the APIs of numpy.fft and scipy.fftpack agree. That would be the lowest on my list because it's hard (requiring lots of discussion on impact on users if we deprecate things etc.), but it's an important one as well.
I am interested in adding pocketfft to scipy, which is linked in the numpy PR. Would it be possible to combine this with the backend system project for scipy?
Yes, this would be possible - that certainly should fit in a single GSoC. It's also possible that Pocketfft will already be merged by then, given that the author of Pocketfft is quite proactive. The NumPy PR is only waiting for the branching of the 1.16.x release, after which it can in principle be merged (C99 is the blocker now). In that case, implementing a backend system + working on matching signatures for numpy and scipy would still be a nice project.
Cheers, Ralf
I would be happy to help mentor an FFT-related project and think having a backend system would be very nice. pyFFTW's scipy interfaces are mostly complete, aside from some real-valued transforms for which work was started in: https://github.com/pyFFTW/pyFFTW/pull/95 There were also GPU-based FFTs matching the scipy API proposed recently in https://github.com/cupy/cupy/pull/1745
On Fri, Nov 30, 2018 at 12:10 PM Gregory Lee <grlee77@gmail.com> wrote:
On Fri, Nov 30, 2018 at 1:39 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Nov 25, 2018 at 5:22 AM Sourav Singh <ssouravsingh12@gmail.com> wrote:
Hello,
On Sat, Nov 24, 2018 at 11:26 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi Sourav,
On Mon, Nov 19, 2018 at 5:47 AM Sourav Singh <ssouravsingh12@gmail.com> wrote:
Hello,
I am writing the mail regarding project proposal for GSoC 2019.
I am interested in working with SciPy for the upcoming Google Summer of Code and I am interested in either working on enhancing the randomized numerical linear algebra functionality or fixing the scipy.fftpack module.
I understand that it is quite early to talk, since the organization proposals haven't started yet, but I would like to know if a project proposal can be started right now so that the proposals can be better fleshed out by the time the application period starts?
That's the earliest start I've seen (which is a good thing)!
I suspect that we'll have trouble finding a mentor for the randomized linear algebra, however fftpack could be a good topic. Have you seen https://github.com/numpy/numpy/pull/11888? I suspect that by the time GSoC starts, we'll have merged that into NumPy, and would like to take it over for SciPy. A related topic would be to add a backend system for fft implementations (pyfftw, mkl-fft).
And a third topic would be to make the APIs of numpy.fft and scipy.fftpack agree. That would be the lowest on my list because it's hard (requiring lots of discussion on impact on users if we deprecate things etc.), but it's an important one as well.
I am interested in adding pocketfft to scipy, which is linked in the numpy PR. Would it be possible to combine this with the backend system project for scipy?
Yes, this would be possible - that certainly should fit in a single GSoC. It's also possible that Pocketfft will already be merged by then, given that the author of Pocketfft is quite proactive. The NumPy PR is only waiting for the branching of the 1.16.x release, after which it can in principle be merged (C99 is the blocker now). In that case, implementing a backend system + working on matching signatures for numpy and scipy would still be a nice project.
Cheers, Ralf
I would be happy to help mentor an FFT-related project and think having a backend system would be very nice.
Awesome, thanks Greg! pyFFTW's scipy interfaces are mostly complete, aside from some real-valued
transforms for which work was started in: https://github.com/pyFFTW/pyFFTW/pull/95 There were also GPU-based FFTs matching the scipy API proposed recently in https://github.com/cupy/cupy/pull/1745
Interesting:) Ralf
Hello, I am creating a new conversation since I have created a draft proposal for the project here- https://goo.gl/S3J9Kg I would be glad to know your views about the proposal and what needs to be done to improve the proposal. I also have a few questions- 1) Would it be fine if I create a PR to SciPy's codebase to adopt pocketfft? The PR could give me an understanding of how to contribute to SciPy's fftpack module. 2) I noticed that scipy.ffitpack has fortran sources. What kind of knowledge of fortran is expected of me for this project? I have a basic knowledge of fortran, but I am not very confident enough to write high-level code in the language. Regards, Sourav
On Mon, Dec 3, 2018 at 12:41 PM Sourav Singh <ssouravsingh12@gmail.com> wrote:
Hello,
I am creating a new conversation since I have created a draft proposal for the project here- https://goo.gl/S3J9Kg
Hi Sourav, thanks for writing that up, that's a good start. Before submission you'll have to add a lot more detail about how to go about the implementation, but there's time for that. I would suggest to focus on how to approach the backend system, because there's a lot of options to do that.
I would be glad to know your views about the proposal and what needs to be done to improve the proposal. I also have a few questions-
1) Would it be fine if I create a PR to SciPy's codebase to adopt pocketfft? The PR could give me an understanding of how to contribute to SciPy's fftpack module.
I would prefer to wait a little bit with that. The branching of 1.16.x in the NumPy repo is imminent (1-3 weeks I expect), and at that point Pocketfft can be merged into NumPy. Then we'll be able to have a discussion with the author, and port things to SciPy. I think having two PRs for Pocketfft integration going on in parallel is a bit much and likely will lead to duplicate work. If you want to try your hand on something in fftpack now, this is probably the best choice of all the open issues: https://github.com/scipy/scipy/issues/5986#issuecomment-313889128
2) I noticed that scipy.ffitpack has fortran sources. What kind of knowledge of fortran is expected of me for this project? I have a basic knowledge of fortran, but I am not very confident enough to write high-level code in the language.
That's a good question. I think it's limited. For the set of function we're replacing, we just dont use the Fortran implementation at all anymore, and instead just have a C implementation. So you'll have to be comfortable in C, as well as in dealing with the build system, but I won't expect you having to make significant changes in Fortran code. Cheers, Ralf
On Fri, Dec 7, 2018 at 1:15 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Mon, Dec 3, 2018 at 12:41 PM Sourav Singh <ssouravsingh12@gmail.com> wrote:
1) Would it be fine if I create a PR to SciPy's codebase to adopt pocketfft? The PR could give me an understanding of how to contribute to SciPy's fftpack module.
I would prefer to wait a little bit with that. The branching of 1.16.x in the NumPy repo is imminent (1-3 weeks I expect), and at that point Pocketfft can be merged into NumPy. Then we'll be able to have a discussion with the author, and port things to SciPy. I think having two PRs for Pocketfft integration going on in parallel is a bit much and likely will lead to duplicate work.
If you want to try your hand on something in fftpack now, this is probably the best choice of all the open issues: https://github.com/scipy/scipy/issues/5986#issuecomment-313889128
I think the suggested SciPy issue above is a good one. Last week I rebased the real-to-real transforms PR in pyFFTW on current master so it is up to date and ready for continued work. There are still a few open items in the checklist at https://github.com/pyFFTW/pyFFTW/pull/256 if you are interested. However, as your project would be under SciPy, I think your time is probably better spent working on a SciPy PR such as the one Ralph suggested.
participants (3)
-
Gregory Lee -
Ralf Gommers -
Sourav Singh