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

[Travis E. Oliphant]

David Cournapeau wrote:
> Hi,
>
>     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
> subpackage.
>
> How: For 0.7, we could rename it while keeping scipy.fftpack as an empty
> placeholder (like scipy.linsolve), and deprecating scipy.fftpack.
>   
+1
> 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.
>   
+1