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

[Markus Fröb <grey_earl@xxxxxx>]

> 24.06.09 17:55:10 "Benoit Jacob" <jacob.benoit.1@xxxxxxxxx>
> 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;
> m.resize(4);
> 
> 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....
> 
> Benoit

I vote for a failed assertion here and still do the change otherwise.
The single-argument resize already tests if it's a vector, no?
So I think the change shouldn't be too big ...

______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de