Re: [eigen] Evaluator design

[ Thread Index | Date Index | More Archives ]

On Tue, 3 Jul 2012, Gael Guennebaud wrote:

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

That's okay. I look forward to your ideas. I don't care if it invalidates some of the work I'm doing now; I expect that my initial attempts will make any further changes much easier to implement.

There is at least one design change related to 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.

I quite like the idea of having an Assign expression (templated by a functor as you see) which goes to the same cycle of building an expression tree, then optimizing the tree, and then evaluating it. This seems to be an easy way to implement D = A + B*C --> (D = A) += B*C and related optimizations.

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

Actually, yes, that is quite a good solution to this particular problem. Much simpler than any I had in mind. Rather embarrassing that I hadn't thought of it myself.


Mail converted by MHonArc 2.6.19+