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

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/1/3 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?

Yes, 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?

Yes, there would be few changes.
The basic linear algebra operations syntax doesn't change. The thing
closest to this that will change, is coefficient-wise operations with
cwise().

> 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.

We don't have this at the moment, but nothing prevents you from
writing your own, there is no difficulty here.
Just look at the file MatrixBase.h where all these methods are
declared, it is then straightforward to write inline global functions
wrapping them.

We do not have plans to include this in Eigen itself; not that it
would cost anything besides maintainance, but I don't think there's a
single API to implement that would satisfy everybody, so I would
rather expect that people who need it code their own; but nothing
prevents you from creating your Eigen fork on bitbucket.org and
creating a new unsupported module there, and then we'll see how many
people find it useful.

> 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?

I haven't heard of that, but at first glance, this seems perfectly possible..

Cheers,
Benoit