[eigen] Evaluator design

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


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


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.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/