Re: [eigen] Do we need geometry refactoring? |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Do we need geometry refactoring?*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Mon, 16 Aug 2010 16:04:04 -0400*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=LCUj+M71zePP/sgOqTL95fal5GhysJnHz0c67b7ar0w=; b=VsTI4S/2Xe2mbQU9Vs0LJ38QJonj3CsWpeBThGGbDWL12VLO2vPWimraVckKxzI2N1 Gj1453Jh9+YozkoEhIa2lqKcbtXIvQlul/1gbckCUXzi8poHN4TT62LnppGW522qgHhd P1AI5Qm6683nPbjiFYKRf7xIJfyPGg9rffrrU=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=gdu6VFFhUJo+rXSIVTB0CMM3bfiW8pO4K+PnFtKSoFHI9fWXEZVlAKDo4yYEb7JDjo dVk4JQdv6sVvDdMi7PMLSDjkClhDN2leWkcpfAzq0fjl4XTmGUV8+WTAN45n6RFKAcE7 LTB/1c29nDS5rAKoeSaDXA2jHgWI5ER0YDJyk=

> 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.>> ...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.

But it doesn't have to make a big difference, you can always write and use:

template<

int LhsMode,

int RhsMode>

struct ei_transform_product_result_mode

{

int ret = (LhsMode == Projective || RhsMode == Projective) ? int(Projective)

: (LhsMode == Affine || RhsMode == Affine) ? int(Affine)

: int(AffineCompact)

};

Benoit

**Follow-Ups**:**Re: [eigen] Do we need geometry refactoring?***From:*Hauke Heibel

**References**:**Re: [eigen] Do we need geometry refactoring?***From:*Manuel Yguel

**Re: [eigen] Do we need geometry refactoring?***From:*Hauke Heibel

**Re: [eigen] Do we need geometry refactoring?***From:*Benoit Jacob

**Re: [eigen] Do we need geometry refactoring?***From:*Hauke Heibel

**Re: [eigen] Do we need geometry refactoring?***From:*Benoit Jacob

**Re: [eigen] Do we need geometry refactoring?***From:*Hauke Heibel

**Re: [eigen] Do we need geometry refactoring?***From:*Benoit Jacob

**Re: [eigen] Do we need geometry refactoring?***From:*Benoit Jacob

**Re: [eigen] Do we need geometry refactoring?***From:*Benoit Jacob

**Re: [eigen] Do we need geometry refactoring?***From:*Hauke Heibel

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Do we need geometry refactoring?** - Next by Date:
**Re: [eigen] adopting a slightly more strict commit policy** - Previous by thread:
**Re: [eigen] Do we need geometry refactoring?** - Next by thread:
**Re: [eigen] Do we need geometry refactoring?**

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