| Re: [eigen] Evaluator design |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen 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
facing.
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
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.
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.
Cheers,
Jitse