<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu Mar 1 10:40:16 EST 2018, Todd<span dir="ltr"></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
Similarly, there is an fft-based version of correlation equivalent to<br>
fftconvolve that isn't implemented,</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> 2D and n-d versions of fft convolution<br>
and correlation that aren't implemented, etc.<br></div></blockquote><div><br></div><div>correlate and convolve are both N-D, and implemented using fftpack when possible, which is compiled fortran, so I'm not sure those would benefit much.<br></div><div><br></div><div>convolve2d and correlate2d could benefit from FFT.  Only reason they don't is because of the boundary conditions, but I think they could be adapted to FFT if the inputs were extended in the relevant ways first?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
A lot of these issues apply elsewhere in scipy.signal.  For example the<br>
stft/spectrogram uses a slow, naive implementation.<br></div></blockquote><div><br></div>All of the _spectral_helper functions like stft() and spectrogram() are fftpack-based, as well.  Is there a lot of room for improvement here?<br></div></div></div>