Re: [eigen] FFT for Eigen |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] FFT for Eigen*From*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Tue, 19 May 2009 21:37:13 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Uj1fuaz9nBinLbp/kRAutU2B93i4hP6Val7Dbz/otlg=; b=I2h0bx4bTgPGrHYmG+osqvkcZ2cZrBSh7ISJgJb/Q0ScOxwAQCfoaZWAPWHPU58Zoa BCPXPmIp3uZjczScRN9/nqtEyOyr4cf3BhMqVrmKrdRTMSxnqxmSBCpFeyBfkysNPt56 8pZp5ieMWK0atw6UHyTZAuKfCF5HaFHrHQyGQ=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=B3UByZT9gL94IRo/LjZ38reT7IrdOGvrtT0aAt0uAIUIIEfOxz2upv37RoUaFTMYLg 5jhPpd7EQ7OV9ZD1jq5Cc2EAYKn5TCeAHKL0icy6gRiJ3+wFPoRUBSdrkelcQMZPZ8Oa fA//SJ+sAz84hhIw/T4GuMxdEQbzcGDd9LMas=

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

**Follow-Ups**:**Re: [eigen] FFT for Eigen***From:*Benoit Jacob

**References**:**[eigen] FFT for Eigen***From:*Mark Borgerding

**Re: [eigen] FFT for Eigen***From:*Ricard Marxer Piñón

**Re: [eigen] FFT for Eigen***From:*Mark Borgerding

**Re: [eigen] FFT for Eigen***From:*Benoit Jacob

**Re: [eigen] FFT for Eigen***From:*Márton Danóczy

**Re: [eigen] FFT for Eigen***From:*Benoit Jacob

**Re: [eigen] FFT for Eigen***From:*Rohit Garg

**Re: [eigen] FFT for Eigen***From:*Benoit Jacob

**Re: [eigen] FFT for Eigen***From:*Gael Guennebaud

**Re: [eigen] FFT for Eigen***From:*Ricard Marxer Piñón

**Messages sorted by:**[ date | thread ]- Prev by Date:
**packetwise complex format for vectorization, was Re: [eigen] FFT for Eigen** - Next by Date:
**Re: [eigen] FindEigen2.cmake** - Previous by thread:
**Re: [eigen] FFT for Eigen** - Next by thread:
**Re: [eigen] FFT for Eigen**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |