[Numpy-discussion] FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy functions)
Alexander Eberspächer
alex.eberspaecher at gmail.com
Wed Oct 29 14:23:50 EDT 2014
On 29.10.2014 18:03, Pierre-Andre Noel wrote:
>>> Id rather have us discuss how to facilitate the integration of as
> many possible fft libraries with numpy behind a maximally uniform
> interface, rather than having us debate which fft library is 'best'.
>
> I agree with the above.
Absolutely. I think the NumPy/Scipy interfaces are easy and convenient
enough to serve as a front-end to different FFT codes.
>> I would agree if it were not already there, but removing it (like
> Blas/Lapack) is out of the question for backward compatibility reason.
> Too much code depends on it.
>
> And I definitely agree with that too.
>
> I think that numpy.fft should be left there in its current state
> (although perhaps as deprecated). Now scipy.fft should have a good
> generic algorithm as default, and easily allow for different
> implementations to be accessed through the same interface.
Definitely. My attempt at streamlining the use of pyfftw even further
can be found here:
https://github.com/aeberspaecher/transparent_pyfftw
This small package does nothing more than to automatically load fftw
wisdom on export and add a keyword that gives the number of threads to
use to NumPy/Scipy style FFT calls. I think similar attempts could be
made with other FFT libraries. The mission statement would be to map
each library's interface to the simple and convenient SciPy/NumPy-style
interface, and also to wisely choose default parameters (such as e.g.
pyfftw's planner_effort).
Also, I think it's obvious that a generic and easy-to-use implementation
cannot deliver exactly the same performance as hand-tuned code, but
anyway I see plenty room for improvement for SciPy/NumPy's FFT modules.
Alex
More information about the NumPy-Discussion
mailing list