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*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Mon, 8 Mar 2010 22:35:24 +0100*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 :from:date:message-id:subject:to:content-type; bh=eY7TijljmhbGg8AYs3xS27rw4j9CZYlNIIfuFoPX+As=; b=HFvWmPCcU/Z0GqxtLr7Ev+ULbq+Jw+jcnF/rKtU2QUiYx5jspT5nYCRg6lalp13hPS mupm4CJrR2K8/Xg7ig5afkMS0+KJ7CzWGQir6SR0JWbYdlAjfMFvgsB1gCbmsBL7sRzU vOCEEhWo+kUrs68SFOFsF4YmuuWVbBmtiCz2U=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=f7sJbW72FYc2N6Gn++4wa8qTm87oI0wFnMpgEUfI77sU8v+0M4CNYyoe3HFdjNq2u3 nReYOtyZOCmA0zYPlA+b5i6SjZEZMDJucqiHGo8H4Z7twfQk9JOQgF3NmXY245bYdC1D cxw7m+g5ImuSNr7K7213282ZgG99o7BeTVTM8=

On Mon, Mar 8, 2010 at 5:27 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:

I second that proposal. As a bonus it also improves the readability => no need to know precisely the types of dest to understand what's going on...

gael

Why don't you template your inv() method in the destination scalar type? Like: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.

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

I second that proposal. As a bonus it also improves the readability => no need to know precisely the types of dest to understand what's going on...

gael

of course you could still keep inv() for the case where the

destination type is identical to the scalar type...

no... that's complicated!

>

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

But it would be confusing for the user that certain ReturnByValue

>

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

pseudo expressions can be nested, and some can't.

Benoit

>

> -- Mark

>

>

>

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

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] again msvc inlining...** - Next by Date:
**Re: [eigen] Propagating Max*AtCompileTime template parameters to decompositions** - Previous by thread:
**Re: [eigen] resizing in ReturnByValue assignment** - Next by thread:
**[eigen] Eigen/src/Core/arch/Default/Settings.h not included in install target**

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