[eigen] Areas of eigen3 variation and using eigen2/3 in generic code?

[Jesse Perla <jesseperla@xxxxxxxxx>]

I am considering a partial switch for my economics-oriented library from ublas to eigen and have a few questions.

1.  What are the likely areas of flux in the eigen3 interface?  I looked at: http://eigen.tuxfamily.org/index.php?title=Todo_for_3.0  and it seems that most are focused on changing higher level functionality and some of the underlying _expression_ template tech.  But not necessarily on the basic linear algebra operations .  Is this correct? My worry, of course, is to have to do a port of my library to eigen3 in 9-12 months that involves fundamental changes.  If I stuck to the basic operations in: http://eigen.tuxfamily.org/dox-devel/AsciiQuickReference.txt (with the exception of the solution and eigenvalue routines)  do you expect that I would have few changes when it comes time for a port?

2. I am interested in writing many of my library routines with generic code that would use a subset of operations and could work with various matrix/vector types.  (just the basic opertations for the most part, with no expectation of integration between libraries for a given call)

Since many of the other libraries use free rather than member functions, it would make things easier if those functions existed (e..g. row(A, i)  as well as A.row(i) ).  Is this something people have contributed or is there anything that could make this difficult to develop with no overhead?  If there is no impediment, it is something I could contribute on my own using basic SFINAE if it is allowed in the library.  I think a lot of people would find this a natural alternative API.

3. I am interested in writing a lot of routines that would have the option of using the boost numeric bindings traits (see https://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric/bindings/traits/ and http://lists.boost.org/MailArchives/ublas/2009/11/3854.php ).  Mostly, this involves creating a set of traits classes that enable interoperability with bound LAPACK, MUMPS, etc.. routines and partially solves the problem described in (2.).

Has anyone implemented the traits for eigen2 or see any reason it would be impossible?

Thanks for your help evaluating this superb library.

-Jesse