|Re: [eigen] Inverse of an array through .matrix()|
[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]
2010/6/27 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
Thanks for the heads up, i had forgotten that this was legal. Makes sense!> On Sun, Jun 27, 2010 at 2:21 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> 2010/6/27 Carlos Becker <carlosbecker@xxxxxxxxx>:
>>> Hi everyone again. I am still writing some examples for the tutorials and
>>> came out with the following piece of code:
>>> #include <Eigen/Dense>
>>> #include <iostream>
>>> using namespace Eigen;
>>> using namespace std;
>>> int main()
>>> ArrayXXf m(2,2);
>>> m << 1,2,3,4;
>>> // this compiles OK
>>> MatrixXf ww = m.matrix().inverse();
>>> // ERROR: no matching function for call to
>>> ‘Eigen::TriangularView<Eigen::Matrix<float, 33331, 33331, 0, 33331, 33331>,
>>> ArrayXXf xx = m.matrix().inverse();
>> That can't work: m.matrix().inverse() wants to return a matrix
>> _expression_, so you can't assign that to an array _expression_. This
>> ArrayXXf xx = m.matrix().inverse().array();
> on the other hand:
> MatrixXf m1, m2;
> ArrayXXf a = m1 + m2;
> is legal and works fine.
> What is not allowed is to mix matrix and
> array in the right and side (e.g., array+matrix is forbidden). What
> happens here is that .inverse() returns a proxy object which is
> compiled as:
> (the function compute_the_inverse_into does not exist, it is just to
> get the idea)
> => we are mixing matrix and arrays.
> However, I think it is fine that this example does not compile,
> because it does not make sense to do pure linear algebra on arrays.
>> Notice that eigen3's .matrix() and .array() are very different from
>> eigen2's .cwise(): while .cwise() was just a prefix for the next
>> method call, .matrix() and .array() are permanently switching your
>> _expression_ between the Matrix and Array worlds.
>> Please don't mention .inverse() in the Array page, as
>> - it is nontrivial linear algebra so should not be mentioned before
>> the linear algebra page
>> - implementation-wise it is very nontrivial and special, whence the
>> weird error messages that you got.
>>> I just wanted to ask if this is the way it should work or not, since I
>>> supposed that the last line should be fine.
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|