ADD: added other eigen lib

This commit is contained in:
Henry Winkel
2022-12-21 16:19:04 +01:00
parent a570766dc6
commit 9e56c7f2c0
832 changed files with 36586 additions and 20006 deletions

View File

@@ -111,9 +111,9 @@ Vector4d c(5.0, 6.0, 7.0, 8.0);
If C++11 is enabled, fixed-size column or row vectors of arbitrary size can be initialized by passing an arbitrary number of coefficients:
\code
Vector2i a(1, 2); // A column vector containing the elements {1, 2}
Matrix<int, 5, 1> b {1, 2, 3, 4, 5}; // A row-vector containing the elements {1, 2, 3, 4, 5}
Matrix<int, 1, 5> c = {1, 2, 3, 4, 5}; // A column vector containing the elements {1, 2, 3, 4, 5}
Vector2i a(1, 2); // A column-vector containing the elements {1, 2}
Matrix<int, 5, 1> b {1, 2, 3, 4, 5}; // A column-vector containing the elements {1, 2, 3, 4, 5}
Matrix<int, 1, 5> c = {1, 2, 3, 4, 5}; // A row-vector containing the elements {1, 2, 3, 4, 5}
\endcode
In the general case of matrices and vectors with either fixed or runtime sizes,
@@ -151,14 +151,14 @@ The numbering starts at 0. This example is self-explanatory:
\verbinclude tut_matrix_coefficient_accessors.out
</td></tr></table>
Note that the syntax <tt> m(index) </tt>
Note that the syntax `m(index)`
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
column-major storage order, but this can be changed to row-major, see \ref TopicStorageOrders "Storage orders".
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] !
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]`!
\section TutorialMatrixCommaInitializer Comma-initialization
@@ -186,8 +186,8 @@ The current size of a matrix can be retrieved by \link EigenBase::rows() rows()\
<td>\verbinclude tut_matrix_resize.out </td>
</tr></table>
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.
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.
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.
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.
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;
@@ -234,7 +234,7 @@ 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
and in addition to that, the \c 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
@@ -276,14 +276,16 @@ Matrix<typename Scalar,
\section TutorialMatrixTypedefs Convenience typedefs
Eigen defines the following Matrix typedefs:
\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>.
\li \c MatrixNt for `Matrix<type, N, N>`. For example, \c MatrixXi for `Matrix<int, Dynamic, Dynamic>`.
\li \c MatrixXNt for `Matrix<type, Dynamic, N>`. For example, \c MatrixX3i for `Matrix<int, Dynamic, 3>`.
\li \c MatrixNXt for `Matrix<type, N, Dynamic>`. For example, \c Matrix4Xd for `Matrix<d, 4, Dynamic>`.
\li \c VectorNt for `Matrix<type, N, 1>`. For example, \c Vector2f for `Matrix<float, 2, 1>`.
\li \c RowVectorNt for `Matrix<type, 1, N>`. For example, \c RowVector3d for `Matrix<double, 1, 3>`.
Where:
\li N can be any one of \c 2, \c 3, \c 4, or \c X (meaning \c Dynamic).
\li t can be any one of \c i (meaning int), \c f (meaning float), \c d (meaning double),
\c cf (meaning complex<float>), or \c cd (meaning complex<double>). The fact that typedefs are only
\li \c N can be any one of \c 2, \c 3, \c 4, or \c X (meaning \c Dynamic).
\li \c t can be any one of \c i (meaning \c int), \c f (meaning \c float), \c d (meaning \c double),
\c cf (meaning `complex<float>`), or \c cd (meaning `complex<double>`). The fact that `typedef`s are only
defined for these five types doesn't mean that they are the only supported scalar types. For example,
all standard integer types are supported, see \ref TopicScalarTypes "Scalar types".