NewKindr : Names ...

[HannesSommer]

Let's try to find proper names for rotations to use it in the implementation of the core functionality of NewKindr:

We are seeking the name for the base class of all things that do rotate / or rotate and translate, purely having the purpose to specify the interface of something that rotates or rotates and translates, but without thinking of frames or any other modeling or physical related notion (to not have to interfere with different ways of thinking about aka active vs. passive).

Candidates, I see right now:

1. For pure rotations in 3d:
   1. SO3,
   2. Rotation3 or Rot3,
   3. ProperRotation3 or PRot3
2. For pure translations in 3d:
   1. T3
   2. Translation3 or Trans3,
3. For combinations of 1. and 2.
   1. SE3
   2. Isometry3 or Iso3
   3. Transformation3 or Trafo3

Please feel free to add some candidates.

I think we (or who is interested) also should discuss the naming for the primary action of these (yes we can have operators overloaded for them but we also could/should have names), which would be either specifically called like rotate or or more generically : apply, act, operate.

In some kind of correspondence to the interface names above, but that is only quite loosely coupled :

1. pure rotation:
   1. act, operate, apply
   2. rotate
   3. rotate
2. pure translations
   1. act, operate, apply
   2. translate
3. mixtures
   1. act, operate, apply
   2. act, operate, apply
   3. transform

As overloaded operators we have as candidates probably only:

1. operator ()
2. operator *

Why translations (for those who like to know or to not have them there):
I would like to have them and would also implement them (almost no work), because from a conceptional point of view they they are just one third of the whole story about SE3. And they are crucial to conceptually well understand SE3 and the relation between SO3 and SE3 because

SE3 = SO3 * T3 = T3 * SO3,

where * is pairwise concatenation.

Please don't oppose them just because you would not need them: they won't interfere! And no, they are not the same as vectors (Vec3). Vectors are the usual implementation for the translation, like the rotation matrix for a rotation / a SO3 element. And vectors are also the things all those operations (rotation and translation and combinations of both) do operate or act upon! So for example a rotation does compose or concatenate with a translation (resulting in a mixture!) but acts or operates on a vector! So it is something different. Not properly understanding the difference is probably one important reason for a lot of confusion in that area. This essentially means that rotate would still get a Vec3 as argument and not a translation!

[HannesSommer]

I would vote for:

SO3, T3, SE3, apply() and operator ()

[furgalep]

Hannes. Nice analysis. My vote:

SO3, T3, SE3, apply, operator*

Everything gets a bit easier (less critical) if people can define their own custom interfaces as I propose in #50.

[gehrinch]

I'm fine with those names.
I would only use method apply.

[HannesSommer]

Ah, great. Seems easier than I expected. Then lets go for SO3, T3, SE3 and apply.
operator * I don't like much as apply operator.
Can we have that just for matrices? And operator() for all?
RotVec(a) * v, looks just wired to me.
Of course operator * will be the shorthand for composition in any case.

[gehrinch]

I don't like the operator() for this operation, because the current kindr uses it for conversion between different parameterization.
I also would like to have a constructor for the rotation vector that accepts a Eigen::Vecter3 for parameter initialization (as it is now in kindr).

Operator* looks also strange to me for non-rotation matrices.

[HannesSommer]

Uh, how do you use operator () for conversion? Could not find it on a brief look. Are you talking about cast operators? The operator I'm talking about would be used like:

AngleAxis a;
Vec3 v, w;

w = a(v); // uses operator ()  and would be exactly the same as a.apply(v)

[HannesSommer]

A cast operator would be used well like a typecast:

RotMat C;

double a = static_cast<AngleAxis>(C).getAngle();
// or
double a = AngleAxis(C).getAngle();
// one could also think of support it the Eigen - way.
double a = C.cast<AngleAxis>().getAngle();

[furgalep]

+1 for the .cast<Type>() operator!

[gehrinch]

According to the docu of kindr:

AngleAxisPD angleAxis;
RotationQuaternionPD quaternion(angleAxis); // constructor
angleAxis = quaternion; // assignment operator
quaternion(angleAxis); // parenthesis operator

I would also add the .cast<Type>() operator since most of the students did not understand that they can use the constructor.

[HannesSommer]

Ah, ok, so it does exactly what an assignment would do? (in some direction). I don't think we need that. What was the idea behind it? Is that used a lot?

[HannesSommer]

Ah, for chaining with side effects? I would still vote for assignment (a = b).something(). This would make the side effect much better visible than a(b).something().

[gehrinch]

Well, I don't remember why we implemented the parethesis operator for casting (that did not come from my side). I don't care too much about that, as long as "casting" with the constructor works, because that is something we used a lot: double angle = kindr::AngleAxis(eulerAngles).getAngle();

[gehrinch]

This is too much work for us. We keep it as it is for kindr version 1.0.0.