Re: [eigen] Eigen/FFT |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Eigen/FFT*From*: Rohit Garg <rpg.314@xxxxxxxxx>*Date*: Tue, 16 Jun 2009 22:11:25 -0700*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=CKKOZ7ofVolbA6Mu0LLCNCOKNja+KUZa0+xP0SMe5sc=; b=hlpBqQTEYG/EnFQAqA6q8YSW7Hnk7HJ1WQ8bREeZCILttMbVruhbMzG+Kp3rDH2A7y w+Y+b8gZvquAkS6PtGcqqJPOwDLNiAxdijl6vx0RbHAiYOzfJXeSIaTjDDB+Y2hZPCOX U1KhOvNISa+skUZfz3jz9mK/frkt8hNHqAxwQ=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=EqVzv6JSnhMFHhEyLHOX+z/C/URTEZitvjCdt3PElIZ4Xquq1RR6fJ63CpoULZMWNy UHXjtPsK+KsEU5hfEsBmFvjEU+NLXgTWQlxmr6QUOVtGGVEFsBG4c5tqlMrQOlnCrqOO vuedZyuE+6a0xzPAizE4QXV2fU/aANO0a1Qyc=

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? 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. 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 > > > > > > > > > > > > > > -- Rohit Garg http://rpg-314.blogspot.com/ Senior Undergraduate Department of Physics Indian Institute of Technology Bombay

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

**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

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

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

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] Eigen::Complex attempt** - Next by Date:
**[eigen] [Patch] fix typo** - 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/ |