If I may 'hyjack' the discussion back to the meta-point:

should we be having this discussion on the numpy mailing list at all?

Perhaps the 'batteries included' philosophy made sense in the early days of numpy; but given that there are several fft libraries with their own pros and cons, and that most numpy projects will use none of them at all, why should numpy bundle any of them?

To have a scipy.linalg and scipy.fft makes sense to me, although import pyfftw or import pyFFTPACK would arguably be better still. Just as in the case of linear algebra, those different libraries represent meaningful differences, and if the user wants to paper over those differences with a named import they are always free to do so themselves, explicitly. To be sure, the maintenance of quality fft libraries should be part of the numpy/scipy-stack in some way or another. But I would argue that the core thing that numpy should do is ndarrays alone.

Perhaps the 'batteries included' philosophy made sense in the early days of numpy; but given that there are several fft libraries with their own pros and cons, and that most numpy projects will use none of them at all, why should numpy bundle any of them?

To have a scipy.linalg and scipy.fft makes sense to me, although import pyfftw or import pyFFTPACK would arguably be better still. Just as in the case of linear algebra, those different libraries represent meaningful differences, and if the user wants to paper over those differences with a named import they are always free to do so themselves, explicitly. To be sure, the maintenance of quality fft libraries should be part of the numpy/scipy-stack in some way or another. But I would argue that the core thing that numpy should do is ndarrays alone.

On Tue, Oct 28, 2014 at 11:11 AM, Sturla Molden <sturla.molden@gmail.com> wrote:

David Cournapeau <cournape@gmail.com> wrote:

> The real issue with fftw (besides the license) is the need for plan

> computation, which are expensive (but are not needed for each transform).

This is not a problem if you thell FFTW to guess a plan instead of making

measurements. FFTPACK needs to set up a look-up table too.

> I made some experiments with the Bluestein transform to handle prime

> transforms on fftpack, but the precision seemed to be an issue. Maybe I

> should revive this work (if I still have it somewhere).

You have it in a branch on Github.

Sturla

_______________________________________________

NumPy-Discussion mailing list

NumPy-Discussion@scipy.org

http://mail.scipy.org/mailman/listinfo/numpy-discussion