[SciPy-Dev] GSoC 2019 Projects

Fri Apr 5 13:49:35 EDT 2019

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

>
>
> 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.
>

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=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
>>
> _______________________________________________
> 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/443ce897/attachment-0001.html>