[SciPy-dev] Cleaning and fixing fft in scipy ?
Sat Apr 28 05:52:18 CDT 2007
Pearu Peterson wrote:
> On Sat, April 28, 2007 1:06 pm, Pearu Peterson wrote:
>> In summary, I am not against to rewriting scipy.fftpack provided that
>> 1) it is carried out in scipy.sandbox until it becomes more-or-less
>> equivalent to the current scipy.fftpack in terms of features,
>> unit-testing, supported fft backends, and documentation.
> I now reread your original proposal and I think that this condition
> can be relaxed provided that after applying any patches to
> scipy.fftpack all fftpack unittests pass ok.
Thanks for your email, Pearu. I would certainly not submit a patch which
do not pass the unittest; problem being I cannot test all
implementations (I can test fftpack/fftw2/fftw3 on Linux easily; I
cannot get djbfft to compile on my machine; if necessary, I can install
the MKL; I don't know whether OS and compiler matters a lot for fftpack,
as I don't intend to touch the setup part).
I think that I was not really clear in my former emails: I do not
suggest a rewrite, but a 2 steps improvements:
- one which does not change anything to the code except its
organization (one file for one fft API instead of the #ifdef)
- once the first step is done and considered acceptable by the scipy
developers, I would like to improve fftw3, such as it is at least on par
with fftw2: right now, for fftw3, the arrays are copied twice. I think
fftw3 requires a more sophisticated caching scheme, because with fftw3
you cannot use the same plan when the input/output are changed, at least
with the basic API. For example, Octave is using such a scheme. Other
implementations would be untouched.
> Scipy-dev mailing list
More information about the Scipy-dev