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

Thu May 9 15:47:18 EDT 2019

On Thu, May 9, 2019 at 6:04 PM Todd <toddrjen at gmail.com> wrote:

> On Thu, May 9, 2019 at 10:55 AM 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.
>>
>>
>>
>> See:
>>
>> https://github.com/scipy/scipy/issues/2487
>>
>> https://scipy.github.io/devdocs/roadmap-detailed.html#fftpack
>>
>
> Yes, these are the sorts of issues this idea would fix.  However, adding
> backend support to scipy wouldn't fix these issues, since the duplication
> these discuss would still exist in numpy.
>

The problem is simply orthogonal to the backend feature. We have two very
similar but slightly incompatible APIs in NumPy and SciPy, and evolving
those to match is tricky. We do want to get them to match, but no one has
sat down to create a good plan for how to achieve that. Once they match,
the implementation of the SciPy functions that also exist in NumPy could
indeed be removed and those functions could simply be aliased to the NumPy
ones instead.

Also note that NumPy just switched to Pocketfft, and for SciPy we want to
do that too. So at that point the implementations really are duplicate.

>
>> > 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.
>>
>
> As I said, this was a problem traditionally, before wheels and openblas.
>
>
>> > 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.
>>
> I had the problem backwards.  scipy supports more dtypes, but is slower,
> at least according to comments in fftconvolve:
>
> https://github.com/scipy/scipy/blob/master/scipy/signal/signaltools.py#L409
>

"Pre-1.9 NumPy FFT routines are not threadsafe." --> that can be ripped out
now. I don't see where it says it's slower, it shouldn't be. Anyway, not
worth looking at if we replace fftpack with Pocketfft anyway.

Cheers,
Ralf

>
> 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
>>
> _______________________________________________
> 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/20190509/44a7ad8d/attachment.html>