2010-06-25 22:04:35 +08:00
namespace Eigen {
Big changes in Eigen documentation:
- Organize the documentation into "chapters".
- Each chapter include many documentation pages, reference pages organized as modules, and a quick reference page.
- The "Chapters" tree is created using the defgroup/ingroup mechanism, even for the documentation pages (i.e., .dox files for which I added an \eigenManualPage macro that we can switch between \page or \defgroup ).
- Add a "General topics" entry for all pages that do not fit well in the previous "chapters".
- The highlevel struture is managed by a new eigendoxy_layout.xml file.
- remove the "index" and quite useless pages (namespace list, class hierarchy, member list, file list, etc.)
- add the javascript search-engine.
- add the "treeview" panel.
- remove \tableofcontents (replace them by a custom \eigenAutoToc macro to be able to easily re-enable if needed).
- add javascript to automatically generate a TOC from the h1/h2 tags of the current page, and put the TOC in the left side panel.
- overload various javascript function generated by doxygen to:
- remove the root of the treeview
- remove links to section/subsection from the treeview
- automatically expand the "Chapters" section
- automatically expand the current section
- adjust the height of the treeview to take into account the TOC
- always use the default .css file, eigendoxy.css now only includes our modifications
- use Doxyfile to specify our logo
- remove cross references to unsupported modules (temporarily)
2013-01-05 23:37:11 +08:00
/** \eigenManualPage TutorialMatrixClass The Matrix class
2010-06-25 22:04:35 +08:00
Big changes in Eigen documentation:
- Organize the documentation into "chapters".
- Each chapter include many documentation pages, reference pages organized as modules, and a quick reference page.
- The "Chapters" tree is created using the defgroup/ingroup mechanism, even for the documentation pages (i.e., .dox files for which I added an \eigenManualPage macro that we can switch between \page or \defgroup ).
- Add a "General topics" entry for all pages that do not fit well in the previous "chapters".
- The highlevel struture is managed by a new eigendoxy_layout.xml file.
- remove the "index" and quite useless pages (namespace list, class hierarchy, member list, file list, etc.)
- add the javascript search-engine.
- add the "treeview" panel.
- remove \tableofcontents (replace them by a custom \eigenAutoToc macro to be able to easily re-enable if needed).
- add javascript to automatically generate a TOC from the h1/h2 tags of the current page, and put the TOC in the left side panel.
- overload various javascript function generated by doxygen to:
- remove the root of the treeview
- remove links to section/subsection from the treeview
- automatically expand the "Chapters" section
- automatically expand the current section
- adjust the height of the treeview to take into account the TOC
- always use the default .css file, eigendoxy.css now only includes our modifications
- use Doxyfile to specify our logo
- remove cross references to unsupported modules (temporarily)
2013-01-05 23:37:11 +08:00
\eigenAutoToc
2010-06-27 02:00:00 +08:00
2010-07-06 17:48:25 +08:00
In Eigen, all matrices and vectors are objects of the Matrix template class.
2010-06-25 22:04:35 +08:00
Vectors are just a special case of matrices, with either 1 row or 1 column.
2010-07-06 17:48:25 +08:00
\section TutorialMatrixFirst3Params The first three template parameters of Matrix
2010-06-25 22:04:35 +08:00
2010-07-06 17:48:25 +08:00
The Matrix class takes six template parameters, but for now it's enough to
learn about the first three first parameters. The three remaining parameters have default
2010-06-25 22:04:35 +08:00
values, which for now we will leave untouched, and which we
2010-06-27 02:00:00 +08:00
\ref TutorialMatrixOptTemplParams "discuss below".
2010-06-25 22:04:35 +08:00
2010-07-06 17:48:25 +08:00
The three mandatory template parameters of Matrix are:
2010-06-25 22:04:35 +08:00
\code
Matrix<typename Scalar, int RowsAtCompileTime, int ColsAtCompileTime>
\endcode
\li \c Scalar is the scalar type, i.e. the type of the coefficients.
That is, if you want a matrix of floats, choose \c float here.
2010-06-27 02:00:00 +08:00
See \ref TopicScalarTypes "Scalar types" for a list of all supported
2010-06-25 22:04:35 +08:00
scalar types and for how to extend support to new types.
\li \c RowsAtCompileTime and \c ColsAtCompileTime are the number of rows
2010-07-06 17:48:25 +08:00
and columns of the matrix as known at compile time (see
\ref TutorialMatrixDynamic "below" for what to do if the number is not
known at compile time).
2010-06-25 22:04:35 +08:00
We offer a lot of convenience typedefs to cover the usual cases. For example, \c Matrix4f is
a 4x4 matrix of floats. Here is how it is defined by Eigen:
\code
2010-07-06 17:48:25 +08:00
typedef Matrix<float, 4, 4> Matrix4f;
2010-06-25 22:04:35 +08:00
\endcode
2010-06-27 02:00:00 +08:00
We discuss \ref TutorialMatrixTypedefs "below" these convenience typedefs.
2010-06-25 22:04:35 +08:00
2010-06-27 02:00:00 +08:00
\section TutorialMatrixVectors Vectors
2010-06-25 22:04:35 +08:00
As mentioned above, in Eigen, vectors are just a special case of
matrices, with either 1 row or 1 column. The case where they have 1 column is the most common;
such vectors are called column-vectors, often abbreviated as just vectors. In the other case
where they have 1 row, they are called row-vectors.
2010-07-06 17:48:25 +08:00
For example, the convenience typedef \c Vector3f is a (column) vector of 3 floats. It is defined as follows by Eigen:
2010-06-25 22:04:35 +08:00
\code
typedef Matrix<float, 3, 1> Vector3f;
\endcode
2010-07-06 17:48:25 +08:00
We also offer convenience typedefs for row-vectors, for example:
2010-06-25 22:04:35 +08:00
\code
typedef Matrix<int, 1, 2> RowVector2i;
\endcode
2010-06-27 02:00:00 +08:00
\section TutorialMatrixDynamic The special value Dynamic
2010-06-25 22:04:35 +08:00
Of course, Eigen is not limited to matrices whose dimensions are known at compile time.
2010-07-06 17:48:25 +08:00
The \c RowsAtCompileTime and \c ColsAtCompileTime template parameters can take the special
2010-06-25 22:04:35 +08:00
value \c Dynamic which indicates that the size is unknown at compile time, so must
2010-07-06 17:48:25 +08:00
be handled as a run-time variable. In Eigen terminology, such a size is referred to as a
2010-06-25 22:04:35 +08:00
\em dynamic \em size; while a size that is known at compile time is called a
\em fixed \em size. For example, the convenience typedef \c MatrixXd, meaning
a matrix of doubles with dynamic size, is defined as follows:
\code
2010-07-06 17:48:25 +08:00
typedef Matrix<double, Dynamic, Dynamic> MatrixXd;
2010-06-25 22:04:35 +08:00
\endcode
And similarly, we define a self-explanatory typedef \c VectorXi as follows:
\code
2010-07-06 17:48:25 +08:00
typedef Matrix<int, Dynamic, 1> VectorXi;
2010-06-25 22:04:35 +08:00
\endcode
You can perfectly have e.g. a fixed number of rows with a dynamic number of columns, as in:
\code
Matrix<float, 3, Dynamic>
\endcode
2010-06-27 02:00:00 +08:00
\section TutorialMatrixConstructors Constructors
2010-06-25 22:04:35 +08:00
2010-10-15 21:44:43 +08:00
A default constructor is always available, never performs any dynamic memory allocation, and never initializes the matrix coefficients. You can do:
2010-06-25 22:04:35 +08:00
\code
Matrix3f a;
MatrixXf b;
\endcode
Here,
2013-06-18 21:35:12 +08:00
\li \c a is a 3-by-3 matrix, with a plain float[9] array of uninitialized coefficients,
\li \c b is a dynamic-size matrix whose size is currently 0-by-0, and whose array of
2010-06-25 22:04:35 +08:00
coefficients hasn't yet been allocated at all.
Constructors taking sizes are also available. For matrices, the number of rows is always passed first.
For vectors, just pass the vector size. They allocate the array of coefficients
with the given size, but don't initialize the coefficients themselves:
\code
MatrixXf a(10,15);
VectorXf b(30);
\endcode
Here,
\li \c a is a 10x15 dynamic-size matrix, with allocated but currently uninitialized coefficients.
\li \c b is a dynamic-size vector of size 30, with allocated but currently uninitialized coefficients.
In order to offer a uniform API across fixed-size and dynamic-size matrices, it is legal to use these
constructors on fixed-size matrices, even if passing the sizes is useless in this case. So this is legal:
\code
Matrix3f a(3,3);
\endcode
and is a no-operation.
2019-01-23 00:08:47 +08:00
Matrices and vectors can also be initialized from lists of coefficients.
Prior to C++11, this feature is limited to small fixed-size column or vectors up to size 4:
2010-06-25 22:04:35 +08:00
\code
Vector2d a(5.0, 6.0);
Vector3d b(5.0, 6.0, 7.0);
Vector4d c(5.0, 6.0, 7.0, 8.0);
\endcode
2019-01-23 07:07:19 +08:00
If C++11 is enabled, fixed-size column or row vectors of arbitrary size can be initialized by passing an arbitrary number of coefficients:
PR 572: Add initializer list constructors to Matrix and Array (include unit tests and doc)
- {1,2,3,4,5,...} for fixed-size vectors only
- {{1,2,3},{4,5,6}} for the general cases
- {{1,2,3,4,5,....}} is allowed for both row and column-vector
2019-01-21 23:25:57 +08:00
\code
2019-01-23 07:07:19 +08:00
Vector2i a(1, 2); // A column vector containing the elements {1, 2}
2019-01-23 00:08:47 +08:00
Matrix<int, 5, 1> b {1, 2, 3, 4, 5}; // A row-vector containing the elements {1, 2, 3, 4, 5}
2019-01-23 07:07:19 +08:00
Matrix<int, 1, 5> c = {1, 2, 3, 4, 5}; // A column vector containing the elements {1, 2, 3, 4, 5}
PR 572: Add initializer list constructors to Matrix and Array (include unit tests and doc)
- {1,2,3,4,5,...} for fixed-size vectors only
- {{1,2,3},{4,5,6}} for the general cases
- {{1,2,3,4,5,....}} is allowed for both row and column-vector
2019-01-21 23:25:57 +08:00
\endcode
2019-01-23 00:08:47 +08:00
In the general case of matrices and vectors with either fixed or runtime sizes,
coefficients have to be grouped by rows and passed as an initializer list of initializer list (\link Matrix::Matrix(const std::initializer_list<std::initializer_list<Scalar>>&) details \endlink):
PR 572: Add initializer list constructors to Matrix and Array (include unit tests and doc)
- {1,2,3,4,5,...} for fixed-size vectors only
- {{1,2,3},{4,5,6}} for the general cases
- {{1,2,3,4,5,....}} is allowed for both row and column-vector
2019-01-21 23:25:57 +08:00
\code
2019-01-23 00:08:47 +08:00
MatrixXi a { // construct a 2x2 matrix
PR 572: Add initializer list constructors to Matrix and Array (include unit tests and doc)
- {1,2,3,4,5,...} for fixed-size vectors only
- {{1,2,3},{4,5,6}} for the general cases
- {{1,2,3,4,5,....}} is allowed for both row and column-vector
2019-01-21 23:25:57 +08:00
{1, 2}, // first row
{3, 4} // second row
};
Matrix<double, 2, 3> b {
2019-01-23 00:08:47 +08:00
{2, 3, 4},
{5, 6, 7},
PR 572: Add initializer list constructors to Matrix and Array (include unit tests and doc)
- {1,2,3,4,5,...} for fixed-size vectors only
- {{1,2,3},{4,5,6}} for the general cases
- {{1,2,3,4,5,....}} is allowed for both row and column-vector
2019-01-21 23:25:57 +08:00
};
\endcode
2019-01-23 00:08:47 +08:00
For column or row vectors, implicit transposition is allowed.
This means that a column vector can be initialized from a single row:
PR 572: Add initializer list constructors to Matrix and Array (include unit tests and doc)
- {1,2,3,4,5,...} for fixed-size vectors only
- {{1,2,3},{4,5,6}} for the general cases
- {{1,2,3,4,5,....}} is allowed for both row and column-vector
2019-01-21 23:25:57 +08:00
\code
2019-01-23 00:08:47 +08:00
VectorXd a {{1.5, 2.5, 3.5}}; // A column-vector with 3 coefficients
RowVectorXd b {{1.0, 2.0, 3.0, 4.0}}; // A row-vector with 4 coefficients
PR 572: Add initializer list constructors to Matrix and Array (include unit tests and doc)
- {1,2,3,4,5,...} for fixed-size vectors only
- {{1,2,3},{4,5,6}} for the general cases
- {{1,2,3,4,5,....}} is allowed for both row and column-vector
2019-01-21 23:25:57 +08:00
\endcode
2010-06-27 02:00:00 +08:00
\section TutorialMatrixCoeffAccessors Coefficient accessors
2010-06-25 22:04:35 +08:00
The primary coefficient accessors and mutators in Eigen are the overloaded parenthesis operators.
For matrices, the row index is always passed first. For vectors, just pass one index.
The numbering starts at 0. This example is self-explanatory:
2010-07-12 19:02:31 +08:00
2010-10-19 17:40:49 +08:00
<table class="example">
<tr><th>Example:</th><th>Output:</th></tr>
<tr><td>
\include tut_matrix_coefficient_accessors.cpp
2010-07-12 19:02:31 +08:00
</td>
<td>
2010-10-19 17:40:49 +08:00
\verbinclude tut_matrix_coefficient_accessors.out
2010-07-12 19:02:31 +08:00
</td></tr></table>
2010-06-25 22:04:35 +08:00
2010-07-12 19:02:31 +08:00
Note that the syntax <tt> m(index) </tt>
2010-06-25 22:04:35 +08:00
is not restricted to vectors, it is also available for general matrices, meaning index-based access
in the array of coefficients. This however depends on the matrix's storage order. All Eigen matrices default to
2010-06-27 02:00:00 +08:00
column-major storage order, but this can be changed to row-major, see \ref TopicStorageOrders "Storage orders".
2010-06-25 22:04:35 +08:00
The operator[] is also overloaded for index-based access in vectors, but keep in mind that C++ doesn't allow operator[] to
take more than one argument. We restrict operator[] to vectors, because an awkwardness in the C++ language
would make matrix[i,j] compile to the same thing as matrix[j] !
2010-06-28 06:22:47 +08:00
\section TutorialMatrixCommaInitializer Comma-initialization
2010-07-12 19:02:31 +08:00
%Matrix and vector coefficients can be conveniently set using the so-called \em comma-initializer syntax.
2010-06-28 06:22:47 +08:00
For now, it is enough to know this example:
2010-07-12 19:02:31 +08:00
2010-10-19 17:40:49 +08:00
<table class="example">
<tr><th>Example:</th><th>Output:</th></tr>
<tr>
<td>\include Tutorial_commainit_01.cpp </td>
<td>\verbinclude Tutorial_commainit_01.out </td>
</tr></table>
2010-07-12 19:02:31 +08:00
2010-07-06 17:48:25 +08:00
The right-hand side can also contain matrix expressions as discussed in \ref TutorialAdvancedInitialization "this page".
2010-06-28 06:22:47 +08:00
2010-06-27 02:00:00 +08:00
\section TutorialMatrixSizesResizing Resizing
2010-06-25 22:04:35 +08:00
2010-10-20 21:34:13 +08:00
The current size of a matrix can be retrieved by \link EigenBase::rows() rows()\endlink, \link EigenBase::cols() cols() \endlink and \link EigenBase::size() size()\endlink. These methods return the number of rows, the number of columns and the number of coefficients, respectively. Resizing a dynamic-size matrix is done by the \link PlainObjectBase::resize(Index,Index) resize() \endlink method.
2010-07-12 19:02:31 +08:00
2010-10-19 17:40:49 +08:00
<table class="example">
<tr><th>Example:</th><th>Output:</th></tr>
<tr>
<td>\include tut_matrix_resize.cpp </td>
<td>\verbinclude tut_matrix_resize.out </td>
</tr></table>
2010-06-25 22:04:35 +08:00
2010-07-06 17:48:25 +08:00
The resize() method is a no-operation if the actual matrix size doesn't change; otherwise it is destructive: the values of the coefficients may change.
2010-10-20 21:34:13 +08:00
If you want a conservative variant of resize() which does not change the coefficients, use \link PlainObjectBase::conservativeResize() conservativeResize()\endlink, see \ref TopicResizing "this page" for more details.
2010-06-25 22:04:35 +08:00
All these methods are still available on fixed-size matrices, for the sake of API uniformity. Of course, you can't actually
resize a fixed-size matrix. Trying to change a fixed size to an actually different value will trigger an assertion failure;
but the following code is legal:
2010-07-12 19:02:31 +08:00
2010-10-19 17:40:49 +08:00
<table class="example">
<tr><th>Example:</th><th>Output:</th></tr>
<tr>
<td>\include tut_matrix_resize_fixed_size.cpp </td>
<td>\verbinclude tut_matrix_resize_fixed_size.out </td>
</tr></table>
2010-07-12 19:02:31 +08:00
2010-06-25 22:04:35 +08:00
2010-06-27 02:00:00 +08:00
\section TutorialMatrixAssignment Assignment and resizing
2010-07-06 17:48:25 +08:00
Assignment is the action of copying a matrix into another, using \c operator=. Eigen resizes the matrix on the left-hand side automatically so that it matches the size of the matrix on the right-hand size. For example:
2010-07-12 19:02:31 +08:00
2010-10-19 20:42:49 +08:00
<table class="example">
2010-10-19 17:40:49 +08:00
<tr><th>Example:</th><th>Output:</th></tr>
<tr>
<td>\include tut_matrix_assignment_resizing.cpp </td>
<td>\verbinclude tut_matrix_assignment_resizing.out </td>
</tr></table>
2010-06-27 02:00:00 +08:00
2010-07-06 17:48:25 +08:00
Of course, if the left-hand side is of fixed size, resizing it is not allowed.
2010-06-25 22:04:35 +08:00
2010-06-27 02:00:00 +08:00
If you do not want this automatic resizing to happen (for example for debugging purposes), you can disable it, see
\ref TopicResizing "this page".
\section TutorialMatrixFixedVsDynamic Fixed vs. Dynamic size
When should one use fixed sizes (e.g. \c Matrix4f), and when should one prefer dynamic sizes (e.g. \c MatrixXf)?
2010-06-25 22:04:35 +08:00
The simple answer is: use fixed
sizes for very small sizes where you can, and use dynamic sizes for larger sizes or where you have to. For small sizes,
especially for sizes smaller than (roughly) 16, using fixed sizes is hugely beneficial
to performance, as it allows Eigen to avoid dynamic memory allocation and to unroll
2013-06-18 21:35:12 +08:00
loops. Internally, a fixed-size Eigen matrix is just a plain array, i.e. doing
2010-06-25 22:04:35 +08:00
\code Matrix4f mymatrix; \endcode
really amounts to just doing
\code float mymatrix[16]; \endcode
2010-06-29 18:42:51 +08:00
so this really has zero runtime cost. By contrast, the array of a dynamic-size matrix
2010-06-25 22:04:35 +08:00
is always allocated on the heap, so doing
\code MatrixXf mymatrix(rows,columns); \endcode
amounts to doing
\code float *mymatrix = new float[rows*columns]; \endcode
and in addition to that, the MatrixXf object stores its number of rows and columns as
member variables.
The limitation of using fixed sizes, of course, is that this is only possible
when you know the sizes at compile time. Also, for large enough sizes, say for sizes
greater than (roughly) 32, the performance benefit of using fixed sizes becomes negligible.
2013-06-18 21:35:12 +08:00
Worse, trying to create a very large matrix using fixed sizes inside a function could result in a
stack overflow, since Eigen will try to allocate the array automatically as a local variable, and
this is normally done on the stack.
2010-06-25 22:04:35 +08:00
Finally, depending on circumstances, Eigen can also be more aggressive trying to vectorize
2010-06-27 02:00:00 +08:00
(use SIMD instructions) when dynamic sizes are used, see \ref TopicVectorization "Vectorization".
2010-06-25 22:04:35 +08:00
2010-06-27 02:00:00 +08:00
\section TutorialMatrixOptTemplParams Optional template parameters
2010-06-25 22:04:35 +08:00
2010-07-06 17:48:25 +08:00
We mentioned at the beginning of this page that the Matrix class takes six template parameters,
but so far we only discussed the first three. The remaining three parameters are optional. Here is
2010-06-25 22:04:35 +08:00
the complete list of template parameters:
\code
Matrix<typename Scalar,
int RowsAtCompileTime,
int ColsAtCompileTime,
int Options = 0,
int MaxRowsAtCompileTime = RowsAtCompileTime,
int MaxColsAtCompileTime = ColsAtCompileTime>
\endcode
2010-07-06 17:48:25 +08:00
\li \c Options is a bit field. Here, we discuss only one bit: \c RowMajor. It specifies that the matrices
of this type use row-major storage order; by default, the storage order is column-major. See the page on
2010-06-27 02:00:00 +08:00
\ref TopicStorageOrders "storage orders". For example, this type means row-major 3x3 matrices:
2010-06-25 22:04:35 +08:00
\code
2010-07-06 17:48:25 +08:00
Matrix<float, 3, 3, RowMajor>
2010-06-25 22:04:35 +08:00
\endcode
\li \c MaxRowsAtCompileTime and \c MaxColsAtCompileTime are useful when you want to specify that, even though
2010-07-06 17:48:25 +08:00
the exact sizes of your matrices are not known at compile time, a fixed upper bound is known at
2010-06-25 22:04:35 +08:00
compile time. The biggest reason why you might want to do that is to avoid dynamic memory allocation.
2013-06-18 21:35:12 +08:00
For example the following matrix type uses a plain array of 12 floats, without dynamic memory allocation:
2010-06-25 22:04:35 +08:00
\code
2010-07-06 17:48:25 +08:00
Matrix<float, Dynamic, Dynamic, 0, 3, 4>
2010-06-25 22:04:35 +08:00
\endcode
2010-06-27 02:00:00 +08:00
\section TutorialMatrixTypedefs Convenience typedefs
2010-06-25 22:04:35 +08:00
Eigen defines the following Matrix typedefs:
2010-07-02 08:29:13 +08:00
\li MatrixNt for Matrix<type, N, N>. For example, MatrixXi for Matrix<int, Dynamic, Dynamic>.
\li VectorNt for Matrix<type, N, 1>. For example, Vector2f for Matrix<float, 2, 1>.
\li RowVectorNt for Matrix<type, 1, N>. For example, RowVector3d for Matrix<double, 1, 3>.
2010-06-25 22:04:35 +08:00
Where:
2010-07-06 17:48:25 +08:00
\li N can be any one of \c 2, \c 3, \c 4, or \c X (meaning \c Dynamic).
2010-07-02 08:29:13 +08:00
\li t can be any one of \c i (meaning int), \c f (meaning float), \c d (meaning double),
2010-06-25 22:04:35 +08:00
\c cf (meaning complex<float>), or \c cd (meaning complex<double>). The fact that typedefs are only
2010-07-06 17:48:25 +08:00
defined for these five types doesn't mean that they are the only supported scalar types. For example,
2010-06-27 02:00:00 +08:00
all standard integer types are supported, see \ref TopicScalarTypes "Scalar types".
2010-06-25 22:04:35 +08:00
*/
2010-06-29 18:42:51 +08:00
}