Re: [eigen] Eigen appears to rock.

["Thomas Vaughan" <tevaughan@xxxxxxxxx>]

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