Re: [eigen] Evaluator design |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Evaluator design*From*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Tue, 3 Jul 2012 20:20:04 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=+o1LbtmHcfejF8geCK9Ccs0IDsolCoOMU/zKRSCIf8o=; b=vy1vRFY3GW3+g79XW0qD6YDknmWWK5eDXFyfIZNpbeJ5P44iFeS1A1cuFO1HqpfJOc IphPDXDoGmeq9sliZWavCZHKLoK6i3jsMguPVfs3PYbQmssIEZpnrIs82k2bH6f/wpUn DXhYYJjCaVtQ/19qVtR2rxMDIOCgOpz0Jat71AHHfdzb+69pNRRP8uJXZ00MfWVpfLvn NjlutAb1fjH8ziYM9ZbRGM/06C+DKS/A5zOlV81RvjYov7JKpm1WBOyhk90LPREqHOi/ Xq2tRJIn9PWuUKwASmigyX471/S3KmmhZUVfKBNYRFPK9VngzS3LZrPeIa+n3q+01SXS yjvw==

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 > >

**Follow-Ups**:**Re: [eigen] Evaluator design***From:*Jitse Niesen

**References**:**[eigen] Evaluator design***From:*Jitse Niesen

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Eigens Parallellism** - Next by Date:
**[eigen] NEON PacketMath.h questions** - Previous by thread:
**[eigen] Evaluator design** - Next by thread:
**Re: [eigen] Evaluator design**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |