Re: [eigen] FFT for Eigen

[Ricard Marxer Piñón <email@xxxxxxxxxxxxxxxx>]

I'm sorry I have brought up all this, you were all right that this
discussion was quite orthogonal to the FFT stuff.

But since we are onto it.  I'm not defending one storage or the other,
actually I'm pretty convinced with the arguments about interleaved
being more compatible and separate storage not being a big win.  In
any case I'm sure more expertise than mine is needed for this
decisions.

Here are some of the use cases I bumped into:
- I would like to create a complex vector given a vector of reals for
the real part and a vector of reals for the imaginary part.
MatrixComplex(myRealVec, myImagVec);  // here myRealVec and myImagVec
would be both vectors of reals

- Separately assigning real and imaginary parts, using Eigen vectors.
myVec.real() = myRealVec;
myVec.imag() = myImagVec;

- I need to add the real part of a matrix with the reverse of the real
part of another matrix.
myVec.real() = myVec1.real() + myVec2.real().reverse();

It is probable that these are quite specific use cases, and that they
could be done by iterating over the coefficients by hand (it is how I
do it now).

just some thoughts.
ricard

On Tue, May 19, 2009 at 8:02 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> On Tue, May 19, 2009 at 7:07 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>  i'd be (pleasantly) surprised if this could be done without
>> very big (not worth it) changes in Eigen....
>
> definitely !
>
> Anyway, I just wanted to add that such a storage scheme would also be
> optimal to vectorize code dealing with many Vector3 or other non easy
> to vectorize data types....
>
> Gael.
>
>> Benoit
>>
>> 2009/5/19 Rohit Garg <rpg.314@xxxxxxxxx>:
>>> This is probably not a good idea. I believe that they should be stored
>>> in the interleaved format. I'll be happy to pitch in with SSE2/3
>>> intrinsics code for complex multiplication, division if neccessary. I
>>> think we should go the standard way as many other libraries and
>>> std::complex use it.
>>>
>>> So far, on this discussion, the only reason for not using the
>>> interleaved format that I have seen is that it is tricky to multiply
>>> using that. Is there any other reason?
>>>
>>> IMHO, we shouldn't lose compatibility with ~90% of other complex
>>> libraries/formats just to simplify multiplication.
>>>
>>> On Tue, May 19, 2009 at 5:49 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>>> I can believe that this is probably a very efficient storage scheme.
>>>> We could offer this as an option if really it's not too hard to
>>>> implement (i didn't start thinking about this).
>>>>
>>>> The default should remain the current for many reasons, but as an
>>>> option why not.
>>>>
>>>> Cheers,
>>>> Benoit
>>>>
>>>>
>>>> 2009/5/19 Márton Danóczy <marton78@xxxxxxxxx>:
>>>>>> I concur: I don't think that it would be very useful to have complex
>>>>>> matrices with the real and imaginary parts stored separately. Most
>>>>>> operations -- and the more costly ones -- would run slower in such a
>>>>>> scheme. The basic issue here is memory locality.
>>>>>
>>>>> What about storing them packet by packet? That is, in case of floats,
>>>>> four real parts followed by four imaginary parts. That would not be
>>>>> too hard to implement and vectorization of component-wise operations
>>>>> would be trivial. And I think even FFTW can handle that using the guru
>>>>> interface, by setting up a split fft plan with a stride of
>>>>> 2*packetsize.
>>>>>
>>>>> Marton
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Rohit Garg
>>>
>>> http://rpg-314.blogspot.com/
>>>
>>> Senior Undergraduate
>>> Department of Physics
>>> Indian Institute of Technology
>>> Bombay
>>>
>>>
>>>
>>
>>
>>
>
>
>



-- 
ricard
http://www.ricardmarxer.com
http://www.caligraft.com