Re: [eigen] FFT for Eigen

[ Thread Index | Date Index | More Archives ]

I have been using fftw as well [1], and by doing so I also end up
copying the data, which is a pity, so I would also very much
appreciate such a module.

There are several tricky points I have been bumping into:

1- If I recall correctly, when creating a plan, you pass it two
pointers (or optionally when done inplace, only one) that have been
allocated by fftw.  This way fftw assures they are aligned, etc.
Maybe there is lower level API fftw which might let you apply plans to
pointers you have allocated on your own, otherwise, I don't know how a
copy could be avoided.

2- The complex type matrices in Eigen are still somewhat basic.  I
think they are just a Matrix with data type std::complex (real and
imaginary components are interleaved).  Which for some use cases is
not great.  For example if I am going to do a lot of vector operations
with the real and imaginary part separately, these operations cannot
be easily vectorized (correct me if I'm wrong).  On the other hand it
is true that this storage might be the one used by most external
It has been already a long time since I told Benoit I would write a
wiki page for this discussion, but still haven't.  Sorry for that.

[1] Here you can find the way I'm currently using FFTW in case it can
help (I'm no C++ pro, you have been warned :) ):


On Mon, May 18, 2009 at 4:56 PM, Thomas Capricelli
<orzel@xxxxxxxxxxxxxxx> wrote:
> I agree that fftw is kind of a strandard, it handles every sizes (not only
> power of 2) and every  dimension (not only 1D or 2D FFT).
> I use it on some projects and i'm very happy with it.
> Though of course, the current situation if you want to use both eigen and fftw
> is to convert data back & forth between libraries. This is especially not
> great as complex numbers are involved.
> I would enjoy a fft in eigen, and in an ideal world that would use fftw in the
> backend.
> The way fftw works is the following : you create a "plan" (describing
> dimensions, sizes, type and so on), and you use the plan on data. The idea of
> course is that you create the plan once and use it several times. I am not
> sure if this is good or bad wrt to the use of fftw in eigen. Just wanted to
> mention it.
> greatings;
> Thomas
> In data lunedì 18 maggio 2009 16:34:47, Benoit Jacob ha scritto:
>> Many people who need a linear algebra library, also need a FFT
>> library. In that case, if both libraries use the same data types
>> (read: if they both talk in terms of Eigen:: objects like vectors)
>> then it's extra convenient. They can also share infrastructure for
>> handling various numeric types, for handling fixed-size/dynamic-size
>> with a consistent API... Eigen has all that and so it makes sense to
>> add a small FFT module that integrates well with that. Then, I think
>> that Mark was very clear that FFTW is "much faster", and that's why I
>> think we all agree that a must-have feature is that such optimized
>> libraries may be used as optional backends. The idea is to enjoy their
>> performance while using a uniform Eigen API. Also Mark notes that
>> kissFFT provides more flexibility wrt custom datatypes (like
>> fixed-point).
>> Cheers,
>> Benoit
>> 2009/5/18 Robert Lupton the Good <rhl@xxxxxxxxxxxxxxxxxxx>:
>> > I'm not quite sure why eigen needs an FFT library,
>> > especially when there's a standard (C) library
>> > that everyone uses, FFTW?
>> >
>> > Now, I can see the advantages of a pure-template
>> > C++ library if it's competitive computationally,
>> > so the question that I'd ask is, how do the
>> > kissfft benchmarks look relative to FFTW?
>> >
>> >
>> >                                R
> --
> Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>


Mail converted by MHonArc 2.6.19+