Re: [eigen] Eigen/FFT

[Mark Borgerding <mark@xxxxxxxxxxxxxx>]

Rohit Garg wrote:

Regrading multidimensional transforms, I doubt if it will be easy (API
wise) since the rest of Eigen is geared towards Matrices and  vectors
only. BTW, is it even within the scope of goal of Eigen to do this?
  

When I've been saying "multidimensional", I've been thinking first and foremost about 2d matrices.
The mechanics of 2d,3d,... FFTs are so similar that we may as well allow arbitrary dimensions.

And yes, FFTW's plan creation API is not threadsafe. Their FFT
execution api is. This should be emphasised in the docs since the rest
of API is stateless and trivially threadsafe.
  

Good point.
Does Eigen have access to and make use of any threading and synchronization primitives?

On Tue, Jun 16, 2009 at 9:10 PM, Mark Borgerding<mark@xxxxxxxxxxxxxx> wrote:
  

FYI,
I added a wiki page to document Eigen::FFT
http://eigen.tuxfamily.org/index.php?title=EigenFFT


Rohit Garg wrote:

Oh, that's very nice. Thanks.

On Tue, Jun 16, 2009 at 11:11 AM, Mark Borgerding<mark@xxxxxxxxxxxxxx>
wrote:


If you
#include <fftw3.h>
before
#include <Eigen/FFT>

Then the default backend is FFTW.





Rohit Garg wrote:


I am personally more interested int he FFTW backend. Is that complete yet?
I checked the fft fork page on bitbucket. There doesn't seems to be an
example showing how to use the FFTW backend.

On Tue, Jun 16, 2009 at 7:45 AM, Mark Borgerding<mark@xxxxxxxxxxxxxx>
wrote:



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