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

[Ralf Gommers]

On Thu, May 9, 2019 at 4:54 PM Peter Bell <PeterBell10 at live.co.uk> wrote:

> > This would be a bit more extreme, but might this be better in numpy?
>
>
>
> AFAIK the main issue here is that NumPy and SciPy have incompatible APIs
> and
>
> SciPy also has more types of transforms like DCT and DST. It also seems
> that the
>
> scipy functions are generally intended to be preferred over numpy. I think
>
> keeping it in scipy is also consistent with modules like linalg where
> there is
>
> some duplication but generally more functionality in scipy.
>

For who is interested in these, please read
https://github.com/scipy/scipy/issues/10175. That started as "hey there's a
new C++ PyPocketfft" (which looks cool), and evolved into "let's create a
scipy.fft module with an API that mirrors numpy.fft and gets the backend
system".

Peter, I now read your whole document more carefully, really interesting. I
tried to comment on some of the smaller things to not mix those up with the
discussion on the GitHub issue, but the doc is view-only. Perhaps you can
switch it to "suggest edits" mode to let people insert comments?

Cheers,
Ralf


>
> See:
>
> https://github.com/scipy/scipy/issues/2487
>
> https://scipy.github.io/devdocs/roadmap-detailed.html#fftpack
>
>
>
> > As I understand it, at least traditionally, numpy has been easier to
> install
>
> > due to not needing a Fortran compiler
>
>
>
> It should be easy enough to say `pip install scipy` pretty much anywhere,
> right?
>
> And for those going out of their way to compile themself, I'm not sure
> that a
>
> fortran compiler is that much more of a burden.
>
>
>
> > 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
>
>
>
> Could you give some examples of this? I thought scipy generally supported a
>
> wider variety of both transforms and dtypes.
>
>
>
> Peter
>
>
>
>
>
> *From:* SciPy-Dev <scipy-dev-bounces+peterbell10=live.co.uk at python.org> *On
> Behalf Of *Todd
> *Sent:* 09 May 2019 14:55
> *To:* SciPy Developers List <scipy-dev at python.org>
> *Subject:* Re: [SciPy-Dev] Backend support for fftpack - GSoC 2019
>
>
>
> 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).
> _______________________________________________
> 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/20190514/81c1e7a1/attachment.html>