diff --git a/doc/A05_PortingFrom2To3.dox b/doc/A05_PortingFrom2To3.dox deleted file mode 100644 index 51555f996..000000000 --- a/doc/A05_PortingFrom2To3.dox +++ /dev/null @@ -1,299 +0,0 @@ -namespace Eigen { - -/** \page Eigen2ToEigen3 Porting from Eigen2 to Eigen3 - -This page lists the most important API changes between Eigen2 and Eigen3, -and gives tips to help porting your application from Eigen2 to Eigen3. - -\eigenAutoToc - -\section CompatibilitySupport Eigen2 compatibility support - -Up to version 3.2 %Eigen provides Eigen2 support modes. These are removed now, because they were barely used anymore and became hard to maintain after internal re-designs. -You can still use them by first porting your code to Eigen 3.2. - -\section Using The USING_PART_OF_NAMESPACE_EIGEN macro - -The USING_PART_OF_NAMESPACE_EIGEN macro has been removed. In Eigen 3, just do: -\code -using namespace Eigen; -\endcode - -\section ComplexDot Dot products over complex numbers - -This is the single trickiest change between Eigen 2 and Eigen 3. It only affects code using \c std::complex numbers as scalar type. - -Eigen 2's dot product was linear in the first variable. Eigen 3's dot product is linear in the second variable. In other words, the Eigen 2 code \code x.dot(y) \endcode is equivalent to the Eigen 3 code \code y.dot(x) \endcode In yet other words, dot products are complex-conjugated in Eigen 3 compared to Eigen 2. The switch to the new convention was commanded by common usage, especially with the notation \f$ x^Ty \f$ for dot products of column-vectors. - -\section VectorBlocks Vector blocks - - - - -
Eigen 2Eigen 3
\code -vector.start(length) -vector.start() -vector.end(length) -vector.end() -\endcode\code -vector.head(length) -vector.head() -vector.tail(length) -vector.tail() -\endcode
- - -\section Corners Matrix Corners - - - - - -
Eigen 2Eigen 3
\code -matrix.corner(TopLeft,r,c) -matrix.corner(TopRight,r,c) -matrix.corner(BottomLeft,r,c) -matrix.corner(BottomRight,r,c) -matrix.corner(TopLeft) -matrix.corner(TopRight) -matrix.corner(BottomLeft) -matrix.corner(BottomRight) -\endcode\code -matrix.topLeftCorner(r,c) -matrix.topRightCorner(r,c) -matrix.bottomLeftCorner(r,c) -matrix.bottomRightCorner(r,c) -matrix.topLeftCorner() -matrix.topRightCorner() -matrix.bottomLeftCorner() -matrix.bottomRightCorner() -\endcode
- -Notice that Eigen3 also provides these new convenience methods: topRows(), bottomRows(), leftCols(), rightCols(). See in class DenseBase. - -\section CoefficientWiseOperations Coefficient wise operations - -In Eigen2, coefficient wise operations which have no proper mathematical definition (as a coefficient wise product) -were achieved using the .cwise() prefix, e.g.: -\code a.cwise() * b \endcode -In Eigen3 this .cwise() prefix has been superseded by a new kind of matrix type called -Array for which all operations are performed coefficient wise. You can easily view a matrix as an array and vice versa using -the MatrixBase::array() and ArrayBase::matrix() functions respectively. Here is an example: -\code -Vector4f a, b, c; -c = a.array() * b.array(); -\endcode -Note that the .array() function is not at all a synonym of the deprecated .cwise() prefix. -While the .cwise() prefix changed the behavior of the following operator, the array() function performs -a permanent conversion to the array world. Therefore, for binary operations such as the coefficient wise product, -both sides must be converted to an \em array as in the above example. On the other hand, when you -concatenate multiple coefficient wise operations you only have to do the conversion once, e.g.: -\code -Vector4f a, b, c; -c = a.array().abs().pow(3) * b.array().abs().sin(); -\endcode -With Eigen2 you would have written: -\code -c = (a.cwise().abs().cwise().pow(3)).cwise() * (b.cwise().abs().cwise().sin()); -\endcode - -\section PartAndExtract Triangular and self-adjoint matrices - -In Eigen 2 you had to play with the part, extract, and marked functions to deal with triangular and selfadjoint matrices. In Eigen 3, all these functions have been removed in favor of the concept of \em views: - - - - - - - - - - - - - - - -
Eigen 2Eigen 3
\code -A.part(); -A.part(); \endcode\code -A.triangularView() -A.triangularView()\endcode
\code -A.extract(); -A.extract();\endcode\code -A.triangularView() -A.triangularView()\endcode
\code -A.marked(); -A.marked();\endcode\code -A.triangularView() -A.triangularView()\endcode
\code -A.part(); -A.extract();\endcode\code -A.selfadjointView() -A.selfadjointView()\endcode
\code -UpperTriangular -LowerTriangular -UnitUpperTriangular -UnitLowerTriangular -StrictlyUpperTriangular -StrictlyLowerTriangular -\endcode\code -Upper -Lower -UnitUpper -UnitLower -StrictlyUpper -StrictlyLower -\endcode
- -\sa class TriangularView, class SelfAdjointView - -\section TriangularSolveInPlace Triangular in-place solving - - - - -
Eigen 2Eigen 3
\code A.triangularSolveInPlace(Y);\endcode\code A.triangularView().solveInPlace(Y);\endcode
- - -\section Decompositions Matrix decompositions - -Some of Eigen 2's matrix decompositions have been renamed in Eigen 3, while some others have been removed and are replaced by other decompositions in Eigen 3. - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Eigen 2Eigen 3Notes
LUFullPivLUSee also the new PartialPivLU, it's much faster
QRHouseholderQRSee also the new ColPivHouseholderQR, it's more reliable
SVDJacobiSVDWe currently don't have a bidiagonalizing SVD; of course this is planned.
EigenSolver and friends\code #include \endcode Moved to separate module
- -\section LinearSolvers Linear solvers - - - - - - - - - - - - - - - - - - -
Eigen 2Eigen 3Notes
\code A.lu();\endcode\code A.fullPivLu();\endcodeNow A.lu() returns a PartialPivLU
\code A.lu().solve(B,&X);\endcode\code X = A.lu().solve(B); - X = A.fullPivLu().solve(B);\endcodeThe returned by value is fully optimized
\code A.llt().solve(B,&X);\endcode\code X = A.llt().solve(B); - X = A.selfadjointView.llt().solve(B); - X = A.selfadjointView.llt().solve(B);\endcodeThe returned by value is fully optimized and \n -the selfadjointView API allows you to select the \n -triangular part to work on (default is lower part)
\code A.llt().solveInPlace(B);\endcode\code B = A.llt().solve(B); - B = A.selfadjointView.llt().solve(B); - B = A.selfadjointView.llt().solve(B);\endcodeIn place solving
\code A.ldlt().solve(B,&X);\endcode\code X = A.ldlt().solve(B); - X = A.selfadjointView.ldlt().solve(B); - X = A.selfadjointView.ldlt().solve(B);\endcodeThe returned by value is fully optimized and \n -the selfadjointView API allows you to select the \n -triangular part to work on
- -\section GeometryModule Changes in the Geometry module - -The Geometry module is the one that changed the most. If you rely heavily on it, it's probably a good idea to use the "Eigen 2 support modes" to perform your migration. - -\section Transform The Transform class - -In Eigen 2, the Transform class didn't really know whether it was a projective or affine transformation. In Eigen 3, it takes a new \a Mode template parameter, which indicates whether it's \a Projective or \a Affine transform. There is no default value. - -The Transform3f (etc) typedefs are no more. In Eigen 3, the Transform typedefs explicitly refer to the \a Projective and \a Affine modes: - - - - - - - - -
Eigen 2Eigen 3Notes
Transform3f Affine3f or Projective3f Of course 3f is just an example here
- - -\section LazyVsNoalias Lazy evaluation and noalias - -In Eigen all operations are performed in a lazy fashion except the matrix products which are always evaluated into a temporary by default. -In Eigen2, lazy evaluation could be enforced by tagging a product using the .lazy() function. However, in complex expressions it was not -easy to determine where to put the lazy() function. In Eigen3, the lazy() feature has been superseded by the MatrixBase::noalias() function -which can be used on the left hand side of an assignment when no aliasing can occur. Here is an example: -\code -MatrixXf a, b, c; -... -c.noalias() += 2 * a.transpose() * b; -\endcode -However, the noalias mechanism does not cover all the features of the old .lazy(). Indeed, in some extremely rare cases, -it might be useful to explicit request for a lay product, i.e., for a product which will be evaluated one coefficient at once, on request, -just like any other expressions. To this end you can use the MatrixBase::lazyProduct() function, however we strongly discourage you to -use it unless you are sure of what you are doing, i.e., you have rigourosly measured a speed improvement. - -\section AlignMacros Alignment-related macros - -The EIGEN_ALIGN_128 macro has been renamed to EIGEN_ALIGN16. Don't be surprised, it's just that we switched to counting in bytes ;-) - -The \link TopicPreprocessorDirectivesPerformance EIGEN_DONT_ALIGN \endlink option still exists in Eigen 3, but it has a new cousin: \link TopicPreprocessorDirectivesPerformance EIGEN_DONT_ALIGN_STATICALLY.\endlink It allows to get rid of all static alignment issues while keeping alignment of dynamic-size heap-allocated arrays. Vectorization of statically allocated arrays is still preserved (unless you define \link TopicPreprocessorDirectivesPerformance EIGEN_UNALIGNED_VECTORIZE \endlink =0), at the cost of unaligned memory stores. - -\section AlignedMap Aligned Map objects - -A common issue with Eigen 2 was that when mapping an array with Map, there was no way to tell Eigen that your array was aligned. There was a ForceAligned option but it didn't mean that; it was just confusing and has been removed. - -New in Eigen3 is the #Aligned option. See the documentation of class Map. Use it like this: -\code -Map myMappedVector(some_aligned_array); -\endcode -There also are related convenience static methods, which actually are the preferred way as they take care of such things as constness: -\code -result = Vector4f::MapAligned(some_aligned_array); -\endcode - -\section StdContainers STL Containers - -In Eigen2, \#include\ tweaked std::vector to automatically align elements. The problem was that that was quite invasive. In Eigen3, we only override standard behavior if you use Eigen::aligned_allocator as your allocator type. So for example, if you use std::vector, you need to do the following change (note that aligned_allocator is under namespace Eigen): - - - - - - - -
Eigen 2Eigen 3
\code std::vector \endcode \code std::vector > \endcode
- -\section eiPrefix Internal ei_ prefix - -In Eigen2, global internal functions and structures were prefixed by \c ei_. In Eigen3, they all have been moved into the more explicit \c internal namespace. So, e.g., \c ei_sqrt(x) now becomes \c internal::sqrt(x). Of course it is not recommended to rely on Eigen's internal features. - - - -*/ - -} diff --git a/doc/Manual.dox b/doc/Manual.dox index 194164e97..84f0db645 100644 --- a/doc/Manual.dox +++ b/doc/Manual.dox @@ -15,7 +15,6 @@ namespace Eigen { /** \page UserManual_Generalities General topics - - \subpage Eigen2ToEigen3 - \subpage TopicFunctionTakingEigenTypes - \subpage TopicPreprocessorDirectives - \subpage TopicAssertions diff --git a/test/adjoint.cpp b/test/adjoint.cpp index 7c8081ec4..e2bfa6d7d 100644 --- a/test/adjoint.cpp +++ b/test/adjoint.cpp @@ -177,6 +177,10 @@ void adjoint_extra() c.col(j).head(j) = c.row(j).head(j); } + for (int j = 0; j < 10; ++j) { + c.col(j) = c.row(j); + } + a.conservativeResize(1,1); a = a.transpose();