Move GroupManifold interface to ManifoldsBase. #84
Conversation
Codecov Report
@@ Coverage Diff @@
## master #84 +/- ##
===========================================
- Coverage 99.85% 87.76% -12.09%
===========================================
Files 14 15 +1
Lines 1339 1504 +165
===========================================
- Hits 1337 1320 -17
- Misses 2 184 +182
Continue to review full report at Codecov.
|
That's an interesting idea. I think, though, that it should be developed in Manifolds.jl first. What operations would actually be simplified by having homogeneous spaces?
I think having dedicated constructors for each important Lie group may be actually more convenient.
It should be non-breaking for everything except Manifolds.jl but IIRC redefinitions are a bad idea, so I'd prefer to make a breaking release here. BTW, why did you only partially move group actions here? |
Ok, then lets not include it in this PR. My idea is that some operations can already be defined on homogeneous spaces (and then inherited by Lie groups). So it would not be necessarily a simplification but make the “coupling” Group&Manifold better/more clear.
Sure we have those already, I was thinking here about “getting” to the (default) Lie group for rotations that way (in the sense of decorating). But if you think that is not so interesting, we can also leave that out.
I hope I only moved the abstract stuff here and not the concrete (addition/multiplication) parts? And the abstract parts can surely be in ManifoldsBase. Did I do that wrongly somewhere? |
Which operations do you have in mind? I think I don't quite see what you want to do but maybe let's discuss that in a separate issue.
I'm not against, I just don't see the benefit here.
Maybe it's fine but it feels weird to have |
Since we do not do it here, sure lets do that in a separate issue. My main idea is to have a
It would just get easier to use/read; whether that is super useful, I am also not sure.
Did I miss to move |
I don't see |
|
Ah, I read it the other way around, sorry (that it was here and should not be). I will check for the tests and the error with Julia 1.0 later today anyways and then also look for that. |
|
While I checked where I missed GroupOperationAction, I noticed that that type is in principle what I meant with the Homogeneous Space, i.e. couple a manifold and an action/other space (most prominently translation & rotation actions then). Edit: Since it seems really to be the case that |
|
Hm, are you sure? |
|
But exactly that makes it currently a little strange, because the |
|
That's a good point -- the division between actions and their respective quotients is somewhat arbitrary and rearranging things a bit may be a good idea.
For which operation?
I also want to handle non-transitive actions so not all quotient spaces are going to be homogeneous spaces. |
|
Well for me an action storing its group feels the wrong way around. I am not yet finished with modelling the new types, but I do not like this line for example Since in principle the action (operation?) would be a type of the group and here its the other way around – what if the group operation within the action is different form the action you have in mind? I think that also action and operation refer to nearly the same thing? And I am far away from quotient spaces here, but as a sketch would render the |
|
Ah here https://github.com/JuliaManifolds/Manifolds.jl/blob/272f2581f0629a89150a000c1540f0feade961d2/src/groups/semidirect_product_group.jl#L43-L53 was the lines that feel strange. You take a group (that has an action) and a manifold and an action (that internally has a group and a manifold) and then those have to match. Why then store everything double if that only yields that one has to check that the fit? |
|
I mean, maybe you both think all this is bogus – but then someone else has to move the Lie group stuff to Base, because then I seem to have a major problem in understanding the modelling here, but for me the order is a little mixed up in the current modelling (operation in group but group and manifold in action...) |
|
It would be nice to improve the current design but it's a hard problem. Take |
|
I currently get confused that apply and an order rotates the order sometimes. And currently I am confusing Action and operation. Maybe I should stop here, because I seem to have a major misunderstanding somewhere. My understanding of the action (until your last post) was that it is the group operation of the group? Maybe its not? Then I am missing some major documentation what is what here and why the action (which is an operation?) internally stores group and manifold. Would and Addition internally store the Rn? And the Rn again? So (I stop here, until both of you have clarified this, since I am now confused and someone else might have to take over or clarify). |
|
Apply would habe as its first argument the homogeneous space – that has both the group and the manifold. That would not be a problem. Also what confuses me, that we have the apply documentation
Which for me sounds like |
|
rom rotation it seems that left action means multiplication from the left. And right action means – multiplication from the left just with the inverse of the action (rotation matrix). So somehow elements of the group are called actions (why?) and their direction is a question whether we invert or not but right is still application from the left. But for the default (abstract) case, this does not seem to matter I think I am missing something here. |
|
Sorry for all these posts – I really seem to miss a lot in the theory with actions operations and directions, sometimes actions seem operations (+ / *), then the are vectors/rotations, sometimes directions matter, sometimes not, but its not documented and for the last link I maybe would have expected compose instead to translate? I think we might have missed to document this in a little more detail, so its easier to follow the code flow. |
Operation is internal to the group (a part of its definition). For example matrix multiplication on matrix Lie groups. Action is how a group acts on a different manifold. I think a good example may be actions of SO(2) on R^3 -- you have a group, a manifold, and additionally need to specify the axis of rotation somewhere. Then it's rotation about that axis by an angle specified by an element of SO(2).
Action direction may be a bit unclear, right. I'm not even quite sure why it's defined this way for the rotation action...
No problem, it really is not properly documented. I'll have to take a deeper look to answer all questions. |
|
So operation is matrix multiplication.
Above you said a is the action? That is exactly what confuses me. a is a point from the group and an action and depends on itself? I still don't get it. Is the action |
Ok, that is a little confusing, but I think my main problem is an action indeed. My understanding would be as follows: We take a homogeneous space H that is
then we do not have an action. we would just have g * p (or p * g for right) where * is the operation from G. Whether the space stores the group or the operation – might be a matter of taste I would prefer to store G instead of just the MultiplicationOperation for example, but one can manage both. But we can still take all g and p and this text does not include actions. So I must miss something. Is * the action? or g? It can not be g because g does not have a direction... so its *? but why store that extra , the group should know its operation? |
Action is the way elements on group operate on the manifold.
Where did I say that? I didn't mean that. |
I think my above example with SO(2) and R^3 demonstrates well what an action is -- and that the group, manifold, and direction don't fully specify |
But that means that the action is not the Lie group operation? What is the action then actually? In my had it is more like a magic hat now... it is not the group operation? What is it then and how is it defined? And why is it not the group operation? I thought that was the whole idea of taking a group :D
Oh, sorry, maybe only the docs said that |
The action is the \alpha function described here: https://en.wikipedia.org/wiki/Group_action . Does this make things more clear? |
But how would one model that? Axis of rotation – so for a general combination of a manifold and a group this is really some magic hat? I had hoped that for R3 only SO(3) is allowed, since then matrix multiplication (or the group action to be precise) would just do the job – but it can be anything? How would one model that? |
|
...but well. Then I can basically only conclude that all ideas in this PR are bogus and this will lead nowhere and we have to close this :( I am not able to model actions properly in these sketches I fear. |
I can write that example, but the key thing is making a concrete subtype of |
I can help with the design, and all parts except group actions should be OK. |
Thanks. I am really lost in how to model the magic hat alpha. For best of cases we have an decorator(?) that stores
and for the homogeneous space one would model alpha to just use the group action? also according to the wikipedia article (where alpha gets shortened to *) alpha has to be alble to couple two group elements as well as a group element and a manifold element? Or is the Compatibility property ones using * for alpha and ones for the group operation to confuse me? |
|
And thanks for all your patience, that \alpha to some extend clarified it (up to the problem whether it can also be applied to two group elements). But then our documentation was really misleading calling a group element the action. |
|
Went for a walk. What about a
which we can use for dispatch and one thing would be a And one could to subtypes of said type to model for example the rotation axis you mentioned. the apply could then access that (we would implement apply for the |
|
Sorry for not responding earlier but I was carried away by other stuff.
Yes, we need something that stores these three things. Alpha is the group action but usually it's different from group operation. Alpha doesn't need to do something with two group elements, where did you see that? In that Wikipedia article they use group operation (denoted by simple juxtaposition of two elements), while group action (alpha) is denoted by
No problem, it'd be really good to improve docs here because it is quite complicated. I hope my example with rotation around axis will also help here.
I don't really mind it being a manifold decorator but it's not quite necessary. And |
Then I must have misread this; I thought it also had to be able to just work on group elements. This Something that holds all three still needs a name though.
Yes it does.
I though of it similar to a Lie group, so that it would decorate the manifold it contains. |
|
I think we have to restart this approach in the new decorator style, but I will keep this open (or turn it into an issue once we have the new scheme). |
|
Yes, this will have to be redone but we can keep this PR open for now. |
|
This is continues in https://github.com/JuliaManifolds/LieGroups.jl |
This PR aims to provide the Lie group functionality already in ManifoldsBase.
While transferring the code (ok, in the end it was just copying 974 lines) I noticed two things:
GROUP_MANIFOLD_BASIS_DISAMBIGUATIONcurrently unusedAlso I would like to use this to propose to add a few small features
Homogeneous space
We could introduce an Homogneous Space wikipedia as a more generic case? This might be nice for some ManifoldDiffEq.jl solvers. I was thinking that again we have an abstract type and a concrete one; the abstract one would be a supertype of the `AbstractGroupManifold (where then M=G) and a concrete subtype with a manifold a group and an action.
What do you think?
Lie Groups
Currently we use the technical term
GroupManifoldwhich I think we should keep, but we could introduceLieGroupeither as an const or as an easy constructor with defaults LieGroup(Rotations(3)) could then just return the default Lie group on the rotations, i.e.SpecialOrthogonal(3)(though this specific case would have to be defined in Manifolds for sure). This would be kind of a higher level (or semantic) way to use GroupManifolds. Maybe that would be easier to a few end users.What do you think?
Still missing
I think this PR is nonbreaking though technically now Manifolds (when bumped to this without changes) would redefine a few things.