[SciPy-Dev] GSoC 2019 Projects

Sat Apr 6 19:04:24 EDT 2019

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

Hi, Peter!

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

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

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

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

  3rd task.

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

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

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

  entirely in python or cython?

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

- Nikolay

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

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

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

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

Hi Greg,

Thanks for your response.

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

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

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

Peter

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

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

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

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

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

Cheers,

Ralf

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

Hi Peter,

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

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

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

- Greg

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

Hello,

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

are still looking for students?

A bit about myself

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

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

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

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

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

number of computer science courses covering software engineering, object

oriented design and high performance programming.

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

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

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

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

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

Questions about the projects

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

I have some questions regarding both of the proposed projects.

Revamp fftpack:

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

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

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

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

       import scipy.fftpack

       import pyFFTW.interfaces.scipy_fftpack as fftw_pack

       scipy.fftpack.set_backend(fftw_pack)

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

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

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

  configuration from the user.

Improve ODE solvers (mainly the first 3 tasks):

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

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

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

  3rd task.

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

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

  entirely in python or cython?

Best regards,

Peter

_______________________________________________

 SciPy-Dev mailing list

 mailto:SciPy-Dev at python.org

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

_______________________________________________

 SciPy-Dev mailing list

 mailto:SciPy-Dev at python.org

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

_______________________________________________

 SciPy-Dev mailing list

 mailto:SciPy-Dev at python.org

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

_______________________________________________

SciPy-Dev mailing list 

mailto:SciPy-Dev at python.org 

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