I have a pretty simple to replicate error that I previously thought was valid code. This results in an EIGEN_ASSERT from "rows() === other.rows() and cols() === other.cols()":

Code: Select all

#include <Eigen/Dense>
int main() {
  Eigen::MatrixXd x(5, 2);
  const Eigen::Ref<const Eigen::VectorXd>& y = x.row(0);
};


Now this isn't what my code original code looked like (rather I had a function that was accepting a const Eigen::Ref<const Eigen::VectorXd>&), but this is the minimum reproducing code. Humorously enough, when I change the y dimension to 1, it works perfectly fine:

Code: Select all

Eigen::MatrixXd x(5, 1);
const Eigen::Ref<const Eigen::VectorXd>& y = x.row(0);


Perhaps less strange, is that when I change the type qualifier, I get a compiler error "STORAGE_LAYOUT_DOES_NOT_MATCH":

Code: Select all

Eigen::MatrixXd x(5, 2);
const Eigen::Ref<Eigen::VectorXd>& y = x.row(0);


All of this has kind of undermined my understanding of Eigen::Refs and their use-case as generic function parameters that don't produce temporary values. The even stranger part is that we have const Eigen::Ref<const Eigen::VectorXd>& littered through our code base as a function parameter, yet we've only hit this road block today. Is my fundamental issue that I can't use a Vector Ref of a Matrix? Is there a way for me to write my functions generically so that both of these invocations are valid?

Code: Select all

Eigen::VectorXd vector(5);
Eigen::MatrixXd matrix(5, 1);

someFunction(vector);
someFunction(matrix.row(0));


Thank you in advance!

It looks like every other place we use const Eigen::Ref<const Eigen::VectorXd>& we're actually referring to:

a column of an Eigen::MatrixXd
an actual Eigen::VectorXd

That, along with the fact that this compiles and works:

Code: Select all

#include <Eigen/Dense>

int main() {
  Eigen::MatrixXd x(5, 2);
  const Eigen::Ref<const Eigen::VectorXd>& y = x.col(0);
}


leads me to believe that I've answered my own question: that storage order matters http://eigen.tuxfamily.org/dox-devel/gr ... rders.html.

Indeed, storage layout does matter. If you want more flexibility at the cost of less performance you can enable non-contiguous vector storage by allowing an inner stride:

Ref<VectorXd,0,InnerStride<> > vec(mat.row(i));