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

[Benoît Jacob <jacob@xxxxxxxxxxxxxxx>]

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
Description: This is a digitally signed message part.