|Re: [eigen] How to resize a partially fixed matrix|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] How to resize a partially fixed matrix
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Wed, 24 Jun 2009 20:18:32 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=sC0M+jyWqYkrfTxNAP1ayMc4DsvUUBJSdlZkF8IGRkw=; b=LsW7CQNMmRnXvqmq17ybHhiVg8G8YdHSC/RqAkYnLMsWLUtgcxfMpeyo1t484FBaTv wKT8QV91COAMyLWufnzmXaOqBxjNhFW+CEWJwWleZEHxdlksHN3f1smlNz9ylyRtX1us 4whhlEZhE+F0vXOjFtP6rhZcERaoNQtcmF51s=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=G8CDc2kMLysJc4tubtI1+8ZJBBgNPK/0V68lCBg/vxLTwRoBny9PL2FRG9ALAN30NP WXn8ncGeI0tbB6tQNBcdlIUnvTjKw3t6Ya8W4B+vMF25nteBydK+CsdDegCoGxIOfEhu sGyIdhmxRpktK0UMl1ZKpS8e5wXDA7gX05VeY=
2009/6/24 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> On Wed, Jun 24, 2009 at 6:06 PM, Markus Fröb<grey_earl@xxxxxx> wrote:
>> 24.06.09 17:55:10 "Benoit Jacob" <jacob.benoit.1@xxxxxxxxx>
>>> 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....
>> 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 ...
> same here.
Here is the current code:
inline void resize(int size)
if(RowsAtCompileTime == 1)
m_storage.resize(size, 1, size);
m_storage.resize(size, size, 1);
As you can see, we forgot(!) so far to add the assertion!
Here, the assertion would be :
ei_assert(SizeAtCompileTime == Dynamic || SizeAtCompileTime == size);
Here is a way to implement the proposed change:
inline void resize(int size)
if(RowsAtCompileTime != Dynamic)
m_storage.resize(size*RowsAtCompileTime, RowsAtCompileTime, size);
m_storage.resize(size*ColsAtCompileTime, size, ColsAtCompileTime);
The question that's up for discussion now is: what assertion to add here?
As far as I can see, there is no good choice. Indeed, we want this to work:
but then we also want this to work:
Indeed, it could happen that the user notices that in a certain
situation the first dimension is already known to be 3 at compile
time, but he still wants to call on such a matrix a generic function
that he wrote for the general case!
This has been a design principle for a long time in Eigen and I think
that we should stick with it:
"Making a dynamic dimension fixed (keeping the same value) should work."
But as discussed above, the proposed resize(int) change is
incompatible with that.
Otherwise, I'll add the assert in resize(int) and update the
documentation with what Tim Hutt proposes.