Hi Vincent, Andre,
I think Hybrid Matrix is better name because it means fix size on stack
and dynamic matrix size.
Names are quite subjective. Presumably you are used to blaze terminology
where static and dynamic matrix are implemented in distinct classes, so
that the term hybrid makes sense. Before this conversation, I would have
been clueless as to what a HybridMatrix could be.
Anyway, if you are using c++11 or later, you can declare the following, *in
the Eigen namespace*:
*template<typename Scalar, int r, int c>using HybridMatrix = Matrix<Scalar,
Dynamic, Dynamic, 0, r, c>;*
and use HybridMatrix the same way as in blaze:
*HybridMatrix<int, 6, 8> A(3,4);*
You can even declare the following to get as close as possible to the blaze
object
*template<typename Type, int M, int N, int SO = RowMajor>using HybridMatrix
= Matrix<Type, Dynamic, Dynamic, SO, M, N>;*
however there are not so many cases where the storage order matters, and I
would make the (educated?) guess that Eigen is better optimized for
column-major matrices.
or maybe a different term called "Dynamic_on_stack" to make it clearer ?
I can't speak for the devs, but the Eigen philosophy seems to be that all
dense matrices are (specialized) instances of the Matrix class,
irrespective of the storage scheme, to avoid burdening casual users with
the distinction between static and dynamic storage. The distinction between
fix- and dynamic-size matrices is easy enough to grasp and use. As for the
"hybrid" case, it is more meant for power users, and for very specific
cases where the upper bounds on the number of rows and column can be known
at compile time and are small enough (be careful that Eigen defines a limit
on the size of a buffer allocated on the stack - 128kb by default - with
EIGEN_STACK_ALLOCATION_LIMIT). I do agree that *Matrix<double, Dynamic,
Dynamic, 0, 6, 4>* is not very clear but I would argue that the power user
writing that should use aliases with application-meaningful names.
Best regards,
Adrien