Re: [eigen] Cumbersome syntax questions/feedback

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

Hi Staffan,

On Sun, Aug 16, 2009 at 2:11 PM, Staffan Gimåker<staffan@xxxxxxxxxx> wrote:
> Hi guys,
>
> After converting to Eigen in a couple of work projects (mobile robotics
> stuff), and being very happy with the results (great job! :), I've
> started to convert an open source project of mine to Eigen as well
> (http://www.peekabot.org). However I ran into some minor troubles with
> cumbersome syntax -- some questions/feedback below.
>
> First, I dabbled with replacing our own rudimentary Matrix4f class used
> for affine coordinate system transformations with Eigen::Transform3f.
> Works wonderfully, but expressions involving inverse() becomes a bit
> cumbersome (I'm using 2.0.4):
>
>  Eigen::Transform3f A, B, C;
>  ...
>  C = A.inverse() * // doesn't compile, inverse() returns a matrix type
>      Eigen::Translation3f(...) *
>      Eigen::AngleAxisf(...) *
>      Eigen::Translation3f(...) *
>      B;
>
>  C = Eigen::Transform3f(A.inverse()) * // works, but a bit cumbersome
>      Eigen::Translation3f(...) *
>      ...
>
> What's the reason that Transform3f::inverse() returns a matrix type
> rather than a transform type?

yes, that's weird that Transform::inverse() returns a Matrix and not a
Transform. This also surprised myself recently while it is probably me
who right it. Unless someone can refresh why it should return a
Matrix, I'm willing to change that (in both branches)

> Looking for a less cumbersome syntax I tried to use Eigen::Matrix4f
> instead, but ran into a similar issue:
>
>  Eigen::Matrix4f A;
>  ...
>  A = A * Eigen::Translation3f(...).matrix(); // error, no such method
>
>  A = A * Eigen::Transform3f(Eigen::Translation3f(...)).matrix(); //
> works, but a bit cumbersome to use
>
> Any special reason that Translation3f and friends doesn't have a
> matrix() method? Or am I doing something plain wrong here?

hm, here you should really use the Transform class. We cannot have a
..matrix() class because we don't know what the user want. E.g, for
Translation shall we return a Dim+1 x Dim+1 matrix, or a compact Dim x
Dim+1 matrix ? For Scaling we could also return a Dim x Dim matrix.
Furthermore, Transform internally stores a Matrix, so the matrix()
function is free, while converting a Translation to a Matrix is not
free and costly to use. For instance, Transform3f * Translation3f is
compiled as a Matrix33 * Vector3 product that is something the
compiler cannot do by itself.

gael.

> It's nothing I can't cope with, but in an ideal world the syntax would
> be a bit less cumbersome :) I guess the above "workarounds" might
> involve some unnecessary temporaries as well.
>
> A reason to justify the current syntax would be greatly appreciated
> (maybe that could be put in the documentation as well).
>
>
> /Staffan
>