Re: [eigen] conservative resize ...

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

hi,

what about the following:

- we keep only the two simple conservativeResize() overloads taking
only size arguments

- we add one template overload:

template<typename OtherDerived>
void conservativeResize(const MatrixBase<OtherDerived>& other);

resizing *this to match the sizes of other, and filling the extended
parts from the respective parts of other. Typical use cases:

Mat m;

// ...

// extend with 0 (similar to the current m.conservativeResize(r, c, true))
m.conservativeResize(Mat::Zero(r,c));

// extend with x:
m.conservativeResize(Mat::Constant(r, c, x));

// and some more complex examples:
m.conservativeResize(Mat::Identity(r,c));
m.conservativeResize(Mat::Random(r,c));

The drawback is that it makes the "extend with zeros" a bit more verbose.
Alos, perhaps conservativeResize() is not a very good name for this
overload, but what do you think about this idea ?

cheers,
gael.



On Mon, Sep 7, 2009 at 1:52 PM, Hauke Heibel<hauke.heibel@xxxxxxxxxxxxxx> wrote:
> On Mon, Sep 7, 2009 at 1:34 PM, Márton Danóczy<marton78@xxxxxxxxx> wrote:
>> You're right, initializing a matrix after resizing should suffice, if
>> it is not slower than doing both in one step.
>
> It is possible and would probably be even faster - if done correctly.
> I am just saying this because you would need to take care of
> initializing only those parts of the matrix which are yet
> uninitialized. At the moment, when pre-initializing with zeros, the
> parts of the old and resized matrices that overlap are accessed twice.
> Once for initializing with zeros and a second time to copy the old
> values.
>
> @Benoit, ExtendByZero is fine. I am just wondering, was there a
> particular reason for making NoChange_t a struct? Should we follow the
> same strategy to ExtendByZero?
>
> - Hauke
>
>
>