Re: [eigen] Being able to use Eigen::Map<Eigen::Matrix< ... > > everywhere you can use a Eigen::Matrix

[Jitse Niesen <jitse@xxxxxxxxxxxxxxxxx>]

On Mon, 18 Feb 2013, Malcolm Reynolds wrote:

> First post to this list, apologise if this is something really obvious but
> I'm having a bit of trouble using Eigen::Map. As I understand, it allows me
> to declare an Eigen matrix which reuses some memory already allocated (in my
> cases I'm gettin the data pointer from Numpy matrices), and then use this
> value everywhere I can use a regular Eigen matrix?

All Eigen functions are written such that a Map can be used in the same 
way as a regular Eigen matrix. If you write your own functions, you may 
need to do something extra if you want your own functions to accept a Map 
instead of a regular matrix. This is explained at

http://eigen.tuxfamily.org/dox-devel/TopicFunctionTakingEigenTypes.html


> I have a function which I'd already written with the signature
>
> predict(const MatrixXd & features, MatrixXd * const labels_out)
>
> following the good practice (afaik) of using const refs for parameters that
> don't need to be modified, and pointers otherwise. Anyway I'd like to pass
> in Eigen::Maps for both arguments of this function, as I'm writing a python
> interface for my library. [...]

You are calling this function like:

Map<MatrixXd> mapFeatures = ...;
Map<MatrixXd> mapLabels = ...;
predict(mapFeatures, &mapLabels);

For the first argument, the compiler converts the Map<MatrixXd> into a 
MatrixXd by introducing a temporary object, so it is as if you had 
written:

MatrixXd tempObject(mapFeatures);
predict(tempObject, &mapLabels);

This does what you want, but it induces a performance penalty because when 
tempObject is constructed, all the data from mapFeatures is copied into 
the matrix tempObject.

However, this does not work for the second argument. If the compiler were 
to introduce another temporary object and pass that as the second 
argument, then predict() would change the data in the temporary object and 
not in mapLabels.

The solution is to have predict() accept arguments of the template type 
MatrixBase, as explained in the link I included above. If you still have 
questions after reading that, do not hesitate to ask. Any suggestions on 
how we can improve the explanations would be very welcome.

Good luck,
Jitse