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 17:45:26 +0200*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:content-type :content-transfer-encoding; bh=oH8e5fGyb1PP+HmXD1E1f9UrISpGH9R5pyUKmLHWYx8=; b=Sm3UTfUFppbS6gaMFSz37zcSDMHWZ5GWutEwpBH4AkUx7osCm+GcucJld5bdTQKjTN W1Ih6cAr/wEeYfvSh45ywa/BzCTfQrHlvvgWRA+HZzBUlQN4oVTZu+50Eb78IdRY0VSn We4MTBdsi74cHpsUQHKTqXmnUCfeqm+LlnoXE=*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 :content-type:content-transfer-encoding; b=NeivAXjxnVx9JsOjKZivQ3NfqR7THxuGibOY1vgmgktAaH8F4nJAlO9SsSgC3UEhyb vO9O8EwwHXTlCm7VFZ2LatdyXp4Kruv/eIJzmZix8O3Sf0yBKUt3vScVq8Py/vld0tIc PaYBoPJcYRoa+BEdDZ6m2oFCDV/rYgcUB6hHg=

I'll fix it immediately. On Mon, Aug 16, 2010 at 5:14 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: > 2010/8/16 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>: >> 2010/8/16 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>: >>> 2010/8/3 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>: >>>> On Tue, Aug 3, 2010 at 3:53 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: >>>> >>>>>> - It is unintuitive that the most generic Transformation is affine >>>>> >>>>> Let's focus on this point because it looks crucial to me. The most >>>>> generic transformation is definitely projective, there's no question >>>>> about that, the questions discussed here are: >>>>> a) what should the default value for Mode be? >>>>> b) what should the Transform3f (etc) typedefs stand for? >>>>> >>>>> Obviously, a typedef named "Transform3f" has to use the default mode, >>>>> but at the same time that name "Transform3f" does suggest something >>>>> generic, whence the confusion in this discussion between "default" and >>>>> "generic". >>>> >>>> Right, you nailed it. So, we agree that Transform3f is likely to >>>> suggest something generic. >>>> >>>>> What do you think about this plan: >>>>> - we just remove the Transform3f... typedefs. We just force the user >>>>> to use the mode-specific typedefs such as Affine3f, Projective3f, etc.. >>>>> - we don't give Mode any default value. >>>>> - in the tutorials, we focus (at least at the start) on Affine >>>>> transforms, Affine3f etc, so that the intuitive idea that 3D-transform >>>>> * 3D-vector gives a 3D-vector. Of course we then do explain other >>>>> kinds of transform. >>>> >>>> Sound like a plan. Gael, do you have any opinion? >>> >>> Hauke: the geo_hyperplane test fails to build at the moment, something >>> related to Transform and some matrix not having the right size. This >>> is most probably related to your change, no? >> >> Ah, great, Gael had fixed that already, I should have grabbed the >> newest changes. > > ...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. > > I'm going to write to the list about tightening our commit policy (i'd > like to request that we run all tests before pushing anything, etc). > > Benoit > >> >> The question below about transform() still remains, though. >> >> Benoit >> >>> >>> Also: the Hyperplane::transform() methods are still taking a >>> TransformTraits runtime parameter, which we probably want to get rid >>> of. >>> >>> Benoit >>> >>>> >>>> - 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] Optimization for special complex operations** - 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/ |