> 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.