Group action on different objects

[artivis]

At the moment, the act function treats its input argument as a point and act on it accordingly (e.g. SE2 rotates and translates). It would be great if act could act appropriately on different objects, likely vectors and points at first.

Options

This calls for a rethinking/redesign of the function with the following options:

1. distinguish objects with a runtime flag (likely an enum)
2. distinguish objects with a compile-time flag (e.g. struct assumePoint )
3. specialize the function for different objects types.

Pro/cons:

1.

Pro:

• Does not break current user code (flag defaults to point)

Cons:

• act implementation is going to be a big switch
• forces to input both Jacobians (possibly nil) to define the flag (see impl below)
• requires to edit the enum for every new object

2.

Pro:

• does not break user code (flag defaults to point)
• easy to add a new object

Cons:

• more complicated implementation (can't do partial specialization, requires an intermediate template class to do the specialization).

3.

Pro:

• alleviate confusion as it relies on actual type
• easy to add a new object
• looks good :D

Cons:

• breaks user code
• requires to define objects classes (e.g. class Point)

Pseudo-code for each options:

1. act( obj, Ja, Jb, flag )
2. act< flag >( obj, Ja, Jb )
3. act( Vector, Ja, Jb ) act( Point, Ja, Jb )

[artivis]

@joansola I thrown here a few initial ideas on improving act, any thoughts?? Notice that, at the moment, I tend to favor option 3.

I'll edit the ticket to keep it up to date with the discussion.

[joansola]

Complex groups are SE(3), SE_2(3), Sgal(3).

I was thinking, regarding act() in all complex groups. Maybe we could have special actions. In case e.g. of SGal3, we would have:

• transform points: T+R*p
• boost: see Kelly's paper
• event-transform: see paper

and other possible actions only available for this group.

In SE3 we have a similar problem, in

• transforming points T+R*p
• and transforming vetors R*v

In manif we already have some examples on non-abstracted methods:

• asSO3() <-- for SE3, SE23, SGal3
• E6() <-- for the generators

so I see no fundamental impediment for act(). In fact, it is possible that act() as an abstract form is not convenient, precisely because actions are not pre-defined operations for Lie groups in their abstract form.