Re: [eigen] Being able to use Eigen::Map<Eigen::Matrix< ... >

Hi Jitse,

Thanks for your quick answer - excellent explanation. The way that C++ can implicitly create temporary objects is definitely something I need to read up more on. One final question, why do you recommend I use MatrixBase rather than the more general DenseBase or EigenBase? Will using the more general template types infer a performance hit?

The only suggestion I would have for the documentation is maybe adding some note to the "Mapping external arrays" section of http://eigen.tuxfamily.org/dox-devel/group__QuickRefPage.html as that is the main page I was using for reference. A little note there saying "to use Maps in place of Matrices, please see considerations in <link>", with the link pointing to the TopicFunctionTakingEigenTypes.html page, would be a good idea I think.

Thanks again!

Malcolm

On Tue, Feb 19, 2013 at 10:30 AM, Jitse Niesen <jitse@xxxxxxxxxxxxxxxxx> wrote:

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