> 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.
Yep, so, indeed I don't think it's a good idea to rely
on the particular numerical values of the modes.