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*: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>*Date*: Mon, 16 Aug 2010 19:58:49 +0200*Cc*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qg4N0xKHZSxEmWXDgvIT0BnITyb93bPleUhfoEKkJws=; b=Gl6HRzQJwCe5YHPtIP+1FqrEBLnz0pW3uekxeR5XFX3m4QVcIita+oPuBoPp+/DVFI gThA44RWm9vv4QXopqgW2XCm64oq2lQbfVhaliZDV5dSVQd9Mkc5nsrCXWB+KyUfdmCz ttalOWa08cnkKdgg5CgT2tUIUh06oMSRFuhPs=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jiZMBtZcWuINnMTXBrWRexA3W5HTI7ZwKdblC55yIuc1V7QAdxmh3d9NSINYjxuT+b Zms3/BNxixRF4OCB4LUXJBx1c+8l/rTXAgRGM+am7JOVanxiPbXJtvaTyOdRCCGxJPUZ PFa4J/4e5KHH0gc4Moq4ZKk4FUeKnKRETu9EE=

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

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

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] non-linear optimization test summary** - Next by Date:
**Re: [eigen] Do we need geometry refactoring?** - 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/ |