[ Thread 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).
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
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.