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

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