On 27-lug-10, at 23:28, dsimcha wrote:
== Quote from Fawzi Mohamed (fa...@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
