Re: [eigen] Eigen and rigid body simulation

[Mathieu Gautier <mathieu.gautier@xxxxxx>]

> However, if you want to design an algorithm that works for any Lie 
group (like
> interpolation, blending, averaging, and what not), then it might be 
convenient
> to abstract out the specifics of each class, which is what the 
wrapper/concept
> map stuff does. It will give you a coherent, convenient, and 
non-intrusive
> view over existing data types for implemening *generic* algorithms.

I agree with you, my suggestion goes in this way, since I only propose 
simple operation (such as composition, exp, log, etc.). I don't want all 
methods (interpolation, etc) to be part of such classes. I think that it 
will be easier for users to manipulate such classes than a wrapper 
(especially in simple case, where the mathematical stuff are hidden).

So I can write (almost like you as wrote):

template<class G> LieGroup<G> fastExp(const LieGroup<G>& g, unsigned int n){
  if(n==0)
    return LieGroup<G>::Identity();

  if(n%2)
    return g*fastExp(g*g,n/2);
  else
    return fastExp(g*g,n/2);
}

>
> But say for example i'd like to interpolate rigid transforms or 
homographies
> or data in a high-dimensional torus, or maybe just good ol' vectors in a
> spline way. If i implement the algorithm using only Lie-group 
structure of the
> data ( for example by extending 
http://portal.acm.org/citation.cfm?id=218486
> as i did :-), then it will work for everything that has a Lie group 
structure.
>
> Same goes for a time integrator, post-step stabilization in a constrained
> physical system, statistical analysis ( see
> 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.2692&rep=rep1&type=pdf
> ) and quite a bunch of other things.
>
> It saves huge amounts of development, copypasta, headaches, and so on.

I agree with you that these mechanisms are overdesigned if it is only 
aimed for simple cases such as mine.

But, I try to see if a common implementation could fulfil both our 
requirements. If it's possible, I fear that it implies a more complex 
design. My implementation shift the complexity of the code completely to 
the developers and it keep the fact that you can write generic algorithm 
for several kind of groups.

I try it again with dynamic matrix (MatrixXd) and the 
fast_exponentiation function. The wrapper implementation and my 
implementation generate the same assembly code. So, I think there are no 
unwanted copies. In case of more complex expressions such as :

qr = interpolate(q1,q2, 0.5) * q3;

I think my suggestion would reach it's limitation. It would not benefits 
from Eigen's expression template. And your wrapper have to be adapted to 
use the expression template mechanism when and if possible. For example, 
I think it may be difficult in the interpolation case.

I think it's the main advantage of your suggestion over mine. But with 
more complex types (i.e. pair<A,B>), I think that both our code will 
behave in the same way.

I hope it's clearer now, because I'm reaching the limit of both my 
English and my C++ skills :)

--
Mathieu