I have been using Eigen for quite a while and really enjoy many aspects of this library.

Now I am considering to use it for serious development of a machine learning/computer vision library, upon which there are many higher level applications.

However, one important issue here is the difficulty of extension. Before I go deep into this issue, I would like to make it clear that I have carefully read the relevant wiki page (http://eigen.tuxfamily.org/dox-devel/To ... Eigen.html) and understanding all what it says.

To be more specific, I am not interested in adding a bunch of new methods to the MatrixBase<> class. Instead, my primary goals here are:

(1) Define my own matrix class with some special internal structure, which it can work nicely with other classes of Eigen. One proper way to do this might be to write a derived class of MatrixBase<> in a CRTP way, implementing all required interfaces. (Note: Deriving from Matrix is not an option here, as my classes may have a completely different memory layout than the dense layout implemented by Matrix.)

What make me feel hesitant to do so is that when I look at the MatrixBase<> code, I found that this class is huge and is not clearly documented. Thus it is not completely clear what I need to implement/override and what are the things I'd better leave as they are.

(2) Sometimes, I would like to implement my own new operator that can be applied to all types of matrices or arrays. This is also not trivial with Eigen. With some efforts navigating through the codes, I managed to figure out how to work with MatrixBase<Derived> as input argument. But what I haven't figure out is what if I want to return a lazy expression instead of an evaluated matrix ? I may develop my own expression class, but what are the interfaces that I need to implement? And how can I control the evaluation of the expression? (In other numeric libraries, e.g. armadillo and NT2, this can be relatively easy to be accomplished by specializing some generic template classes).

So basically, what I desire (and possibly some others who would like to extend Eigen) is a very clear document that states the interfaces and the related semantics. Particularly, they might include

(1) Clear document on the interfaces of MatrixBase / ArrayBase / PlainObjectBase, etc and their semantics.

(2) Clear document on how a Matrix/Array expression class should be defined and implemented.

(3) I think along with the implementation of such class, one may also have to define a trait class. Therefore, a clear document on the trait class (e.g. what should be contained therein) is needed.

The wiki pages did have some high level description, but it is not specific enough to support serious development.

In addition, the trait class is encapsulated in the internal namespace (does it mean that it is subject to frequent changes and the user should not rely on that?) But a lot of important traits (e.g. the scalar type of a Derived class) need to be extracted from those classes. I am using some of such things (subject to the risk of such dependencies may suddenly break after typing in "hg update")

I appreciate the support of the Eigen team provided to the end-user. However, to be frank, the support to the users/developers who would like to develop some serious extensions of Eigen really needs improvement.

(BTW: FLENS seems to do a very good job in this respect, which clearly documents the interfaces for people who would like to develop their own kind of matrices/closures (something like a lazy expression) and make them interact nicely with the library).

Yes, we are totally aware of the lack of developer documentation. One fundamental reason for that, is that we plan to restructure our expression template mechanisms to completely decouple the construction of the expression and its evaluation. Once 3.1 released (should happen very soon), this will be the top priority. A large part of the job has already been done. See this entry http://eigen.tuxfamily.org/bz/show_bug.cgi?id=99 and this wiki page http://eigen.tuxfamily.org/index.php?ti ... _evaluator for more details. After these changes, documenting Eigen's internal will be considerably simpler. Extending Eigen like the way you described will be much easier too.

In the meantime, I'm not sure what's best for you.