[eigen] Evaluator design

[Jitse Niesen <jitse@xxxxxxxxxxxxxxxxx>]

Hello,

It's great to see so much action going on around Eigen. It does mean 
however that my recent comment on bugzilla may not have been noticed. It's 
about a mechanism in evaluators for the case when we want to evaluate the 
matrix in one go instead of coeff-by-coeff (e.g., most matrix products). 
See http://eigen.tuxfamily.org/bz/show_bug.cgi?id=99#c33

Now I'm thinking about implementing the product evaluator, and I've come 
across a problem. Currently, part of the evaluation of products (of 
dynamic-size matrices) is in ProductBase::evalTo(), which is implemented 
as follows; see Core/ProductBase.h:117

   dst.setZero();
   scaleAndAddTo(dst,Scalar(1));

In the current implementation, *this (the product being evaluated) and dst 
are expressions. In the new design, *this and dst are evaluators 
corresponding to the product and the destination where it will be stored. 
The question is now: how do we do the equivalent of dst.setZero() ?

This is just an example. Similar issues will surely arise in other 
evaluators with complicated functionality.

These are the possibilities I can think of:


1. Implement a .setZero() member function for evaluators.

Disadvantage: Duplication of code and effort. Remember that this is not 
only about .setZero(); there is probably a lot of other functionality that 
is convenient to have in evaluators.


2. Build a CwiseNullaryOp expression corresponding to the zero matrix, 
construct the corresponding evaluator, and use this to implement the 
necessary functionality.

Disadvantage: Writing evaluators is getting much more difficult, since we 
have one API using expression objects for 'normal' Eigen programming and a 
much more restricted API using evaluator objects for internal programming. 
It's also not clear to me how to actually use the zero matrix evaluator; 
remember that in the current design an evaluator does not know the size of 
the matrix / array.


3. Have the product evaluator store the expression objects corresponding 
to the product, and give it the expression object corresponding to dst.

Disadvantage: This leads to much tighter coupling of expression objects 
and evaluator objects. I think we decided earlier that we do not want to 
store expression objects in the corresponding evaluator.


4. Change the design in some other way.

Disadvantage: I do not see how.


Any preference? To me option 3 looks the best at the moment.

Cheers,
Jitse