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*: "Thomas Vaughan" <tevaughan@xxxxxxxxx>*Date*: Fri, 22 Aug 2008 09:34:22 -0600*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=qzYs5ExBSjmcuROf/9/WrdqkAH7KLi9kzltC3pUadmk=; b=p4ZudLMn+/1Ce3hpiYrVjJlgS6M/V+8eduogZvw8fAJVsLDKnwQppUB/SNWs0tgRZL brUn+FutOfa7SpD51XJ0QdYSnDiX9/lHlJh++M+gPxh7Lo5aJMoUKDkgfoguCLD6eUUY Xo5/MyV1z6Nm3QfcCgapzDhFsIMlazF/6q7Vk=*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=IyTLAxcaOtotYSX2XvMtyv47HykDnSnoOXfnkyIUmHubsB68gCZjIazYQv/TtYFN1G I84yNlHr3B1S83Un4Hc3c++ni6QdIJ5xYQE6NNHErg3i+6YXatBkqNJ+103JjaRWGRMX tIYDzfxVn3yYjIQhxjpqIX3EIKUGosKcx1++A=

On Fri, Aug 22, 2008 at 7:09 AM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote: > > Thomas Vaughan wrote: > > > > 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. I'm having fun trying to express my motivation for this. I know that you probably get it by now, but this is a neat way to see it: A transformation can be equivalently interpreted either (a) as modifying the orientation of a vector in space (or the location of a point in space) while the underlying coordinate system remains fixed or (b) as modifying the underlying coordinate system while a vector's orientation remains fixed in space (or while a point's location remains fixed in space). In fact---and I suppose that this really is the main idea---even if one did not define a coordinate system on a space, then still the addition, etc., of vectors is defined, but the addition of points is not. Moreover, one can define the *difference* between two points, even in the absence of a coordinate system, by the displacement vector between the two points. The second interpretation above allows one easily to see that, regardless of coordinate system, the triangle formed by the head-to-tail addition of two vectors is the same. This can easily be seen even in the first interpretation when the linear transformation is orthonormal, but even for an arbitrary linear transformation, there are invariant properties of the resultant triangle. However, if you simple-mindedly "add" two points, in some coordinate system, then yes, you can get a third point, but the shape of the resultant triangle may change drastically if you were first to do a coordinate transformation before you "add" the points together. What you're really doing anyway is adding displacement vectors from the origin of some coordinate system, not adding points. So I suppose that my underlying motivation is to express the idea that what we often think of as an operation on points is really an operation of vectors. And this is a bad habit of thinking. We can of course treat each point as though it were the same as a displacement vector from the origin of a coordinate system, but as convenient as this may be in some circumstances, that thinking can lead to bugs that could be avoided by a library that enforces the proper distinction. My understanding of your reluctance to enforce the distinction is that it is way too convenient to have the freedom to reinterpret a point as a displacement vector at zero notational and computational cost. Caveat emptor. > 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, it would not have to be written that way. Point m = p1 + 0.5*(p2-p1); Still, your point is a valid consideration. I am open to the possibility that what I am suggesting is just practically wrong, too inefficient to implement, or too inefficient to code, but I am using my scheme for some code that does spacecraft orbit and line-of-sight calculations, and it seems not too bad to me. > 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. Oh, I got started thinking about this when I was working on some GL-based orbit-visualization code back in the 1990s. I made some mistakes by transforming one kind of thing as the other. I started thinking that if things were declared properly, then the compiler could stop me from screwing that up. But I've not done as much of that kind of code as others have (I'm only recently starting to do it again), and so I imagine that you are right to point out the practical difficulties of providing the distinction. > It is not a pb to implement, but it would be nightmare to use ! I am still not convinced that this is so. One might just need to think more carefully about what one is doing. That is, to develop different (better, clearer) habits of thought. But perhaps that alone is an argument against implementing the distinction, for even something that is intrinsically better can be extrinsically worse by being different. And my idea might not even be intrinsically better. > > It would be wonderful to make all of the proper distinctions, and it > > would be didactic. > > From my point of view this is the other way round: > when you have to choose between: "T.linear() * a" or "T * a" you have > to understand what you're doing and when you review the code you don't > have to know the type of "a" to predict the result. The argument cuts both ways. In my view, you have "T * a", and the right thing happens. You don't need to know the type of "a". In your view, when you see "T * a", you have to make sure that even though "a" is a vector, it is really standing for a point. > Actually, from my point of view this only adds an unnecessary > complexity, and though I understand your motivations, I think the > current solution is mathematically sound. Hmm. I think that you should consider the fact that, in the absence of a coordinate system, the addition of vectors still makes sense, but the addition of points does not. I do not think that such a consideration should necessarily lead as a practical matter to what I am suggesting, but there is an interesting (and perhaps even useful) bit of mathematical structure that seems absent in your representation. > > In this way, one could put all of one's information about a > > coordinate transformation into an object of type T and then use that > > same object conveniently on vectors and on points without worrying > > about any details. > > yes I understood that ! and I refer to my previous comments stating > this solution is not necessarily as nice as it might look like at a > first glance. Perhaps you are right. > > In the end, I hope that you are at the very least entertained by > > this discussion. :^) > > it perfectly fill the boring parts of Olympics Games ;) Glad that I could be of some use. :^) -- Thomas E. Vaughan There are only two kinds of people; those who accept dogma and know it, and those who accept dogma and don't know it. - G.K. Chesterton

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

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

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