Re: [eigen] Eigen/FFT

[Rohit Garg <rpg.314@xxxxxxxxx>]

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