cart-elc

Source code for CART-ELC
git clone git://git.laack.co/cart-elc.git
Log | Files | Refs | README | LICENSE

TutorialMatrixClass.dox (13680B)


      1 namespace Eigen {
      2 
      3 /** \eigenManualPage TutorialMatrixClass The Matrix class
      4 
      5 \eigenAutoToc
      6 
      7 In Eigen, all matrices and vectors are objects of the Matrix template class.
      8 Vectors are just a special case of matrices, with either 1 row or 1 column.
      9 
     10 \section TutorialMatrixFirst3Params The first three template parameters of Matrix
     11 
     12 The Matrix class takes six template parameters, but for now it's enough to
     13 learn about the first three first parameters. The three remaining parameters have default
     14 values, which for now we will leave untouched, and which we
     15 \ref TutorialMatrixOptTemplParams "discuss below".
     16 
     17 The three mandatory template parameters of Matrix are:
     18 \code
     19 Matrix<typename Scalar, int RowsAtCompileTime, int ColsAtCompileTime>
     20 \endcode
     21 \li \c Scalar is the scalar type, i.e. the type of the coefficients.
     22     That is, if you want a matrix of floats, choose \c float here.
     23     See \ref TopicScalarTypes "Scalar types" for a list of all supported
     24     scalar types and for how to extend support to new types.
     25 \li \c RowsAtCompileTime and \c ColsAtCompileTime are the number of rows
     26     and columns of the matrix as known at compile time (see 
     27     \ref TutorialMatrixDynamic "below" for what to do if the number is not
     28     known at compile time).
     29 
     30 We offer a lot of convenience typedefs to cover the usual cases. For example, \c Matrix4f is
     31 a 4x4 matrix of floats. Here is how it is defined by Eigen:
     32 \code
     33 typedef Matrix<float, 4, 4> Matrix4f;
     34 \endcode
     35 We discuss \ref TutorialMatrixTypedefs "below" these convenience typedefs.
     36 
     37 \section TutorialMatrixVectors Vectors
     38 
     39 As mentioned above, in Eigen, vectors are just a special case of
     40 matrices, with either 1 row or 1 column. The case where they have 1 column is the most common;
     41 such vectors are called column-vectors, often abbreviated as just vectors. In the other case
     42 where they have 1 row, they are called row-vectors.
     43 
     44 For example, the convenience typedef \c Vector3f is a (column) vector of 3 floats. It is defined as follows by Eigen:
     45 \code
     46 typedef Matrix<float, 3, 1> Vector3f;
     47 \endcode
     48 We also offer convenience typedefs for row-vectors, for example:
     49 \code
     50 typedef Matrix<int, 1, 2> RowVector2i;
     51 \endcode
     52 
     53 \section TutorialMatrixDynamic The special value Dynamic
     54 
     55 Of course, Eigen is not limited to matrices whose dimensions are known at compile time.
     56 The \c RowsAtCompileTime and \c ColsAtCompileTime template parameters can take the special
     57 value \c Dynamic which indicates that the size is unknown at compile time, so must
     58 be handled as a run-time variable. In Eigen terminology, such a size is referred to as a
     59 \em dynamic \em size; while a size that is known at compile time is called a
     60 \em fixed \em size. For example, the convenience typedef \c MatrixXd, meaning
     61 a matrix of doubles with dynamic size, is defined as follows:
     62 \code
     63 typedef Matrix<double, Dynamic, Dynamic> MatrixXd;
     64 \endcode
     65 And similarly, we define a self-explanatory typedef \c VectorXi as follows:
     66 \code
     67 typedef Matrix<int, Dynamic, 1> VectorXi;
     68 \endcode
     69 You can perfectly have e.g. a fixed number of rows with a dynamic number of columns, as in:
     70 \code
     71 Matrix<float, 3, Dynamic>
     72 \endcode
     73 
     74 \section TutorialMatrixConstructors Constructors
     75 
     76 A default constructor is always available, never performs any dynamic memory allocation, and never initializes the matrix coefficients. You can do:
     77 \code
     78 Matrix3f a;
     79 MatrixXf b;
     80 \endcode
     81 Here,
     82 \li \c a is a 3-by-3 matrix, with a plain float[9] array of uninitialized coefficients,
     83 \li \c b is a dynamic-size matrix whose size is currently 0-by-0, and whose array of
     84 coefficients hasn't yet been allocated at all.
     85 
     86 Constructors taking sizes are also available. For matrices, the number of rows is always passed first.
     87 For vectors, just pass the vector size. They allocate the array of coefficients
     88 with the given size, but don't initialize the coefficients themselves:
     89 \code
     90 MatrixXf a(10,15);
     91 VectorXf b(30);
     92 \endcode
     93 Here,
     94 \li \c a is a 10x15 dynamic-size matrix, with allocated but currently uninitialized coefficients.
     95 \li \c b is a dynamic-size vector of size 30, with allocated but currently uninitialized coefficients.
     96 
     97 In order to offer a uniform API across fixed-size and dynamic-size matrices, it is legal to use these
     98 constructors on fixed-size matrices, even if passing the sizes is useless in this case. So this is legal:
     99 \code
    100 Matrix3f a(3,3);
    101 \endcode
    102 and is a no-operation.
    103 
    104 Matrices and vectors can also be initialized from lists of coefficients.
    105 Prior to C++11, this feature is limited to small fixed-size column or vectors up to size 4:
    106 \code
    107 Vector2d a(5.0, 6.0);
    108 Vector3d b(5.0, 6.0, 7.0);
    109 Vector4d c(5.0, 6.0, 7.0, 8.0);
    110 \endcode
    111 
    112 If C++11 is enabled, fixed-size column or row vectors of arbitrary size can be initialized by passing an arbitrary number of coefficients:
    113 \code
    114 Vector2i a(1, 2);                      // A column vector containing the elements {1, 2}
    115 Matrix<int, 5, 1> b {1, 2, 3, 4, 5};   // A row-vector containing the elements {1, 2, 3, 4, 5}
    116 Matrix<int, 1, 5> c = {1, 2, 3, 4, 5}; // A column vector containing the elements {1, 2, 3, 4, 5}
    117 \endcode
    118 
    119 In the general case of matrices and vectors with either fixed or runtime sizes,
    120 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):
    121 \code
    122 MatrixXi a {      // construct a 2x2 matrix
    123       {1, 2},     // first row
    124       {3, 4}      // second row
    125 };
    126 Matrix<double, 2, 3> b {
    127       {2, 3, 4},
    128       {5, 6, 7},
    129 };
    130 \endcode
    131 
    132 For column or row vectors, implicit transposition is allowed.
    133 This means that a column vector can be initialized from a single row:
    134 \code
    135 VectorXd a {{1.5, 2.5, 3.5}};             // A column-vector with 3 coefficients
    136 RowVectorXd b {{1.0, 2.0, 3.0, 4.0}};     // A row-vector with 4 coefficients
    137 \endcode
    138 
    139 \section TutorialMatrixCoeffAccessors Coefficient accessors
    140 
    141 The primary coefficient accessors and mutators in Eigen are the overloaded parenthesis operators.
    142 For matrices, the row index is always passed first. For vectors, just pass one index.
    143 The numbering starts at 0. This example is self-explanatory:
    144 
    145 <table class="example">
    146 <tr><th>Example:</th><th>Output:</th></tr>
    147 <tr><td>
    148 \include tut_matrix_coefficient_accessors.cpp
    149 </td>
    150 <td>
    151 \verbinclude tut_matrix_coefficient_accessors.out
    152 </td></tr></table>
    153 
    154 Note that the syntax <tt> m(index) </tt>
    155 is not restricted to vectors, it is also available for general matrices, meaning index-based access
    156 in the array of coefficients. This however depends on the matrix's storage order. All Eigen matrices default to
    157 column-major storage order, but this can be changed to row-major, see \ref TopicStorageOrders "Storage orders".
    158 
    159 The operator[] is also overloaded for index-based access in vectors, but keep in mind that C++ doesn't allow operator[] to
    160 take more than one argument. We restrict operator[] to vectors, because an awkwardness in the C++ language
    161 would make matrix[i,j] compile to the same thing as matrix[j] !
    162 
    163 \section TutorialMatrixCommaInitializer Comma-initialization
    164 
    165 %Matrix and vector coefficients can be conveniently set using the so-called \em comma-initializer syntax.
    166 For now, it is enough to know this example:
    167 
    168 <table class="example">
    169 <tr><th>Example:</th><th>Output:</th></tr>
    170 <tr>
    171 <td>\include Tutorial_commainit_01.cpp </td>
    172 <td>\verbinclude Tutorial_commainit_01.out </td>
    173 </tr></table>
    174 
    175 
    176 The right-hand side can also contain matrix expressions as discussed in \ref TutorialAdvancedInitialization "this page".
    177 
    178 \section TutorialMatrixSizesResizing Resizing
    179 
    180 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.
    181 
    182 <table class="example">
    183 <tr><th>Example:</th><th>Output:</th></tr>
    184 <tr>
    185 <td>\include tut_matrix_resize.cpp </td>
    186 <td>\verbinclude tut_matrix_resize.out </td>
    187 </tr></table>
    188 
    189 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.
    190 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.
    191 
    192 All these methods are still available on fixed-size matrices, for the sake of API uniformity. Of course, you can't actually
    193 resize a fixed-size matrix. Trying to change a fixed size to an actually different value will trigger an assertion failure;
    194 but the following code is legal:
    195 
    196 <table class="example">
    197 <tr><th>Example:</th><th>Output:</th></tr>
    198 <tr>
    199 <td>\include tut_matrix_resize_fixed_size.cpp </td>
    200 <td>\verbinclude tut_matrix_resize_fixed_size.out </td>
    201 </tr></table>
    202 
    203 
    204 \section TutorialMatrixAssignment Assignment and resizing
    205 
    206 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:
    207 
    208 <table class="example">
    209 <tr><th>Example:</th><th>Output:</th></tr>
    210 <tr>
    211 <td>\include tut_matrix_assignment_resizing.cpp </td>
    212 <td>\verbinclude tut_matrix_assignment_resizing.out </td>
    213 </tr></table>
    214 
    215 Of course, if the left-hand side is of fixed size, resizing it is not allowed.
    216 
    217 If you do not want this automatic resizing to happen (for example for debugging purposes), you can disable it, see
    218 \ref TopicResizing "this page".
    219 
    220 
    221 \section TutorialMatrixFixedVsDynamic Fixed vs. Dynamic size
    222 
    223 When should one use fixed sizes (e.g. \c Matrix4f), and when should one prefer dynamic sizes (e.g. \c MatrixXf)?
    224 The simple answer is: use fixed
    225 sizes for very small sizes where you can, and use dynamic sizes for larger sizes or where you have to. For small sizes,
    226 especially for sizes smaller than (roughly) 16, using fixed sizes is hugely beneficial
    227 to performance, as it allows Eigen to avoid dynamic memory allocation and to unroll
    228 loops. Internally, a fixed-size Eigen matrix is just a plain array, i.e. doing
    229 \code Matrix4f mymatrix; \endcode
    230 really amounts to just doing
    231 \code float mymatrix[16]; \endcode
    232 so this really has zero runtime cost. By contrast, the array of a dynamic-size matrix
    233 is always allocated on the heap, so doing
    234 \code MatrixXf mymatrix(rows,columns); \endcode
    235 amounts to doing
    236 \code float *mymatrix = new float[rows*columns]; \endcode
    237 and in addition to that, the MatrixXf object stores its number of rows and columns as
    238 member variables.
    239 
    240 The limitation of using fixed sizes, of course, is that this is only possible
    241 when you know the sizes at compile time. Also, for large enough sizes, say for sizes
    242 greater than (roughly) 32, the performance benefit of using fixed sizes becomes negligible.
    243 Worse, trying to create a very large matrix using fixed sizes inside a function could result in a
    244 stack overflow, since Eigen will try to allocate the array automatically as a local variable, and
    245 this is normally done on the stack.
    246 Finally, depending on circumstances, Eigen can also be more aggressive trying to vectorize
    247 (use SIMD instructions) when dynamic sizes are used, see \ref TopicVectorization "Vectorization".
    248 
    249 \section TutorialMatrixOptTemplParams Optional template parameters
    250 
    251 We mentioned at the beginning of this page that the Matrix class takes six template parameters,
    252 but so far we only discussed the first three. The remaining three parameters are optional. Here is
    253 the complete list of template parameters:
    254 \code
    255 Matrix<typename Scalar,
    256        int RowsAtCompileTime,
    257        int ColsAtCompileTime,
    258        int Options = 0,
    259        int MaxRowsAtCompileTime = RowsAtCompileTime,
    260        int MaxColsAtCompileTime = ColsAtCompileTime>
    261 \endcode
    262 \li \c Options is a bit field. Here, we discuss only one bit: \c RowMajor. It specifies that the matrices
    263       of this type use row-major storage order; by default, the storage order is column-major. See the page on
    264       \ref TopicStorageOrders "storage orders". For example, this type means row-major 3x3 matrices:
    265       \code
    266       Matrix<float, 3, 3, RowMajor>
    267       \endcode
    268 \li \c MaxRowsAtCompileTime and \c MaxColsAtCompileTime are useful when you want to specify that, even though
    269       the exact sizes of your matrices are not known at compile time, a fixed upper bound is known at
    270       compile time. The biggest reason why you might want to do that is to avoid dynamic memory allocation.
    271       For example the following matrix type uses a plain array of 12 floats, without dynamic memory allocation:
    272       \code
    273       Matrix<float, Dynamic, Dynamic, 0, 3, 4>
    274       \endcode
    275 
    276 \section TutorialMatrixTypedefs Convenience typedefs
    277 
    278 Eigen defines the following Matrix typedefs:
    279 \li MatrixNt for Matrix<type, N, N>. For example, MatrixXi for Matrix<int, Dynamic, Dynamic>.
    280 \li VectorNt for Matrix<type, N, 1>. For example, Vector2f for Matrix<float, 2, 1>.
    281 \li RowVectorNt for Matrix<type, 1, N>. For example, RowVector3d for Matrix<double, 1, 3>.
    282 
    283 Where:
    284 \li N can be any one of \c 2, \c 3, \c 4, or \c X (meaning \c Dynamic).
    285 \li t can be any one of \c i (meaning int), \c f (meaning float), \c d (meaning double),
    286       \c cf (meaning complex<float>), or \c cd (meaning complex<double>). The fact that typedefs are only
    287     defined for these five types doesn't mean that they are the only supported scalar types. For example,
    288     all standard integer types are supported, see \ref TopicScalarTypes "Scalar types".
    289 
    290 
    291 */
    292 
    293 }