Re: [eigen] Eigen/FFT

[Rohit Garg <rpg.314@xxxxxxxxx>]

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