[SciPy-Dev] Backend support for fftpack - GSoC 2019

[Todd]

On Wed, May 8, 2019, 11:50 Peter Bell <PeterBell10 at live.co.uk> wrote:

> Hello all,
>
>
>
> I’m happy to say my GSoC proposal was accepted, so I’ll be working over
> the summer to add support for multiple fftpack backends. For those
> interested, I’ve extracted the main discussion from my proposal which you
> can read here:
>
>
> https://docs.google.com/document/d/1hGMc6ZrsmSi_LSixI5oFbo5cZkPUo92sfmnVthg1u6Y/edit
>
>
>
> There are a several design decisions I raise in the proposal and any
> comments would be appreciated. Of particular note:
>
> * Should backends be allowed to add functionality or should they be
> completely interchangeable. E.g. unlike fftpack, FFTW has support for long
> doubles; should this be exposed to SciPy users?
>
> * Is there any interest in adding a SciPy config file? For just one option
> it’s probably not worthwhile but if there is interest in more config
> options then it starts to make more sense.
>
>
>
> Ideally a clear set of design goals can be agreed upon now, before it gets
> too far into the coding period which begins at the end of the month.
>
>
>
> Peter
>

This would be a bit more extreme, but might this be better in numpy?

As I understand it, at least traditionally, numpy has been easier to
install due to not needing a Fortran compiler, but scipy has a generally
faster FFT implementation.

However, looking at some of the code that uses FFTs in scipy, it falls back
on numpy's FFT because it supports data types scipy doesn't at least for
some implementations. This code will either silently do the wrong thing or
will have to have more complicated run-time checks for data types if we get
backend support in scipy.

However, if the backend support were implemented in numpy we could simplify
all this code.  numpy could be in charge of handling fall-backs if the
requested operation doesn't support the given date type.

Specifically, numpy would have its own FFT back-end.  If scipy is available
it will be used as the default back-end, otherwise the numpy back-end will
be used.  The user can choose a different backend (including the numpy
backend if they want).  The user-facing scipy functions would use the numpy
functions behind-the-scenes.  If the requested operation is not supported
by the requested backend, numpy will emit a warning and fall back on the
numpy version.

This has a few other advantages besides allowing us to simplify the scipy
code-base. First, it will remove the existing confusion regarding whether
to use the numpy or scipy version of FFT functions.  Second, with the new
rng work there is already stuff in numpy that would benefit from a config
file (the fallback warning above could also be configurable).

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190509/f1a9bddf/attachment-0001.html>