Re: [eigen] resizing in ReturnByValue assignment

[ Thread Index | Date Index | More Archives ]

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.

I did run the regression tests with and without the initial resize. The same tests passed and failed in both cases. This would seem to support my theory that most implementations of ReturnByValue<Derived>::evalTo resize the destination matrix.

Can anyone come up with a concrete example of why resizing is necessary *before* calling evalTo?

-- Mark

Benoit Jacob wrote:
2010/3/8 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
Resize should be almost like a nullary op when the destination object
already has correct size - if it is not, this is a bug. The advantage
of having the assignment operator doing the resizing is that you
cannot forget about it when implementing ReturnByValue since you
simply don't need to take care of it.
I admit that the FFT ReturnByValue has a bug. The problem is the bug compiles correctly and gives the right answer. This is the hardest kind of bug to track down. By removing that initial resize, the path to using ReturnByValue is less error-prone.

Regarding the confusion about rows()/cols() you have to think of
ReturnByValue as your actual result and thus this object should also
be reflecting your result's properties as e.g. rows() and cols().

exactly... think for example of the case where you are using your
returnByValue object in some expression that wants to evaluate it as a
temporary (as is automatic when nesting ReturnByValue into a bigger
expression)... then it needs to know the dimensions of the temporary
matrix to create!
Won't this created matrix then be the argument to evalTo? It can assume responsibility for resizing.


Hope that helps...

- Hauke

On Mon, Mar 8, 2010 at 2:33 PM, Mark Borgerding <mark@xxxxxxxxxxxxxx> wrote:
First, the praise: I really like the ReturnByValue paradigm.  It is
syntactically cleaner than using the destination-as-an-argument. It bends
the rules of c++ somewhat and allows one to overload/specialize based on
return type.  Very cool.

Next, my confusion:
Eigen::FFT fwd,inv now uses ReturnByValue but it elicits an unnecessary
resize in some conditions (eliminating the advantage of the ReturnByValue
proxy object). This is my bug -- I thought the rows() and cols() referred to
the source matrix. They refer to the destination.   I can fix this by
duplicating the logic required to decide the output size from the FFT fwd
and inv functions, but I'm lazy and I don't like doing work I don't need to
Why does DenseStorageBase::operator=( ReturnByValue ) call resize() first?
  (defined in Eigen/src/Core/DenseStorageBase.h around line 300)
Why not just require the ReturnByValue subclass evalTo method resize the
destination as needed?

Removing the resize also simplifies the implementation slightly by
eliminating the need for rows() and cols() to be defined in the
ReturnByValue subclass.

Am I missing something?

-- Mark Borgerding

Mail converted by MHonArc 2.6.19+