Re: [eigen] Eigen appears to rock.

["Gael Guennebaud" <gael.guennebaud@xxxxxxxxx>]

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