[SciPy-Dev] PR for overlap-add convolution

[Nathaniel Smith]

On Thu, Sep 26, 2019 at 6:51 PM Todd <toddrjen at gmail.com> wrote:
> I have submitted a PR [1] for a new function, "oaconvolve", which is an implementation of the overlap-add algorithm for convolution.  This algorithm is much faster than conventional FFT-based > We previously discussed whether this should be its own function or part of fftconvolve.  The performance and memory characteristics of this function are significantly different than those of fftconvolve and would really be used in different situations, so the consensus seemed to be that this should be its own function.  I would ultimately like "convolve" to be able to use oaconvolve when it is the best choice, but that is an issue for later.
>
> There is a "method" argument for choosing whether to automatically fall back on fftconvolve or raise an error.  Being able to prevent falling back on fftconvolve is essentially for testing.  We need to be able to make sure that oaconvolve is actually being tested and not the fftconvolve fallback.  But this may not be the best way to do that.

It seems like there's some contradiction between the idea that it
needs to be its own function so that users can control which algorithm
they're using, but then it sometimes silently falls back to
fftconvolve, so they can't – and then you need an argument to disable
the fallback because you do need to control the choice of algorithm.

What would be the consequences of removing the fallback entirely?

-n

-- 
Nathaniel J. Smith -- https://vorpus.org