In short - A couple functions with a few pointers would fall dismally short of the 'mark'.
I agree with this. We need to define an interface that can accommodate the various forms of usage and implementation of the DFT. Even if the first implementation of that interface is limited in terms of performance.
So far everyone has identified a number of things that may belong in a DFT interface. Maybe we need to work on a list. However I don't know if the original poster is up for this kind of work. He proposed a simple implementation of FFT that covered a single usage.
Some of the things to support so far in the interface include: * Abstraction of data it operates on (std::complex, fixed point, ...) * Abstraction of dimensionality * Abstraction of memory layout of data (Is it strided, are the real/imag interleaved, if doing multiple dimensions how are they arranged in memory). Using iterators is probably sufficient here * Size of the transform (supporting non power of 2 is important) * Does it use temporary storage or not On this point I think this is a must. If for example you want to support using FFTW as a backend implementation, you want to be able to store data across transform calls. * Is the transform to happen in-place or not * Do we allow definition of phase rotations as part of the interface or require them as pre/post processing steps I am not sold on this as part of the transform itself. * Do we want to support (probably separate interface) real (vs complex) DFT transforms? * How will we support backend customizations? Allowing a single interface to be backed by say FFTW is probably a very good thing in this situation. Not just FFTW but many embedded platforms provide their own custom implementation of the FFT that a user may wish to utilize, but wrap it in a compatible API.
+1 This is a great summary that shows how multifaceted the concept of FFT within Boost actually is --- or would be. Taking on FFT in Boost would be challenging. The best FFT implementations tend to be proprietary. They are also written in language forms that lack the portability and clarity of interface to which Boost strives. At the same, the existing implementations are, insofar as performance is concerned, hard to beat. Nonetheless, a portable FFT with Boost licensing would be a very valuable resource for the community. If there is ever a coalition of interested developers on this topic, I might be in on it --- with whatever minimal contribution I could offer. Got it on the back burner. Sincerely, Chris.