[SciPy-dev] Renaming fftpack to fft, removing backends

David Cournapeau david@ar.media.kyoto-u.ac...
Tue Oct 28 03:49:21 CDT 2008


    There are some things I would like to do for scipy.fftpack during
the sprint, and I would like to know if anybody would be strongly
against any one of those:

renaming scipy.fftpack -> scipy.fft

Rationale: fftpack is the name of an implementation (fftpack being the
name of the Fortran library we use when no other fft library is
available), and does not fit the convention of any other scipy top

How: For 0.7, we could rename it while keeping scipy.fftpack as an empty
placeholder (like scipy.linsolve), and deprecating scipy.fftpack.

Removing all backends but fftpack

Rationale: we have 5 backends (fftpack, djbfft, fftw2 and 3, mkl), and
none of them is complete. I would much prefer focus on one (fftpack),
make it complete (for example supporting float32 type), than having 5
half implemented ones. Although, more backends mean more reliability
problems for installation, distribution, support, etc...

People may argue that fftw3 or MKL is faster: it is true in theory, but
in practice, not so much. In particular, with the current
implementation, both fftw2 and fftw3 are as fast or even slower than
fftpack (because the wrappers are relatively naive, and do not use fftw
effectively to get max speed). MKL is faster, but a lot of
functionalities are missing for this backend.

How: putting all the code not related to fftpack to a scikits or
something, so people who really need the speed can use this. Since you
need to compile scipy by yourself anyway for MKL, I don't see this as a
huge problem.

If I don't get answer within the sprint, I will proceed with the above plan,



More information about the Scipy-dev mailing list