Re: [eigen] How to resize a partially fixed matrix |
[ Thread Index |
Date 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: Thu, 25 Jun 2009 00:48:27 +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=/7OprqoaRfbxKZqrNsh898yADX84i92sqm9lHbGxsOY=; b=Gj4IT6LjKgFFil1kylLWZc+m3eTbCWyq9uHs4ep1EINafDklaHh5p7F9ZhP8JnQMlS Fa0MqpzaCLI1SPyZg7Y+ruMZgjG+ME7GFd8PZJ8DV4N/FUz/QGJIfOeA4UdJDjbPxqCY H2wQUdhPR4CfcOl2+bcjtDqc1CnbjEr8xW3J8=
- 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=K2TB+p/DqPScT36pj/RN206xfQaSh+ks/2YsWkGxyzoxhGGzoMJGy0GNWjl7xIt6Rq jQsk4c9sGKPkqUSHHKo3V4bEvxlWC0vXb05gqxW2EpWiAp61I3jNjlROMUMQ87QRXpW3 iUo807/7pMxsP/PpvAuAZjk8CkjG9gWZsSPhI=
2009/6/24 Tim Hutt <tdhutt@xxxxxxxxx>:
> 2009/6/24 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>> 2009/6/24 Markus Benjamin Fröb <grey_earl@xxxxxx>:
>>>> Matrix<float,Dynamic,2> m;
>>>> m.resize(3);
>>>>
>>>> but then we also want this to work:
>>>>
>>>> Matrix<float,3,2> m;
>>>> m.resize(3);
>>>
>>> I don't see why the second case should work, since a) it's ambigous what the
>>> user wanted and b) in the documentation it says explicitly "Of course, fixed-
>>> size matrices can't be resized."
>>
>> Yes, that's what I meant, sorry if I was unclear, we were wondering if
>> A should be allowed and I said "if we want to allow A then we also
>> want to allow B", where B is impossible, conclusion: we can't allow A.
>
> I see what you mean. You're saying if you have code like this:
>
> Matrix<double, Dynamic, 3> m;
> // ... lots of code ...
> m.resize(10, 3);
>
> And then for some reason later you want to make m fully dynamic then
> you only have to change the declaration:
>
> Matrix<double, Dynamic, Dynamic> m;
> // ... lots of code ...
> m.resize(10, 3); // Still works.
>
> In which case the trade-off is:
>
> Pros: Constructor and resize are more logical, code is less redundant.
> The code shows that the matrix isn't fully dynamic (i.e. you might
> accidentally try m.resize(10, 4) in the code above.
> Cons: Have to change code if you change matrices from partially to
> fully dynamic.
What you say makes sense but what I really had in mind (if you want to
know) is the case where we have code written for partially-dynamic
matrices and some day we want to use it on fixed-size matrices. This
is where the distinction between AT_MOST_ONE_DYNAMIC_DIM and
EXACTLY_ONE_DYNAMIC_DIM matters, and this is the example that I had in
mind when I said that even EXACTLY_ONE_DYNAMIC_DIM didn't cut it.
So suppose that we had allowed resize(int) on partially dynamic matrices, like:
int x = 4;
Matrix<double, Dynamic, 3> m;
// ... lots of code ...
m.resize(x);
And then some day we want to apply this to a fixed-size matrix m
(because we happen to fully know its size at compile time, and we want
to take advantage of this for better speed) then we would like to only
have to change the declaration, as follows, but unfortunately there's
no sane way to allow resize(int) in that case:
int x = 4;
Matrix<double, 4, 3> m;
// ... lots of code ...
m.resize(4); // BOOM! doesn't work.
Thus, in order to get an API that seamlessly specializes in the
fixed-size case, we can't allow resize(int) for partially dynamic
matrices.
Benoit