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

[Charles R Harris]

On Tue, Oct 28, 2008 at 2:49 AM, David Cournapeau <
david at ar.media.kyoto-u.ac.jp> 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.
>
> 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.
>

IIRC correctly, there are also differences in the way the results of real
transforms are stored, so these backends aren't all that compatible.

>
> 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. The fftpack is a pretty good (if old) implementation whose main failing
is not taking maximum advantage of cache. It does need some supplementation,
a Bluestein implementation for instance, but that is easier to do with a
single target.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20081028/013b502c/attachment.html>