FFT Lib?

[Fawzi Mohamed]

On 27-lug-10, at 23:28, dsimcha wrote:

> == Quote from Fawzi Mohamed (fawzi at gmx.ch)'s article
>> I was preceded, that is a good list. I can only say that FFTW is
>> *really* good, and if you structure your code well you should be able
>> to support more than one library.
>> I have wrappers for fftw, and it can be used with NArray (N
>> dimensional dense arrays in blip), but is not directly there exactly
>> due to the license.
>> So having a fallback FFT would be useful for me.
>> ciao
>> Fawzi
>
> This was kind of my point:  Does a "simple and good enough" FFT  
> that's O(N log N)
> but not super optimized and maybe works on generic ranges and ranges  
> of ranges
> belong in Phobos?  The idea is that if you just need a few FFTs here  
> and there,
> convenience is important, and they're not a major bottleneck for  
> you, you use
> Phobos.  If you need the absolute best even if it has to be  
> installed separately,
> is under a more restrictive license, is more of a PITA to use, etc.,  
> you use FFTW
> or something.

about belonging to phobos I don't know, but it would be useful.
The program I am working on will be GPL, so I don't have problems with  
fftw,
still the fftw binding is one place where I know that I should work  
more...

> My use case, to give a little more detail as an example, is that I  
> want to add
> kernel density estimation to dstats.  I need a reasonably efficient  
> way to compute
> a convolution, but not super-optimized pedal-to-the-metal ones, and  
> I need to not
> have to add a dependency to dstats just for this and for the license  
> to be compatible.

I understand, I need more performance from the fft.

I know numpy  uses fftpack, but that is fortran, but it has a c  
version, probably not the best choice to have a maintanable code, but  
the .c version is small, see
http://www.netlib.org/fftpack/

fawzi