Re: [eigen] conservative resize ...

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


Hi,

In your initial interface, allowing to extend by any arbitrary value,
I don't think there was much of a use case for extending by a value
other than zero. So I don't think it's a loss at all, not to have this
feature. I like your current API,

void conservativeResize(int rows, int cols, bool init_with_zero = false)

How about defining a constant like

const bool ExtendByZero = true;

so that the user's code looks more explicit?

Also, I don't know if the performance difference matters here, but if
you want to get rid of the "if" you can always do a trick like
NoChange_t. The drawback though is that it means even more overloads
of conservativeResize.

Benoit

2009/9/3 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> Hi,
>
> just a short question regarding my recent commit for conservative
> resizing. I added an option to allow the user to set the part by which
> a matrix might be extended to zero - currently via a boolean.
> Initially I wanted to offer the ability to pass the scalar value
> explicity which lead to problems, in particular for integer matrices.
>
> My initial intended interface was somethink like:
>
> void conservativeResize(int,int) // matrices with uninitialized memory
> void conservativeResize(int,int,Scalar value) // matrices with new
> memory set to value
> void conservativeResize(int) // vectors with uninitialized memory
> void conservativeResize(int,Scalar value) // vectors with new memory set to zero
>
> Here, the last and first definitions obviously clash when Scalar is int.
>
> Do you have any proposal how to circumvent this problem. Do we need
> the uninitialized version at all for conservativeResizing? Any use
> case for this?
>
> - Hauke
>
>
>



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