Re: [eigen] FFT for Eigen

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

actually you can already do all you asked for:

> 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

two options:
1 - extend Matrix using the "plugin" mechanism: the additional ctor
will copy the data.
2 - implement an expression storing a ref to the two vectors so that
they can be seen as a single vector of complex

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

this should already work.

> - 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();

this should work too.


cheers,
Gael.

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