Re: [eigen] about Transform API

[ Thread Index | Date Index | More Archives ]

On Wed, Aug 27, 2008 at 9:32 AM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> in my imagination, Scale and Translation would be new types with
> appropriate operator *... Internally they would store a Vector.
> An example:
>  Translation() * v;
> will actually be compiled to a single vector addition ! (That means
> that Translation really means TranslationTransform and not
> TranslationVector)

Oh, I see!  That's a bit more complexity in the library source, but it's
more efficient.

> explicit constructors from vectors will also be part of the game. In
> particular I don't want to enforce people to use these classes to
> store their translation vectors or non uniform scaling factors (see
> the story about Point vs Vector).

Yes, yes.  I know.  :^)

> So one could use these classes only to "type" their vector/array to
> create a Transform object:
> T = Scale(a_vector_considered_as_a_generic_array) *
> Translation(another_vector_which_here_makes_more_sense_to_use_a_vector);

Your Translation type naturally takes a displacement vector in the
constructor.  :^)

> so currently we have 1.75 pts versus 0.25 .... yeah, I count myself
> for 0.75 in favor of that idea, 0.25 against because I'm a bit afraid
> that will lead to the same unnecessary mess as having a Point type

For the Point type there is the inconvenience of converting to
displacement vectors (from a particular origin Point) when there is a
large number of Points.

I don't see an analogous drawback in the usage of this Transform API.

That is, I thought that we had established that the implementation of
Point was not really the problem, but that the usage of the library
would be difficult in some circumstances.

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

Mail converted by MHonArc 2.6.19+