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*: Ricard Marxer Piñón <email@xxxxxxxxxxxxxxxx>*Date*: Tue, 19 May 2009 21:13:38 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=5bFtzjADUyTqc0WnKCCpccKbIt/R/7tuugO5enT49XQ=; b=r/2VH4eg2BVQ7Xzk6b79QrzWZ0ifwlay9gyZ3uAdxfQlRD0/OWUaIUHeSawTZ6x/Ry J6Czrf/dj9xHK+Lcz4l1O9s485aZ34HT+ctrNcFlvMNtfJxCqxxFGSQkl3nFGhvr3As3 UI5kRQa1mmsAvoorAJCLX22E58jLYnH+gSgjk=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=UvUPe7dehDX6sozAeJ7HW4wYg5HoH4LPvAy5JuGIxGof5AYGV3AccgTLtouikW7QRa 9wGRCVPO6OCXfcCaETmWjmcewDQXjNgWda++4aZiE3PDA0NkMtzLMGv1ngg+tXsBdhEi rene5fCqajJGnDYG4bWB+qiaaK7qUgmAWiIuU=

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

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

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

**Re: [eigen] FFT for Eigen***From:*Thomas Capricelli

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Submitting patch to add pkg-config support** - Next by Date:
**Re: [eigen] Submitting patch to add pkg-config support** - 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/ |