Re: [eigen] RotationBase times DiagonalMatrix |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] RotationBase times DiagonalMatrix*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Thu, 22 Sep 2011 02:32:37 -0400*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=EUYxnsv7iIeGEo0RKuK5WMlMslyO1O39zwvlseXPKUw=; b=KKGEx2jCZ5wJxMi08EwUjsnn9KszLnx/ud7/Liu1WgTL6KXhriU2R6lG34VMNpIGJd MPMml4UzVPzP8ouWmPJFmxefN4DXB35MgUa+JNFvAXKo7UwsFcrMgdvkwxC1hViPoCG5 m/AAwgrA5ivvN6r32WsITSWUeahy62JK1eZXM=

Oops, sorry I forgot again :-( I'm at a Khronos meeting this week, but I will try to review it asap... unless Gael beats me to it. Benoit 2011/9/22 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>: > Sorry guys, > > but I wanted to bump this thread since it seems to fall asleep and it > would be great to get some feedback. > > If you are too busy to make such reviews I will simply start creating > a fork, from which you then may pull ... > > I am even fine, if we come to a negative conclusion regarding my > proposals as long as we manage to get to some decision. > > Regards, > Hauke > > On Tue, Aug 9, 2011 at 8:48 AM, Hauke Heibel > <hauke.heibel@xxxxxxxxxxxxxx> wrote: >> Hi Benoit, >> >> welcome back. :) >> >> On Tue, Aug 9, 2011 at 7:25 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: >>>> inline Transform<Scalar,Dim,AffineCompact> operator*(const >>>> DiagonalMatrix<Scalar,Dim>& s) const >>>> { return Transform<Scalar,Dim,AffineCompact>(*this) * s; } >>> >>> My problem with this solution is that the product of a rotation times >>> a diagonal matrix is still a linear transformation, so why return a >>> Transform which is specifically an affine (not linear) transformation? >>> I'm in favor of using plain matrices everytime that a plain, arbitrary >>> linear transformation is meant. >> >> I see what you mean and when Affine transformations were allowed to be >> implicitly constructed from any Dim x Dim matrix that were a perfect >> solution. >> >>> Ah OK, I see. It doesn't compile with a) because the assignment in the >>> declaration is interpreted as construction, so it tries to use the >>> constructor (taking EigenBase) instead of operator= and fails as it's >>> an explicit constructor. >> >> Exactly. >> >>> That's really stupid :-/ C++ is able to convert "T a = b;" into "T >>> a(b);" only to fail when the constructor here is explicit. But if one >>> writes T a(b); or T a; a=b; then the error goes away. >> >> I think that behavior is perfectly fine. The question is why at all allow >> >> T a; a=b; >> >> while declaring the ctor explicit!? That's a little bit of a >> contradiction. From what I understand the reason Gael implemented it >> like this is to prevent the creation of hidden temporaries but I am >> not sure anymore whether this preemptive optimization step is useful. >> Is there at all a measurable performance penalty for these little >> stack objects? >> >>> I'd say that's a problem with C++ itself and I see only two approaches: >>> - either live with that and tell Eigen users to use A a(b) instead of >>> A a = b when the class A has an explicit constructor >> >> The syntax becomes really ugly. My colleagues and me are working since >> 4-5 weeks extensively with the Geometry parts of Eigen and just one >> example is writing and using functions that take Eigen::Transform<...> >> as an input parameter. You cannot pass an Eigen::Translation, you >> cannot pass Eigen::Scaling, all due to the explicit constructors. In >> these cases, I really want would love to have the explicit conversion >> capability which would make the code much more readable at the cost of >> a few extra bytes wasted when converting an Eigen::Translation into an >> Eigen::Transform. >> >>> - or stop making constructors 'explicit', consider that C++ language >>> feature flawed: it doesn't work nicely with C++'s >>> convert-assignment-to-construction rule >> >> I still think explicit does exactly what it is meant to do. The only >> question is whether we really want it in this case. >> >> Regards, >> Hauke >> > > >

**Follow-Ups**:**Re: [eigen] RotationBase times DiagonalMatrix***From:*Benoit Jacob

**References**:**Re: [eigen] RotationBase times DiagonalMatrix***From:*Hauke Heibel

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] RotationBase times DiagonalMatrix** - Next by Date:
**Re: [eigen] RotationBase times DiagonalMatrix** - Previous by thread:
**Re: [eigen] RotationBase times DiagonalMatrix** - Next by thread:
**Re: [eigen] RotationBase times DiagonalMatrix**

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