What did you do this week?

I started off looking into uarray, a library for multi-method dispatch for different backends. I created a working prototype for uarray support in scipy.fft and used this to start benchmarking the overheads involved. I've also been looking into it's design and had online discussions with one of the authors.

I also made some requested changes to my scipy.fft pull-request, including updating the tutorials and benchmark suite. This revealed some serious performance regressions for 1D FFTs, as compared with scipy.fftpack. So, I deverted my attention to resolving these issues which saw over 10x improvement for small FFTs.

What is coming up next?

I need to evaluate the uarray aproach in comparison to my custom backend solution that I implemented last week. Of particular interest is the performance overhead which will need to be compared and possibly optimised. There are also a number of design choices that differ between uarray and my custom solution which I will need to reconsider and discuss on the mailing list.

Did you get stuck anywhere?

No significant blockers, although the work on optimising for 1D FFTs did take time away from the backend work that I had planned to focusing on.

What did you do this week?

I have been working on my pull request to add scipy.fft. This included:

• Investigating and fixing test failures
• Adding an optimized general purpose FFT for real input
• Writing documentation
• Solving build issues

I've also created a working prototype backend system, with tests for the basic functionality of switching between backends and calling functions.

What is coming up next?

I will hopefully start to get reviews for my open pull request and can respond to feedback. I'll also continue to work on the backend system by expanding my current prototype and creating a parallel implementation using uarray which implements a similar backend system. This will be used to open a discussion about whether or not uarray is suitable and ready to be deployed within SciPy.

There are also a number of improvements that can be made to the general state of FFTs within SciPy. For example, scipy.fftpack can be made to use the faster PocketFFT implementation and PocketFFT itself can be expanded to include the sine and cosine transforms that are in fftpack.

Did you get stuck anywhere?

SciPy imports most of the NumPy API into it's own namespace. In particular, I discovered that numpy.fft.fft is imported as scipy.fft; conflicting with my new scipy.fft module. This will hopefully be deprecated and removed in a future version of SciPy but for the time being I've had to use a workaround for the issue. By overriding the module's __class__, we can make the scipy.fft module callable as if it were a function. This works, but has some unfortunate side effects, one of which was thoroughly confusing the documentation generator (sphinx) which silently ignored the whole scipy.fft module.

This whole tangle took a while to work out but I got there in the end.

What did you do this week?

I have been working towards a minimum viable product for the scipy.fft submodule. This involved writing a wrapper around pypocketfft to satisfy the numpy.fft interface, as well as integrating pypocketfft into SciPy's build system. I have opened a draft PR in which all of numpy's fft tests are passing and all but one of the fftpack tests are passing.

What is coming up next?

The draft PR needs to be polished to the point where it is review ready:

• Some small precision issues need to be resolved
• Documentation needs to be written
• fftpack had various optimisations for real input which need to be reimplemented with pocketfft

I can also begin work on the backend system:

• mechanism for installing a backend
• configuration API to give users more control over each backend

Did you get stuck anywhere?

I initially had a lot of trouble getting the build system to work. Any attempt to add or modify scipy submodules were causing build failures in completely unrelated parts of SciPy. I was only able to resolve this after reinstalling my entire python environment. After solving that, I had no major blockers.

Hello, my name is Peter from the UK where I'm studing computational physics. I've used scipy a lot throughout my degree and through my participation in GSoC, I hope to return the favour! Over the summer I'll be working to enhance scipy's fast-fourier transform (fft) library.  This will include the ability for  users to supply their own implementations at run time.

Initially, this was just going to be a new backend system for the existing module scipy.fftpack. Over the past few weeks, I've already had lots of great discussion with the community; both on the mailing list (SciPy-Dev) and on GitHub in a related issue. From this discussion, the project has now evolved into creating a new module scipy.fft which will now also have:

• support for multiple backends
• default to using pocketfft for improved performance and accuray
• an interface that matches better with numpy.fft

The next steps will be to draft up the interface to scipy.fft with the new default implementation. This will no doubt be iterated on in a pull request on github. Once that gets merged, I should be in a good place to start implementing support for different backends.