Re: [eigen] resizing in ReturnByValue assignment |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] resizing in ReturnByValue assignment*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Mon, 8 Mar 2010 11:27:13 -0500*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=zT3QcIuUCZRs7Vfvz0aNIeI/T+rL8yZMXfCM8ixdtek=; b=Vixuwf8eTV1Tszg7xUKksn99qfW9huF2rMIvu4X5yDo4iPd+KKEbB6YSz9NKGUKHXF 0pRB+pPeEBc6Hll9x3RQ1CbXt/bYaLYdUVXwVh+wa1n8PEtNWUtHJfhZJBrcnyru8GmF zoL1lc5hEXGBMLMIc84SlGvfSaiRXrmXP27bw=*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=w23C3TOWq75AzoVcFG1d00JkOl1hTgfuQUPi79Sao/Tx1OElNeTqRgc0WXSDl6y2RH +HoBkGnCugYvM899bVmXMzrz7l09xkityI23DKc2lW2LHv25/u17u4cJhSeiC2kZBFlw 3+FYPPqlW1ChfP5hNPTksc1BnHbYbKH4N/zXE=

2010/3/8 Mark Borgerding <mark@xxxxxxxxxxxxxx>: > On 03/08/2010 09:56 AM, Benoit Jacob wrote: >> >> 2010/3/8 Mark Borgerding<mark@xxxxxxxxxxxxxx>: >> >>> >>> My concern is that there is no value added by the initial resize. At >>> best >>> it is a NOOP. At worst, it is a silent performance killer when resizes >>> don't match exactly. >>> >>> In the case of Inverse FFTs, the size of the output depend on the TYPE of >>> output requested. This is NOT available during the construction of the >>> proxy >>> object. It is not available until the evalTo is called. >>> >> >> Strange. We didn't design ReturnByValue for this use case. So your >> problem is deeper: you can't, then, implement rows()/cols() in the >> ReturnByValue-derived class. This means that, calling foo() your >> function returning a ReturnByValue object, you can't support general >> arithmetic expressions like >> >> some_matrix + foo() >> >> as that would require foo() to evaluate into a temporary matrix, but >> it can't know its size (or that would be far too complex logic to >> determine in general from the expression it is being nested into). >> > > Now I see the need for the rows,cols in nested expressions. This need is > not evident in the simple case > some_matrix = foo(); > but > some_matrix = foo()*42; > is nested and requires more knowledge. > > > Actually, the limitation goes well beyond not knowing the size. The > ReturnByValue needs to know the type of temporary to be created first (by > ReturnType typedef). > > This knowledge can be provided by casting to a temporary (see example code > below), but that is not a perfect solution either, since it requires actual > allocation of a temporary, rather than a chainable placeholder. > > // pre-example code > VectorXf real1,real2; > VectorXcf cpx1; > real1.setRandom(len); > FFT<float> fft; > fft.SetFlag( fft.HalfSpectrum ); > fft.fwd(cpx1,real1); > > // EXAMPLE CODE > fft.inv(real2,cpx1); // #1 original style calling convention, destination > is first arg > real2 = fft.inv(cpx1); // #2 this succeeds, but has an extra resize in > DenseStorageBase::operator= > real2 = fft.inv(cpx1)*42; // #3 this fails to compile -- cannot infer > result type > real2 = VectorXf(fft.inv(cpx1))*42; // #4 this succeeds, but has extra > resize from #2 plus a heavyweight temporary object > > The fact that #3 does not work and #4 is not efficient does not detract from > how much prettier #2 is compared with #1. I very much like the style of > ReturnByValue. I refuse to give up on it yet for Eigen::FFT. Why don't you template your inv() method in the destination scalar type? Like: real2 = fft.inv<double>(cpx1); vs. cpx2 = fft.inv<complex<double> >(cpx1); This would be in line with our general design decision of doing almost no implicit casting. Or another option: since these are 2 different notions why not 2 different methods? real2 = fft.realInverse(cpx1); cplx2 = fft.cplxInverse(real1); of course you could still keep inv() for the case where the destination type is identical to the scalar type... > > Option 1. > Is there a proxy matrix type that would allow one to explicitly name the > type of matrix expected, but defer its actual creation until later? no... that's complicated! > > Option 2. > Alternately, I propose a companion, simpler, ReturnByValue class that > retains most of the syntactic benefits of the ReturnByValue > , but cannot be nested in an expression (unless explicitly casted). Perhaps > a specialization of ReturnByValue would provide the simpler proxy I need. But it would be confusing for the user that certain ReturnByValue pseudo expressions can be nested, and some can't. Benoit > > -- Mark > > >

**Follow-Ups**:**Re: [eigen] resizing in ReturnByValue assignment***From:*Gael Guennebaud

**References**:**[eigen] resizing in ReturnByValue assignment***From:*Mark Borgerding

**Re: [eigen] resizing in ReturnByValue assignment***From:*Hauke Heibel

**Re: [eigen] resizing in ReturnByValue assignment***From:*Benoit Jacob

**Re: [eigen] resizing in ReturnByValue assignment***From:*Mark Borgerding

**Re: [eigen] resizing in ReturnByValue assignment***From:*Benoit Jacob

**Re: [eigen] resizing in ReturnByValue assignment***From:*Mark Borgerding

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] resizing in ReturnByValue assignment** - Next by Date:
**[eigen] pb with doc generation** - Previous by thread:
**Re: [eigen] resizing in ReturnByValue assignment** - Next by thread:
**Re: [eigen] resizing in ReturnByValue assignment**

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