Re: [eigen] Transform products

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

I have to say that i haven't been thinking about that intensely, and
that contrary to you and Keir, these days I am not even a user of the
Transform class (I don't contribute anymore to any user project) so i
just have general uninformed opinions.

2009/2/21 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> I have to say: I'm puzzled!
>
> at least I agree to add homogeneous normalization functions:
>  v.hnormalized();
>  data.colwise().hnormalized();
>  data.rowwise().hnormalized();
> (for the name feel free to suggest something different)

The name sounds good to me (I don't remember suggesting that but that
sounds like a good idea!)

> and then a "projective transform" * "set of non homogeneous vectors"
> would not perform an automatic normalization, but return homogeneous
> vectors. Then it is up to the user to normalize the result.

Can we make sure we mean the same thing by "homogeneous vectors " and
"non homogeneous vectors" ?
homogeneous : size d+1
non homogeneous: size d

Then yes, I agree with your suggestion. projective *
any_vec_homogeneous_or_not returns homogeneous.
Indeed, normalizing the result is not always possible, only the user
can know if it's possible, so leave that up to him.

> I'm not fan of the "as homogeneous" expression because it would
> require a if inside coeff,

Good point.

> but since it might be removed by the
> compiler, why not...

Indeed there's a risk it will not always be, depending on storage
order, in batch operations on a dynamic number of vectors...

>  I think that's better to make Transform good
> enough so that such an expression would not be needed. And by the way,
> currently you can do:
> VectorType v;
> HVectorType hv;
> // ... work with v
> // then you temporally need an homogeneous vector:
> hv << v, 1;
> // use hv

This solution has the other problem that a useless copy of v is performed.

I think, the best solution then might be to make asHomogeneous()
return a proxy, not an expression. It would be used just to resolve
overloading of operator*. I.e. we'd have a Transform*HomogeneousProxy
that would take the vector inside the proxy and continue with a "1"
for the last component.

> About splitting the current Transform into 3 versions... well that
> would probably be ideal, but this would significantly increase the
> number of product combinations... I still have to think about it.

It could end up in more lines of code but that code would also be
simpler, each class having its own separate meaning, and requiring
less template logic.

But if you prefer you might save some LOC's by making it just a single
class Transform with a template parameter (which then should default
to "affine transform stored as big matrix" for optimal compatibility).

Cheers,
Benoit