Re: [eigen] about Transform API

["Thomas Vaughan" <tevaughan@xxxxxxxxx>]

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