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*: Tue, 17 Aug 2010 22:15:36 +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; bh=UbbBfDUhrys0R9UZ+8Awvx6PDLKJo3j1TPg/jXGx9Qg=; b=EdfLW3bgIidPeAAVVZ3uumygmHBj57fPm12Rr+X5mZXm9FbglT4D98uvvbpe9CRPEK 7itfMunmnfUG62PD56ZU6B/rhJl2qKHWmhatBl1Ww+dkFU0Z4fYQ+0PUU1GEU+7O9zFD vIlArAOurd/QgliJShDFjhuH0aPt4DsUYT4NE=*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; b=JwCY6BqqPfK5yY7Njwre6z1vH6WrYN7xkEN40f5LLZ2k9KrdkgC44opgpjfNaBJjhU k3zxs7vQTJNPpwZG9NT8Z3jiG99QZIV3fzzISIuWbrBjDiYmpAbQcGzc6ZYE+RG+re3c IeJQ+htIcz8kU4f8AwmVUoL9oFgCDxVK4l04o=

I looked into the remaining transformations and there seem to be some bugs hidden which are not exposed by our unit tests. Maybe some of them or only because of my changes. First, on thing I recognized. You consider any fixed size (Dim)x(Dim) or (Dim+1)x(Dim+1) matrix as a linear and generic transformation respectively. Therefore, we have the following special product paths for Transform 1) T * linear matrix => T 2) T * generic matrix => Projective Both are violated in case the RHS matrices are not invertible. Rule 1) is on top violated, in case the "linear" matrix is not orthogonal and applied to an Isometry. For these paths, my suggestion is to prohibit case 1) completely. I think the functionality is well covered by T.linear() *= linear matrix For case 2), I would choose to simply return a matrix. This is mathematically more sane and in case your are dead sure, what you are doing, you can still do T * Projective(generic matrix) T * Affine(generic matrix) etc. This is even better because it will not necessarily end up with a projective transformation. It is also more explicit (the ctors are explicit) and leaves no option for interpretations as to what is actually happening. The next issue - and this maybe newly introduced by me - is that currently Transform<Scalar,Dim,Projective> * Matrix<Scalar,Dim,Dynamic> compiles. The chosen implementation path is wrong because it assumes Affine or Isometric times set of points and even if we agreed upon extending the RHS matrix by 1s as their homogeneous coordinates, we were suddenly required to return something homogeneous. Let's quickly take a look at what kind of point transformations we currently allow for Affine and Isometry: a) T * Matrix<Scalar,Dim,Dynamic> b) T * Matrix<Scalar,Dim,1> c) T * Matrix<Scalar,Dim+1,1> On top, we allow for Projective d) T * Matrix<Scalar,Dim+1,Dynamic> I would propose to allow d) for Affine and Isometry too. It is mathematically perfectly valid and would simply leave the homogeneous coordinates untouched. Currently, the only issue is that we allow T * Matrix<Scalar,Dim,Dim> --> T T * Matrix<Scalar,Dim+1,Dim+1> --> Projective as discussed above. In case we do what I proposed, the ambiguity were resolved and we could allow d) for all transformations. Here is the summary of allowed transforms as I suggest to offer them - the asterisk is a wildcard for anything. // this is all for projective Matrix<Scalar,Dim+1,*> = Transform<Scalar,Dim,Projective> * Matrix<Scalar,Dim+1,*> // these for Affine, AffineCompact and Isometry Matrix<Scalar,Dim+1,*> = Transform<Scalar,Dim,Affine> * Matrix<Scalar,Dim+1,*> Matrix<Scalar,Dim,*> = Transform<Scalar,Dim,Affine> * Matrix<Scalar,Dim,*> What do you say? The changes are easy and they will reduce code and template instantiations, make our code more safe and more easy to understand -- for the user and devloper. - 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

**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:*Hauke Heibel

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

**Re: [eigen] Do we need geometry refactoring?***From:*Gael Guennebaud

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Getting to a solution from sparse matrices, Eigen3** - Next by Date:
**[eigen] Eigen 2 alignment errors in VS2010** - 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/ |