Re: [eigen] Eigen/FFT

[Mark Borgerding <mark@xxxxxxxxxxxxxx>]

Many of us have things that make demands on our time, like jobs, 
families, lives, sleeping, eating, et cetera.
There's no rush. The FFT module doesn't really have any dependency on 
anything within Eigen yet, so it is unlikely that there will be any 
changes in the mainline development that make it incompatible.

I would like to add fwd & inv functions for the Eigen Matrix types into 
the FFT interface, but I could use a little guidance on how to do it 
since I am still an Eigen novice.

### Design choices:
I should mention that in the FFT module, I've made a couple of design 
decisions that stray away from the behavior of most FFT libraries.  The 
intent is to facilitate generic programming and ease migrating code from 
Matlab/octave.   I've based these decisions on my experience both using 
FFTs and answering questions about KISSFFT.  I think the default 
behavior of Eigen/FFT should favor correctness and generality over 
speed. The caller should be able to "opt-out" from the behavior and get 
the speed increase if they want it.
1) Scaling:
Other libraries (FFTW,IMKL,KISSFFT)  do not perform scaling, so there is 
a constant gain incurred after the forward&inverse transforms , so 
IFFT(FFT(x)) = Kx;  this is done to avoid a vector-by-value multiply.  
The downside is that algorithms that worked correctly in Matlab/octave 
don't behave the same way once implemented in C++.

How Eigen/FFT differs: invertible scaling is performed so IFFT( FFT(x) ) 
= x. 

2) Real FFT half-spectrum
Other libraries use only half the frequency spectrum (plus one extra 
sample for the Nyquist bin) for a real FFT, the other half is the 
conjugate-symmetric of the first half.  This saves them a copy and some 
memory.  The downside is the caller needs to have special logic for the 
number of bins in complex vs real.

How Eigen/FFT differs: The full spectrum is returned from the forward 
transform.  This facilitates generic template programming by obviating 
separate specializations for real vs complex.  On the inverse transform, 
only half the spectrum is actually used if the output type is real.


-- Mark

Benoit Jacob wrote:
> Hi,
>
> Just wanted to say that i'm very sorry that i've been to busy to
> review your FFT code (or do anything for eigen). Gael is very busy too
> (he is moving). I will try to do it as soon as possible.
> Meanwhile FFT-concerned people are most welcome to share their
> comments, I would only be able to comment from the point of view of
> Eigen but have no experience with fft.
>
> Thank you for your patience!
> Benoit
>
> 2009/6/11 Mark Borgerding <mark@xxxxxxxxxxxxxx>
>   
> > Comments welcome.
> > http://bitbucket.org/mborgerd/eigen2_for_fft
> >
> > Done:
> >
> > complex & real, fwd and inverse FFTs for float,double,long double
> > kissfft and fftw implementations, selectable as a template parameter
> > default is kissfft unless fftw3.h is included before Eigen/FFT
> >
> > TODO:
> >
> > multi-dimensional transforms
> > IMKL backend
> > interface functions that use Eigen matrix types
> >     
>
>