Re: [eigen] Evaluator design

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

Hi Jitse,

sorry, I did not find the time to reply to your post. I just did it.

To be honest I will need some time to catch up and recall all the
details. On my side, I'd like to play a little bit more with the
prototype I developed during the last year meeting to see how it can
be elegantly extended to support all the difficulties your are now
facing.

There is at least one design change related to
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=110 that I'm pretty sure
about: delegate the assignment process to an assign<> struct templated
by the dest and source types, as well as by an assignment functors
covering the following operators: =, +=, -=, etc. Even though I'm
still thinking about the exact design of such functors (it needs to
support both vectorization and swap), this design should permit to get
rid of the ugly SelfCwiseBinaryOp class, and the copyCoeff, copyPacket
functions, and the likes.

Regarding the dst.setZero() issue, I think that the evaluator should
have full access to the object it is evaluating into.

gael


On Tue, Jul 3, 2012 at 4:19 PM, Jitse Niesen <jitse@xxxxxxxxxxxxxxxxx> wrote:
> 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
>
>