Re: [eigen] news on the refactoring of the expression template mechanism

[Jitse Niesen <jitseniesen@xxxxxxxxx>]

On Fri, 21 Feb 2014, Gael Guennebaud wrote:

> As most of you probably know, since the releases of Eigen 3.0 we
> started a significant refactoring of the expression template mechanism
> under the code name "evaluators" aka "bug99" [1].
> [...]
> This refactoring is much more work than what I expected, but I've 
> reached a state where I think that the rest of the refactoring should be 
> quite mechanical. So I think it's time to describe the new design and to 
> discuss it before going too far.

I had a good look and it seems to work. With products you managed to do 
the most difficult part. The next question for me is whether it works with 
sparse matrices; but since you managed to do diagonal matrices we can have 
some confidence.

It's a bit hard to tell though because there is still quite some 
evaluation logic in the expression objects, so it's quite possible that 
there are still gaps in the evaluators even in the parts of the Core and 
LU modules that appear at first sight to be done.

> To this end I prepared a pdf [3] that summarize the new concepts and
> their true implementation inside Eigen. [...]
> The main purpose here is to start discussions and get some early feedbacks.

The pdf all seems right to me, but I realize it's the details that are 
important here and only actually programming it will make clear whether 
the design is okay or not.

> - Currently, the two mechanisms co-exist via conditional compilations
> (EIGEN_ENABLE_EVALUATORS and EIGEN_TEST_EVALUATORS). This means the
> code is a bit messy. Maybe it's OK to already do a big cleaning pass
> since we have a separate branch anyway?

Indeed, how to continue this? I can see two possibilities:

1. To make sure we get the design right, we can continue in the evaluator 
branch with the Core and LU modules, make sure that everything works, get 
rid of the conditional compilations, remove the dead code from the 
expression objects (e.g., implement expr.coeff() in terms of evaluators), 
refactor, etc. Once we are confident with the design we can continue with 
the other modules.

2. The alternative would be to get all (supported?) modules in working 
order with EIGEN_TEST_EVALUATORS, at least in that the tests pass, and 
then merge the branches. At that point we will probably see a lot of 
issues when people start to use evaluators because our tests are not 
comrehensive.


The problem with 1 is the code duplication due to the two separate 
branches (conditional compilation in the same branch has more or less the 
same issue). It will be difficult to merge the two branches and make sure 
that all bug fixes from one branch are ported to the other branch , and 
the further the branches diverge the more difficult it will be.

Approach 2 avoids this issue, but has the problem that when we want to 
change the design for evaluators, we have to change it in all modules (not 
just Core and LU), which will be much more work.

Of course there are more possibilities, but I feel this is the main choice 
to make. What do you guys think?


Jits