Re: [eigen] Eigen and rigid body simulation

[Maxime Tournier <maxime.tournier@xxxxxxxxxxxx>]

Hi !

> 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);
> }
> 

When i said there were some unwanted copies, i was referring to the the case 
when you feed fastExp directly with a Quaternion instead of a 
LieGroup<Quaternion>

Say i have a Quaternion, q, and i want to fastExp it. Then I have to do:

Quaternion res = fastExp( q, n ).get();

It seems there are two Quaternion copies here: one when constructing the 
LieGroup<Quaternion>, and one when affecting the wrapped quaternion to the 
result. I was worried about the first one: is the compiler clever enough to 
elide it ?


 
> 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.

Making all this benefit from expression templates would be painful, and i'm 
not really conviced this would bring much performance enhancement: the 
operations are sometimes complicated and the temporaries are small anyway, in 
most cases. 

For example when you multiply 3 matrices together, you probably still need a 
temporary at some point to cache results, otherwise the complexity explodes. 
Most Lie group operations are of that kind, unless you're considering additive 
vector/matrix groups.

But if we were to do it anyway, we would have to implement Lie group 
expression templates  for each type in the geometry module, then use trait 
classes to determine return types in the wrapper...

Or we could enable -std=c++0x in gcc and use the almighty "auto" keyword ;-)

> 
> 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 :)

If I sum things up so far:

* Your wrapper has a member value
* The user sees the wrapper 
* Group specific-code is implemented in separate struct, in static functions 
(the ei_lie_composition )

* My wrapper captures by reference (possibly lvalues)
* Only the developper sees the wrapper
* Group specific-code is implemented in a separate struct, in static functions
 ( the concept map )

So apart from syntax considerations, the only difference is how does the 
wrapper wrap, with (minor) perfomance implications. 

I think we're getting slightly picky :)


-- 
Maxime