mirror of
https://gitlab.com/libeigen/eigen.git
synced 2026-04-10 11:34:33 +08:00
Removed the deprecated EIGEN2_SUPPORT, as previously announced. A compilation error is raised, if this compile-switch is defined. The documentation references to the corresponding pages from Eigen3.2 now. Also, the Eigen2 testsuite has been removed.
This commit is contained in:
Christoph Hertzberg
@@ -9,11 +9,8 @@ and gives tips to help porting your application from Eigen2 to Eigen3.
|
||||
|
||||
\section CompatibilitySupport Eigen2 compatibility support
|
||||
|
||||
In order to ease the switch from Eigen2 to Eigen3, Eigen3 features \subpage Eigen2SupportModes "Eigen2 support modes".
|
||||
|
||||
The quick way to enable this is to define the \c EIGEN2_SUPPORT preprocessor token \b before including any Eigen header (typically it should be set in your project options).
|
||||
|
||||
A more powerful, \em staged migration path is also provided, which may be useful to migrate larger projects from Eigen2 to Eigen3. This is explained in the \ref Eigen2SupportModes "Eigen 2 support modes" page.
|
||||
Up to version 3.2 %Eigen provides <a href="http://eigen.tuxfamily.org/dox/Eigen2SupportModes.html">Eigen2 support modes</a>. 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 <a href="http://eigen.tuxfamily.org/dox/Eigen2ToEigen3.html">porting your code to Eigen 3.2</a>.
|
||||
|
||||
\section Using The USING_PART_OF_NAMESPACE_EIGEN macro
|
||||
|
||||
|
||||
@@ -1,93 +0,0 @@
|
||||
namespace Eigen {
|
||||
|
||||
/** \page Eigen2SupportModes Eigen 2 support modes
|
||||
|
||||
This page documents the Eigen2 support modes, a powerful tool to help migrating your project from Eigen 2 to Eigen 3.
|
||||
Don't miss our page on \ref Eigen2ToEigen3 "API changes" between Eigen 2 and Eigen 3.
|
||||
|
||||
\eigenAutoToc
|
||||
|
||||
\section EIGEN2_SUPPORT_Macro The quick way: define EIGEN2_SUPPORT
|
||||
|
||||
By defining EIGEN2_SUPPORT before including any Eigen 3 header, you get back a large part of the Eigen 2 API, while keeping the Eigen 3 API and ABI unchanged.
|
||||
|
||||
This defaults to the \ref Stage30 "stage 30" described below.
|
||||
|
||||
The rest of this page describes an optional, more powerful \em staged migration path.
|
||||
|
||||
\section StagedMigrationPathOverview Overview of the staged migration path
|
||||
|
||||
The primary reason why EIGEN2_SUPPORT alone may not be enough to migrate a large project from Eigen 2 to Eigen 3 is that some of the Eigen 2 API is inherently incompatible with the Eigen 3 API. This happens when the same identifier is used in Eigen 2 and in Eigen 3 with different meanings. To help migrate projects that rely on such API, we provide a staged migration path allowing to perform the migration \em incrementally.
|
||||
|
||||
It goes as follows:
|
||||
\li Step 0: start with a project using Eigen 2.
|
||||
\li Step 1: build your project against Eigen 3 with \ref Stage10 "Eigen 2 support stage 10". This mode enables maximum compatibility with the Eigen 2 API, with just a few exceptions.
|
||||
\li Step 2: build your project against Eigen 3 with \ref Stage20 "Eigen 2 support stage 20". This mode forces you to add eigen2_ prefixes to the Eigen2 identifiers that conflict with Eigen 3 API.
|
||||
\li Step 3: build your project against Eigen 3 with \ref Stage30 "Eigen 2 support stage 30". This mode enables the full Eigen 3 API.
|
||||
\li Step 4: build your project against Eigen 3 with \ref Stage40 "Eigen 2 support stage 40". This mode enables the full Eigen 3 strictness on matters, such as const-correctness, where Eigen 2 was looser.
|
||||
\li Step 5: build your project against Eigen 3 without any Eigen 2 support mode.
|
||||
|
||||
\section Stage10 Stage 10: define EIGEN2_SUPPORT_STAGE10_FULL_EIGEN2_API
|
||||
|
||||
Enable this mode by defining the EIGEN2_SUPPORT_STAGE10_FULL_EIGEN2_API preprocessor macro before including any Eigen 3 header.
|
||||
|
||||
This mode maximizes support for the Eigen 2 API. As a result, it does not offer the full Eigen 3 API. Also, it doesn't offer quite 100% of the Eigen 2 API.
|
||||
|
||||
The part of the Eigen 3 API that is not present in this mode, is Eigen 3's Geometry module. Indeed, this mode completely replaces it by a copy of Eigen 2's Geometry module.
|
||||
|
||||
The parts of the API that are still not 100% Eigen 2 compatible in this mode are:
|
||||
\li Dot products over complex numbers. 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.
|
||||
\li The Sparse module.
|
||||
\li Certain fine details of linear algebraic decompositions. For example, LDLT decomposition is now pivoting in Eigen 3 whereas it wasn't in Eigen 2, so code that was relying on its underlying matrix structure will break.
|
||||
\li Usage of Eigen types in STL containers, \ref Eigen2ToEigen3 "as explained on this page".
|
||||
|
||||
\section Stage20 Stage 20: define EIGEN2_SUPPORT_STAGE20_RESOLVE_API_CONFLICTS
|
||||
|
||||
Enable this mode by defining the EIGEN2_SUPPORT_STAGE10_FULL_EIGEN2_API preprocessor macro before including any Eigen 3 header.
|
||||
|
||||
This mode removes the Eigen 2 API that is directly conflicting with Eigen 3 API. Instead, these bits of Eigen 2 API remain available with eigen2_ prefixes. The main examples of such API are:
|
||||
\li the whole Geometry module. For example, replace \c Quaternion by \c eigen2_Quaternion, replace \c Transform3f by \c eigen2_Transform3f, etc.
|
||||
\li the lu() method to obtain a LU decomposition. Replace by eigen2_lu().
|
||||
|
||||
There is also one more eigen2_-prefixed identifier that you should know about, even though its use is not checked at compile time by this mode: the dot() method. As was discussed above, over complex numbers, its meaning is different between Eigen 2 and Eigen 3. You can use eigen2_dot() to get the Eigen 2 behavior.
|
||||
|
||||
\section Stage30 Stage 30: define EIGEN2_SUPPORT_STAGE30_FULL_EIGEN3_API
|
||||
|
||||
Enable this mode by defining the EIGEN2_SUPPORT_STAGE30_FULL_EIGEN3_API preprocessor macro before including any Eigen 3 header. Also, this mode is what you get by default when you just define EIGEN2_SUPPORT.
|
||||
|
||||
This mode gives you the full unaltered Eigen 3 API, while still keeping as much support as possible for the Eigen 2 API.
|
||||
|
||||
The eigen2_-prefixed identifiers are still available, but at this stage you should now replace them by Eigen 3 identifiers. Have a look at our page on \ref Eigen2ToEigen3 "API changes" between Eigen 2 and Eigen 3.
|
||||
|
||||
\section Stage40 Stage 40: define EIGEN2_SUPPORT_STAGE40_FULL_EIGEN3_STRICTNESS
|
||||
|
||||
Enable this mode by defining the EIGEN2_SUPPORT_STAGE40_FULL_EIGEN3_STRICTNESS preprocessor macro before including any Eigen 3 header.
|
||||
|
||||
This mode tightens the last bits of strictness, especially const-correctness, that had to be loosened to support what Eigen 2 allowed. For example, this code compiled in Eigen 2:
|
||||
\code
|
||||
const float array[4];
|
||||
x = Map<Vector4f>(array);
|
||||
\endcode
|
||||
That allowed to circumvent constness. This is no longer allowed in Eigen 3. If you have to map const data in Eigen 3, map it as a const-qualified type. However, rather than explictly constructing Map objects, we strongly encourage you to use the static Map methods instead, as they take care of all of this for you:
|
||||
\code
|
||||
const float array[4];
|
||||
x = Vector4f::Map(array);
|
||||
\endcode
|
||||
This lets Eigen do the right thing for you and works equally well in Eigen 2 and in Eigen 3.
|
||||
|
||||
\section FinallyDropAllEigen2Support Finally drop all Eigen 2 support
|
||||
|
||||
Stage 40 is the first where it's "comfortable" to stay for a little longer period, since it preserves 100% Eigen 3 compatibility. However, we still encourage you to complete your migration as quickly as possible. While we do run the Eigen 2 test suite against Eigen 3's stage 10 support mode, we can't guarantee the same level of support and quality assurance for Eigen 2 support as we do for Eigen 3 itself, especially not in the long term. \ref Eigen2ToEigen3 "This page" describes a large part of the changes that you may need to perform.
|
||||
|
||||
\section ABICompatibility What about ABI compatibility?
|
||||
|
||||
It goes as follows:
|
||||
\li Stage 10 already is ABI compatible with Eigen 3 for the basic (Matrix, Array, SparseMatrix...) types. However, since this stage uses a copy of Eigen 2's Geometry module instead of Eigen 3's own Geometry module, the ABI in the Geometry module is not Eigen 3 compatible.
|
||||
\li Stage 20 removes the Eigen 3-incompatible Eigen 2 Geometry module (it remains available with eigen2_ prefix). So at this stage, all the identifiers that exist in Eigen 3 have the Eigen 3 ABI (and API).
|
||||
\li Stage 30 introduces the remaining Eigen 3 identifiers. So at this stage, you have the full Eigen 3 ABI.
|
||||
\li Stage 40 is no different than Stage 30 in these matters.
|
||||
|
||||
|
||||
*/
|
||||
|
||||
}
|
||||
@@ -1584,7 +1584,6 @@ PREDEFINED = EIGEN_EMPTY_STRUCT \
|
||||
EIGEN_QT_SUPPORT \
|
||||
EIGEN_STRONG_INLINE=inline \
|
||||
EIGEN_DEVICE_FUNC= \
|
||||
"EIGEN2_SUPPORT_STAGE=99" \
|
||||
"EIGEN_MAKE_CWISE_BINARY_OP(METHOD,FUNCTOR)=template<typename OtherDerived> const CwiseBinaryOp<FUNCTOR<Scalar>, const Derived, const OtherDerived> METHOD(const EIGEN_CURRENT_STORAGE_BASE_CLASS<OtherDerived> &other) const;" \
|
||||
"EIGEN_CWISE_PRODUCT_RETURN_TYPE(LHS,RHS)=CwiseBinaryOp<internal::scalar_product_op<typename LHS::Scalar, typename RHS::Scalar >, const LHS, const RHS>"
|
||||
|
||||
@@ -1601,8 +1600,7 @@ EXPAND_AS_DEFINED = EIGEN_MAKE_TYPEDEFS \
|
||||
EIGEN_CWISE_BINOP_RETURN_TYPE \
|
||||
EIGEN_CURRENT_STORAGE_BASE_CLASS \
|
||||
EIGEN_MATHFUNC_IMPL \
|
||||
_EIGEN_GENERIC_PUBLIC_INTERFACE \
|
||||
EIGEN2_SUPPORT
|
||||
_EIGEN_GENERIC_PUBLIC_INTERFACE
|
||||
|
||||
# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
|
||||
# doxygen's preprocessor will remove all references to function-like macros
|
||||
|
||||
@@ -5,7 +5,7 @@ namespace Eigen {
|
||||
You can control some aspects of %Eigen by defining the preprocessor tokens using \c \#define. These macros
|
||||
should be defined before any %Eigen headers are included. Often they are best set in the project options.
|
||||
|
||||
This page lists the preprocesor tokens recognised by %Eigen.
|
||||
This page lists the preprocessor tokens recognized by %Eigen.
|
||||
|
||||
\eigenAutoToc
|
||||
|
||||
@@ -18,10 +18,9 @@ one option, and other parts (or libraries that you use) are compiled with anothe
|
||||
fail to link or exhibit subtle bugs. Nevertheless, these options can be useful for people who know what they
|
||||
are doing.
|
||||
|
||||
- \b EIGEN2_SUPPORT - if defined, enables the Eigen2 compatibility mode. This is meant to ease the transition
|
||||
of Eigen2 to Eigen3 (see \ref Eigen2ToEigen3). Not defined by default.
|
||||
- \b EIGEN2_SUPPORT_STAGEnn_xxx (for various values of nn and xxx) - staged migration path from Eigen2 to
|
||||
Eigen3; see \ref Eigen2SupportModes.
|
||||
- \b EIGEN2_SUPPORT and \b EIGEN2_SUPPORT_STAGEnn_xxx are disabled starting from the 3.3 release.
|
||||
Defining one of these will raise a compile-error. If you need to compile Eigen2 code,
|
||||
<a href="http://eigen.tuxfamily.org/index.php?title=Eigen2">check this site</a>.
|
||||
- \b EIGEN_DEFAULT_DENSE_INDEX_TYPE - the type for column and row indices in matrices, vectors and array
|
||||
(DenseBase::Index). Set to \c std::ptrdiff_t by default.
|
||||
- \b EIGEN_DEFAULT_IO_FORMAT - the IOFormat to use when printing a matrix if no %IOFormat is specified.
|
||||
@@ -55,7 +54,7 @@ run time. However, these assertions do cost time and can thus be turned off.
|
||||
|
||||
\section TopicPreprocessorDirectivesPerformance Alignment, vectorization and performance tweaking
|
||||
|
||||
- \b EIGEN_MALLOC_ALREADY_ALIGNED - Can be set to 0 or 1 to tell whether default system malloc already
|
||||
- \b EIGEN_MALLOC_ALREADY_ALIGNED - Can be set to 0 or 1 to tell whether default system \c malloc already
|
||||
returns aligned buffers. In not defined, then this information is automatically deduced from the compiler
|
||||
and system preprocessor tokens.
|
||||
- \b EIGEN_DONT_ALIGN - disables alignment completely. %Eigen will not try to align its objects and does not
|
||||
|
||||
@@ -1,18 +0,0 @@
|
||||
#define EIGEN2_SUPPORT
|
||||
#include <Eigen/Core>
|
||||
#include <iostream>
|
||||
|
||||
using namespace Eigen;
|
||||
using namespace std;
|
||||
|
||||
int main()
|
||||
{
|
||||
Matrix3i m = Matrix3i::Random();
|
||||
cout << "Here is the matrix m:" << endl << m << endl;
|
||||
Matrix3i n = Matrix3i::Random();
|
||||
cout << "And here is the matrix n:" << endl << n << endl;
|
||||
cout << "The coefficient-wise product of m and n is:" << endl;
|
||||
cout << m.cwise() * n << endl;
|
||||
cout << "Taking the cube of the coefficients of m yields:" << endl;
|
||||
cout << m.cwise().pow(3) << endl;
|
||||
}
|
||||
Reference in New Issue
Block a user