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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
