Re: [eigen] Do we need geometry refactoring?

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


On Mon, Aug 16, 2010 at 5:14 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> ...except that the tests are still failing at runtime,
> geo_transformations_1:
> /home/bjacob/eigen/Eigen/src/Geometry/Transform.h:246:
> Eigen::Transform<Scalar, Dim, Mode>::Transform(const
> Eigen::Transform<_Scalar, Dim, OtherMode>&) [with int OtherMode = 32,
> _Scalar = double, int _Dim = 3, int _Mode = 2]: Assertion
> `OtherMode!=Projective && "You cannot directly assign a projective
> transform to an affine one."' failed.

Ok, I can't finish this today, since I have to leave.

One of the problems seems to come from the definition of
ei_transform_transform_product_impl in line 1299 (approx.) in
Transform.h. The template looks like this

  template<typename Scalar, int Dim, int LhsMode, int RhsMode>
  struct ei_transform_transform_product_impl { ... }

and the ResultType is solely depending on LhsMode where I assume that
this is wrong. I did not yet quite look into all details such as
ei_transform_right_product_impl but I think we need something like
this

  template<int ModeLhs, int ModeRhs> struct
ei_transform_product_result<TMode,TMode> { enum { Mode = ... }; };

I am wondering whether there is a simpler way but to specialize for
all combinations. Maybe someone of you has immediately an idea how to
simplify this. Benoit wanted to prevent relying on the Mode, otherwise
I would have suggested

  Mode = ModeLhs > ModeRhs ? ModeLhs : ModeRhs;

but that is not really nice.

- Hauke



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