|Re: [eigen] Eigen2 to Eigen3 Migration Path|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Eigen2 to Eigen3 Migration Path
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Wed, 12 Jan 2011 15:48:03 -0500
- Cc: Radu Bogdan Rusu <rusu@xxxxxxxxxxxxxxxx>, Stuart Glaser <sglaser@xxxxxxxxxxxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uRHAxd+qmPcLsdSfchLQO8WSfIVjtEWUZGhfHqY2hNE=; b=GsqlcIMlj496rLpwGoWS8GfGdJiBnTSkroJ7koE1fnKzx2wAd+9eEM4RP81uI0+F9w HScnhsMpfa7+VLLMUZndfHBH0pRNWKr6ceeQKD86gqybXqwTWW4S/66ZWLBVkHCCx1pV mWfTGYuuHBUIYMaDlUyAU+ssgRUdegzEQZ7Lg=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZJHS7RN3smqDTTzdq596i8zKfB11+nWIncFU/hhVKrvtuWgpubg0PqhzIFjc2sAeJ/ 4pBZJcLjxR6/2MxELG58dFmBCp01U6xUpxTXrLLC+vhazG+o38pUcYht+J/hYXM/y6i/ ttpZrSqLm/e039NuvvjpyCN5kf3cfk6mNZ368=
2011/1/12 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> On Wed, Jan 12, 2011 at 8:35 PM, Tully Foote <tfoote@xxxxxxxxxxxxxxxx>
>>> At this point I still think that we should go on with the invasive
>>> Eigen->Eigen3, EIGEN_->EIGEN3_ change. We can announce this change
>>> very loudly. For users, adapting to it just some search&replace:
>>> namespace Eigen -> namespace Eigen3
>>> Eigen:: -> Eigen3::
>>> EIGEN_ -> EIGEN3_
>> I strongly support the proposal. That is the cleanest way to progress
>> forward. It does impose a burden on the beta users. However I believe that
>> is better than imposing the corresponding burden on the users of the
>> released version.
> I am strongly voting against this change. Encoding the version number in the
> namespace is in my humblest opinion a very ugly solution!
Is it? I guess that's a matter of taste, but it appeared to me like a
natural way of avoiding collision, it's just one char.
As a little extra bonus, Eigen3::Vector has the merit of reducing the
confusion with "eigenvector".
> Changing Eigen:: -> Eigen2:: on the other hand side
Eigen 2 is stable, we can't break its API or ABI in anyway, and this
change breaks both.
> seems fine since it
> would be only (*cough*) affecting Eigen2 users and such a change would not
> be carried on to future versions. What were the plans regarding the
> namespace adaption once we reach version 4? Are we then switching to Eigen4
> and force everybody to change the ever-growing code base?
Yes, that was the idea, but the only people who would have to do so
would be people migrating from Eigen3 to Eigen4, which in itself would
be a comparatively much larger undertaking, making the effort of doing
the Eigen3->Eigen4 search-and-replace appear as negligible.
> Are we staying
> with Eigen3 while accepting the inherent confusion that might cause?
> We are since almost 6 months advocating users to switch to Eigen3 and
> Benoit's quick check on the number of users has revealed that the user base
> of Eigen v2 and v3 is converging rapidly if they are not already en par.
To be clear, the reason why I'm proposing this is that it means a
modest pain for all current Eigen3 users and no inherent technical
disadvantage as far as Eigen is concerned, in exchange for solving a
very serious problem inherent to Eigen that as far as I can see will
cause trouble to every large project migrating from eigen 2 to 3.
I realize that other libraries tend not to do that, but other
libraries also tend to either not release major new incompatible
versions (e.g. OpenGL stays compatible), or to wreck their ecosystem
when doing so (e.g. Qt, KDE) so it's hard to find an existing model to
> Well, I don't know what else to say. Maybe just that we should try very hard
> to find out how to make code that is currently running based on Eigen v2
> compile with v3 + EIGEN2_SUPPORT.
As I explained in my previous email, even if we fixed all API
compatibility issues, there would remain the ABI incompatibility
caused by differences in default values of template parameters
(Matrix's Options parameter). We got it wrong in Eigen2, fixed it in
Eigen3, but the price to pay was different mangled names.
> Recompiling any dependencies is then
> something that should in my opinion be accepted.
Tully's concern is much more serious than that! There is the concern
of having Eigen2 and Eigen3 coexist in a single software project,
which as discussed is going to stay the case for some time as
libraries using Eigen2 port to Eigen3.
> Kind regards,