[SciPy-Dev] GSoC 2019 Projects

Fri Apr 5 12:29:50 EDT 2019

On Fri, Apr 5, 2019 at 7:34 AM Peter Bell <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. 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.

>
>
> *From:* SciPy-Dev <scipy-dev-bounces+peterbell10=live.co.uk at python.org> *On
> Behalf Of *Gregory Lee
> *Sent:* 04 April 2019 15:42
> *To:* SciPy Developers List <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 <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
> 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/20190405/e2f383d6/attachment.html>