[eigen] introducing the Eigen2 support stages |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen <eigen@xxxxxxxxxxxxxxxxxxx>
- Subject: [eigen] introducing the Eigen2 support stages
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Fri, 21 Jan 2011 11:15:34 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=M4P8LVasw62g9Vku396WfkIxFEyZztW94P5VUnl6X2c=; b=uf/q/THcz7h3QNSJ2vzfDoAZmcbsaXMj9D2yxF54palsDfU2Dh+w/u5pU4cR1x7hVK gw1N60kRr77F0ros2476apLkPNnwEhM8KIL7Rbwxm6uNJgHdmZwYkS7kb65JLCzLvQ2f JXppDyj5/Ccl3FkEWDsqHeD+TJ2khh8jLgyc0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kvsy2k9DUZZVdwW4XsxBcKTyK4nz/xnPF6KLQn5aACbTFhtGUSu58ntlzanJCdsc0T B+RtLQ/1yy5FwLPSIT8/tl8xufEem45RVafoeWER7dE6DgNpshRJoDQwVb/3SXMs1ENt KhSazu9uhIm+r1XP/HGBMP2VeYN3Tj3ie36Ng=
Hi,
As you may know, we are in the process of making the transition from
eigen2 to 3 as easy as possible by making the EIGEN2_SUPPORT mode
fully Eigen2 API compatible.
However, as was discussed, there are a few corner cases where this is
impossible, because eigen2 and 3 use different conventions for the
same API.
So it's been suggested to split EIGEN2_SUPPORT into multiple 'stages',
and I have just dmplemented that.
First of all, if you are currently doing #define EIGEN2_SUPPORT, don't
worry: it stays supported, nothing changes. It just becomes a shortcut
for what I'll call below "stage 3"
So here are the different stages:
1) #define EIGEN2_SUPPORT_STAGE1_FULL_EIGEN2_API
When you #define this before including Eigen3 headers, you get 100%
support of the Eigen2 API (once ongoing work is completed), so that
Eigen2-using code compiles unchanged.
That means that when a convention is different between eigen2 and
eigen3, the eigen2 convention is used. For example, for complex
vectors x and y, x.dot(y) conjugates y (dot product linear in the
first variable x).
For such cases where the eigen2 and eigen3 APIs conflict, we introduce
eigen2_ prefixed functions, so you can replace
x.dot(y)
by
x.eigen2_dot(y)
2) #define EIGEN2_SUPPORT_STAGE2_RESOLVE_API_CONFLICTS
This is identical to stage 1 except that the eigen2 API that conflicts
with eigen3 is now deprecated. So when you do
x.dot(y)
you get a 'deprecated' warning even though that would also compile in
pure eigen3 (but with a different meaning). At this stage, you should
go over these warnings and fix them by using eigen2_ prefixed
functions:
x.eigen2_dot(y)
3) #define EIGEN2_SUPPORT_STAGE3_FULL_EIGEN3_API
This is what you get when you just #define EIGEN_SUPPORT.
This stage switches to eigen3 conventions everywhere. So now x.dot(y)
is linear in the first variable. You may still use eigen2_ prefixed
functions, and of course the rest of the Eigen2 API is still available
unchanged.
Also, where Eigen2 allows to do const-incorrect things (such as
mapping const data as non-const Map), this stage still allows it.
4) #define EIGEN2_SUPPORT_STAGE4_FULL_EIGEN3_STRICTNESS
This stage enables eigen3 strictness where eigen2 was laxist. In
particular, it enforces const-correctness of Map.
Notice that making the EIGEN2_SUPPORT_STAGE1_FULL_EIGEN2_API mode 100%
API compatible is work in progress. I am still in the process of
making the eigen2 test suite succeed. I'd say it should be completed
during this weekend.
Of course, I expect most small projects to just us EIGEN2_SUPPORT
(which, again, is giving you stage 3) and not worry about this at all.
Of course, this needs to be explained in the online 'porting from
eigen 2 to eigen3' dox page.
Benoit