Re: [eigen] FFT for Eigen

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2009/5/18 Mark Borgerding <mark@xxxxxxxxxxxxxx>:
>  1. one-dimensional FFTs, forward and inverse for float, double,long
>     double  (i.e. minimal functionality) this is about 90% complete
>  2. real-only optimization (this involves mostly cannibalizing the
>     existing kissfft C code)
>  3. multi-dimensional FFTs ( more cannibalizing from C version)
>  4. backend for FFTW ( using this would require application to be GPL,
>     or the developer to have a commercial MIT license)
>  5. backend for intel Math Kernel Library (this allows use in closed
>     source applications that have paid their licensing fee to intel.
> Explicitly coding to this interface may not be strictly necessary,
>     since IMKL has a FFTW adapter interface already)

That's quite a bit of a TODO :) I'd like to encourage you to start
developing this under Hg from the outset. This way, you get all the
benefits of revision control, people can start using and reviewing
your code, etc.

> Even though it shows up last in the development order, I *really* want the
> ability to choose at compile time (maybe even at runtime) between kissfft,
> FFTW, and IMKL.   Allowing the different backends makes sure everybody can
> get what they need based on their individual requirements regarding
> licensing, finances, code size, and execution speed.  My hope is that this
> will become the only FFT interface a C++ developer will ever need to learn
> ;)

Exactly the Eigen philosophy :)

> FFTW and IMKL both support arbitrary sizes, real FFTs, and multiple
> dimensions.

Good to know. So we really want that level of generality in the API.
(That wasn't clear in the former FFT discussion we had on this list).

> You are correct that the existing kissfft code is "as hardcore C as it
> gets".  That was the aim for the original kissfft. There are a lot of
> embedded systems that lack FPUs, megabytes of RAM and C++ compilers.
>  However, I don't think Eigen will get used much on those systems.

By definition, Eigen does require a C++ compiler -- and a good one. It
does get used on small embedded platforms but they are more like ARM
so they do have at least a single precision FPU, MBs of RAM, and GCC.
That said Eigen is very extensible wrt numeric types so if you have a
good fixed-point type, it's easy to support it with Eigen. Just edit
NumTraits.h and MathFunctions.h (can be done from outside Eigen).

>    The
> need for macros to handle different types goes away with C++ templates.

Exactly.

>  My
> point is : Don't worry, this module will not simply be C compiled by a C++
> compiler.

Great, looking forward to your branch.

Cheers,
Benoit