Re: [eigen] Eigen/FFT |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Eigen/FFT*From*: Mark Borgerding <mark@xxxxxxxxxxxxxx>*Date*: Tue, 16 Jun 2009 14:11:16 -0400

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

**Follow-Ups**:**Re: [eigen] Eigen/FFT***From:*Rohit Garg

**References**:**[eigen] Eigen/FFT***From:*Mark Borgerding

**Re: [eigen] Eigen/FFT***From:*Benoit Jacob

**Re: [eigen] Eigen/FFT***From:*Mark Borgerding

**Re: [eigen] Eigen/FFT***From:*Rohit Garg

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Eigen/FFT** - Next by Date:
**Re: [eigen] Eigen/FFT** - Previous by thread:
**Re: [eigen] Eigen/FFT** - Next by thread:
**Re: [eigen] Eigen/FFT**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |