|Re: [eigen] Eigen appears to rock.|
[ Thread 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
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
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
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.