Re: [eigen] How to resize a partially fixed matrix

[ Thread Index | Date Index | More Archives ]

2009/6/24 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 2009/6/24 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> On Wed, Jun 24, 2009 at 10:37 AM, Helmut
>> Jarausch<jarausch@xxxxxxxxxxxxxxxxxxx> wrote:
>>> Hi,
>>> I wonder how I can resize a matrix where one of the dimension is fixed,
>>> like
>>> Matrix<double,4,Eigen::Dynamic> MS_BC;
>>> ....
>>> MS_BC.resize(5); //  this fails
>> yes it fails because resize(int size) is for vector only.
>>> but this works
>>> MS_BC.resize(4,5);
>>> but it's not logical?
>> well that depends. First of all it is very clear that
>> MS_BC.resize(4,5) *must* work. Now about allowing resize(int size) to
>> work on such matrices why not. I guess that the main use case for such
>> matrices is to use a Matrix to store a collection of small vectors,
>> and so the matrix can be seen as a std::vector, and so having
>> resize(int size) working makes sense. On the other hand, in that case
>> the parameter "size" will mean either the number of rows or the number
>> of cols depending on the context that is not very nice. So there are
>> pro and cons, but eventually I'm 51% ok to extend resize to partially
>> dynamic matrices.
> Same here. It's the second time in a few days that people ask for
> something like that, so i'd be OK to do this just to make our API
> match what people expect. The "list of vectors" argument is good too.
> And after all it doesn't look that dangerous.
> But then we should do the same for other functions, for consistency:
> - at least other Matrix methods like constructors, setZero...
> - static MatrixBase methods like Zero...
> more generally all methods that take size parameters!

I tried to do that change and now I think that it's very nontrivial:
not sure anymore that it's a good move!
Here's what makes me change my mind. Look at what happens when you do:

Matrix<float,3,4> m;

How to interprete this? Should this be a NOP or a failed assertion?
There are many such issues in Matrix.h alone and I am afraid that any
way to allow that will result in a much more complex Matrix.h and less
consistent API....


Mail converted by MHonArc 2.6.19+