Re: [eigen] Eigen appears to rock. |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Eigen appears to rock.*From*: "Gael Guennebaud" <gael.guennebaud@xxxxxxxxx>*Date*: Fri, 22 Aug 2008 15:09:54 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=adlE6f7hmqPzgAclb21LDqRYB5uI3BxdbL7Hmqw68rQ=; b=T/ym+HsenGM2RaebbWnH4297EJ23eYuzT6Z+DRHLvOuPhDLw3ZyEI2aeTcclJlnEoH wUAqr7a8laSgahVGDEEah3WST0p8UDTyhPTFyxM9PnOi+XuXSw/Ngdilhe6MOuwZ8Iv3 eusg3S4VAQBW+GFceqe37IqJyFahlU7ZQiCV4=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=HIGw+fOqW4RrI/WYeY2M83dcpcZmfxKlCKSqdX+4gtPd3FLfQZSn/N2tekuxbYeHDe y+VCNsp23QAG9bC/e1jIbkrQZBZRsdKYNbkLE+4l+JIV6tZqLu1p+dZnxaD+KOi3hY9X Ws1y9PqfWHAI3jH/aPgMRmz4ujOJVW/k2kAMY=

>> T.affine() is the 3x3 affine part of the above 4x4 matrix (it >> represents the rotation + scale + shear) > > This is a bit confusing because an affine transformation in general > combines a linear transformation and a translation. Perhaps it might be > better to make "T*p" be equal to "T.linear()*p + T.translation()", where > "T.linear()" returns the appropriate 3x3 block of the 4x4 inside T. this change has been done ;) >> Now what about distinguishing Point and Vector types ? I have to say >> that I've already used a couple of libraries making such a type >> difference, and every time I ended up with spending my time to convert >> Point to Vector (remove zero) and Vector to Point (add zero), and I >> disliked that a lot. > >> From a practical point of view the only difference between Points and >> Vectors happens when you apply a transformation. > > In my opinion, this thinking is a bit sloppy. > > The addition of two vectors is well defined; after all, vectors are > elements of a linear vector space. Although one can define an > isomorphism from the points in a three-dimensional Euclidean space to > the set of vectors in a three-dimensional vector space, there is no > unique such mapping, and so the addition of points in general is not > well defined. So a proper Point class will *not* have operator+(const > Point&, const Point&). If you try to add two Points, then you should > get a compiler error. Similarly, a simple rotation that can transform a > vector is not defined for a point because the *location* of the axis of > rotation must also be specified. > > There is a load of differences. hehe this serves exactly my point ! By removing the operator+(const Point&, const Point&) here starts the nightmare of using such a library. For instance, if I want the mid point m of two Points p1 and p2: Point m = 0.5*(p1+p2); would have to be written: Point m = 0.5 * ((p1-Point::Zero()) + (p2-Point::Zero())) + Point::Zero(); which version is more confusing ? No really, if you accept that "p = p-0", then you only need Vectors and all operations are mathematically sounds. You only have to take care when you apply a transformation but I cannot imagine any case where this would not be obvious. If you have any real examples where having only Vector is confusing and might lead to bugs I would be very interested. Actually I would even be tempted to say that allowing "T * some_3_component_quanties" to perform different operations is more confusing and then less readable. Currently: "T * a" always performs the same operation, there is no magic, same for "T.linear() * a". >> That means you would not need only 2 different types (Point and >> Vector) but also a third one: DifferentialVector. I cannot imagine the >> nightmare to use a lib which would do that !! > > That's a really interesting point. I did not spend the time to work > through the math, but the idea, presumably, is that the differential > quantity is *not* a vector because it doesn't transform as a vector > transforms. (Also, a tensor of rank two transforms differently from a > vector, which is a tensor of rank one.) In my opinion, we should not > call it a vector if it is not, in fact, a vector. Just as a point is > not a vector. > > I don't see why this would be a nightmare to implement. I think that > the Point class, for example, would not be a nightmare to implement. > It's really rather simple. In my toy version, I just aggregate a > Vector3d and provide the few functions that I've talked about for an > interface. It is not a pb to implement, but it would be nightmare to use ! > It would be wonderful to make all of the proper distinctions, and it > would be didactic.

**Follow-Ups**:**Re: [eigen] Eigen appears to rock.***From:*Konstantin Heil

**Re: [eigen] Eigen appears to rock.***From:*Thomas Vaughan

**Re: [eigen] Eigen appears to rock.***From:*Thomas Vaughan

**References**:**[eigen] Eigen appears to rock.***From:*Thomas Vaughan

**Re: [eigen] Eigen appears to rock.***From:*Benoît Jacob

**Re: [eigen] Eigen appears to rock.***From:*Thomas Vaughan

**Re: [eigen] Eigen appears to rock.***From:*Gael Guennebaud

**Re: [eigen] Eigen appears to rock.***From:*Thomas Vaughan

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] some problems with building with AltiVec enabled** - Next by Date:
**Re: [eigen] Eigen appears to rock.** - Previous by thread:
**Re: [eigen] Eigen appears to rock.** - Next by thread:
**Re: [eigen] Eigen appears to rock.**

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