On 30-lug-10, at 16:14, dsimcha wrote:
[...]
Part of the preprocessor abuse is necessary for supporting
fixed point FFTs. Does anyone care about these (I sure don't), or
can I just get
rid of them?
I don't care about them
I'm hoping I can refactor this code into a nice D interface, but it
may end up
being that I have to basically start from scratch. One thing I will
absolutely
not do is contribute code without a proper D-style (i.e. templated,
works with
std.complex, etc.) interface. If I can't understand kissfft well
enough to do
this refactoring, then maybe I'll just start from scratch using the
Wikipedia FFT
article and a textbook.
The main thing that you should probably do (apart documenting the
factors and order that you assume/generate)
is splitting fft in initialization of a given size (creating a struct/
class environment) and executing an fft of that size (which might be a
method of the environment (probably better) or a free function taking
the env as parameter).
Both fftpack (http://www.netlib.org/fftpack/doc) and fftw (http://fftw.org/doc/
) have that structure.
This because you can prepare/precompute things to then do the actual
fft in the optimal way.
Then you can still provide easy to use wrappers that call the two
things in sequence.
ciao
Fawzi
