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

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

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