Re: [eigen] Euler-angles and partial reductions API design |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Euler-angles and partial reductions API design*From*: Benoît Jacob <jacob@xxxxxxxxxxxxxxx>*Date*: Fri, 18 Jul 2008 23:10:22 +0200

I agree with you that operation on the right should be the default, as it's what OpenGL does. Whence the naming used in Eigen1. What I don't understand is how this is any issue in Eigen2 and the draft eulerangles API ? I mean, when you write rotationX(angleX) * m it's obviously multiplying m on the left; in Eigen1 or OpenGL it's more problematic because of the API not using natural math notation. I don't think we should support degrees at all, radians are the natural unit of measure, period. If the user wants degrees it's not our job to do the conversion for him. The idea that I like best, among the ones you propose, is static MatrixBase::rotation{XYZ} functions. Let's not use functor classes unless needed, and I don't see the need here. Indeed a EulerAngles class is needed because if rotation{XYZ} returned a matrix then doing rotationX(angleX)*rotationY(angleY)*rotationZ(angleZ) would be terribly inefficient. So rotation{XYZ} returns a EulerAngles object and the actual rotationation matrix is computed in operator= or EulerAngles::operator*(vector) (yes this lends itself very well to optimization and suddenly I think this could be the most useful use case for EulerAngles). I'm not a fan of the last option with typedefs, because "Xf" means dynamic-size-float so at least the naming is misleading (and as I said I prefer functions over short functor classes anyway). There is one thing that needs to be discussed. The whole point of EulerAngles is performance -- otherwise we could do as in Eigen1, i.e. do only a generic rotation(angle,vector) method. In many cases, the user will use only one eulerAngle, i.e. Matrix3f::rotationY(pi/12) * vector We don't want the EulerAngle::operator* to compute three sin/cos pairs when only one is needed! So the EulerAngles class is not so trivial to implement, There are up to 7 cases to handle, X, Y, Z, XY, YZ, XZ, XYZ, it looks a bit tedious. It might be possible to avoid the tediousness at zero overhead using template magic, but that is probably even more cumbersome to write! Cheers, Benoit On Friday 18 July 2008 02:00:15 Gael Guennebaud wrotationatione: > I agree Euler angles are somewhat useless (and might even be dangerous > for the beginners because of their apparent simplicity). Nevertheless > they remain really conveniant to specify/initialize the orientation of > an object as a concatenation of elementary rotationationations. In this context > I think it very important to be able to specify the order, otherwise > we completely miss the convenience point. So if we agree this is the > only use case, then we can drop the EulerAngles class, and provide and > alternative, more explicit and generic API. Actually currently it is > possible to mimic the proposed: > > Matrix3f m = EulerAngles<float,XYZ>(1,2,3); > > by > > Matrix3f m2 = AngleAxis<float>(1, Vector3f(1,0,0)) > * AngleAxis<float>(2, Vector3f(0,1,0)) > * AngleAxis<float>(3, Vector3f(0,0,1)); > > that is a bit heavy (though quite often 1 or 2 elementary rotationationations > are enough to reach the desired orientation). > So what we could do is to make easier the creation of elementary > rotationationations using either: > > * static functions of Matrix: > Matrix3f m = Matrix3f::rotationationX(1) * Matrix3f::rotationationY(2) * Matrix3f::rotationationZ(3); > > * super short classes inheriting Matrix<Scalar,3,3> (or global functions) > Matrix3f m = rotationationX<float>(1) * rotationationY<float>(2) * rotationationZ<float>(3); > > * the same with typedef (or alias): > Matrix3f m = rotationationXf(1) * rotationationYf(2) * rotationationZf(3); > > I have to say I like this last option, though someones might find the > names not explicit enough ? it might also be confusing with the "rotationation" > vector operator (curl) ? > > gael. > > On Thu, Jul 17, 2008 at 8:00 PM, Christian Mayer <mail@xxxxxxxxxxxxxxxxx> wrotationatione: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Gael Guennebaud schrieb: > >> Let's start with the EulerAngles class of the geometry module. [...] > > > > Apart from the fact that EulerAngles are quite useless for real work I > > can understand that beginners usually want them to get a quick start... > > > > Generally it's best to keep the libaray as small and generic as possible. > > > > So I'd offer only one function that generates the rotationationation matrix. This > > function should have a fixed order (that's identical to OpenGL - > > although I didn't find a gl, glu or glut function that uses euler > > angles...). > > > > If the user wants a left or a right multiplication is totally up to him, > > so the library should try to be smarter :) > > > > CU, > > Christian > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > iD8DBQFIf4itoWM1JLkHou0RCD8LAJ0fLw/XfnBezR5i43q4Izln9Hy0VgCfZGDr > > dXdk5TfQ8eSvSDRjtxzFuWU= > > =JZq/ > > -----END PGP SIGNATURE-----

**Attachment:
signature.asc**

**Follow-Ups**:**Re: [eigen] Euler-angles and partial reductions API design***From:*Gael Guennebaud

**References**:**[eigen] Euler-angles and partial reductions API design***From:*Gael Guennebaud

**Re: [eigen] Euler-angles and partial reductions API design***From:*Christian Mayer

**Re: [eigen] Euler-angles and partial reductions API design***From:*Gael Guennebaud

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Euler-angles and partial reductions API design** - Next by Date:
**Re: [eigen] Euler-angles and partial reductions API design** - Previous by thread:
**Re: [eigen] Euler-angles and partial reductions API design** - Next by thread:
**Re: [eigen] Euler-angles and partial reductions API design**

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