On Tue, Oct 28, 2014 at 9:19 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:

On Tue, Oct 28, 2014 at 1:32 AM, Jerome Kieffer <Jerome.Kieffer@esrf.fr> wrote:
On Tue, 28 Oct 2014 04:28:37 +0000
Nathaniel Smith <njs@pobox.com> wrote:

> It's definitely attractive. Some potential issues that might need dealing
> with, based on a quick skim:

In my tests, numpy's FFTPACK isn't that bad considering
* (virtually) no extra overhead for installation
* (virtually) no plan creation time
* not that slower for each transformation

Because the plan creation was taking ages with FFTw, numpy's FFTPACK was often faster (overall)

Cheers,

Ondrej says that f90 fftpack (his mod) runs faster than fftw.

I would be interested to see the benchmarks for this.

The real issue with fftw (besides the license) is the need for plan computation, which are expensive (but are not needed for each transform). Handling this in a way that is user friendly while tweakable for advanced users is not easy, and IMO more appropriate for a separate package.

The main thing missing from fftpack is the handling of transform sizes that are not products of 2,3,4,5.

Strickly speaking, it is handled, just not through an FFT (it goes back to the brute force O(N**2)).

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).

David