3d "compose"?

[truher]

Today I became briefly confused about the difference between Rotation3d.plus() and Transform3d.plus(), imagining that they both meant "compose". Of course Rotation3d doesn't do that, and in 2027 the "plus" method is gone anyway.

But it made me wonder if a consistent "compose" method might be a good idea? It would be an onramp to the ideas of matrix multiplication and the Lie group operator.

I'm aware that reversing the operands would have the same effect, but that doesn't really ameliorate the confusion (to me).

[calcmogul]

Rotation3d.plus() got removed in favor of Rotation3d.rotateBy() since Rotation3d.plus() isn't commutative like Rotation2d.plus(). Renaming Transform3d.plus() to Transform3d.compose() sounds like a good idea since it's also not commutative. Same goes for Transform2d.plus().

I'm not a fan of providing Rotation3d.compose() because it implies an argument symmetry that doesn't exist. I also prefer the more descriptive name.

Now that I think about it, maybe Transform3d.plus() should be renamed to Transform3d.transformBy().

[truher]

Well, I think you mean "replaced" not "renamed"?

x.plus(y) is x * y

but

x.transformBy(y) would be y * x, to match the meaning in Rotation3d.

Wouldn't it?

[calcmogul]

It's confusing:

  /**
   * Composes two transformations. The second transform is applied relative to the orientation of
   * the first.
   *
   * @param other The transform to compose with this one.
   * @return The composition of the two transformations.
   */
  public Transform3d plus(Transform3d other) {
    return new Transform3d(Pose3d.kZero, Pose3d.kZero.transformBy(this).transformBy(other));
  }

That's why I want plus() gone.

The current intended API usage uses plus() to mean transformBy(), so x.plus(y) means y * x in transformation matrix speak. The plus() and minus() thing is a holdover from when rotation happened to be commutative in 2D, but it doesn't extend to 3D.

[truher]

Adding to my confusion, GTSAM uses the right-hand convention, which I think is opposite what you're saying here, i.e. X.compose(Y) is XY, not YX.

Is that right?

https://github.com/devbharat/gtsam/blob/master/gtsam/geometry/Rot3M.cpp

[calcmogul]

Yea, that's not how transformation matrices usually work.

[auscompgeek]

If we make the + overloads disappear (which I also agree is a good idea), we should probably consider overloading the matrix multiplication operator (@, __matmul__) in Python.