Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce LieGroupsBase.jl and LieGroups.jl #3

Closed
kellertuer opened this issue Jul 19, 2021 · 5 comments
Closed

Introduce LieGroupsBase.jl and LieGroups.jl #3

kellertuer opened this issue Jul 19, 2021 · 5 comments

Comments

@kellertuer
Copy link
Member

Maybe the development of this package is a good start point to discuss whether it might be reasonable to introduce

LieGroupsBase.jl
that covers the basic interface for Lie groups (currently in Manifolds.jl/groups/groups.jl, e.g. the GroupManifold, the Actions and Operators) and has mainly only ManifoldsBase.jl as a dependency. I think the interface we have there (maybe up to the identity discussion) is quite stable already.

LieGroups.jl
Which covers the groups in Manifolds.jl/groups. So it should depend on LieGroupsBase.jl and Manifolds.jl

Would that be reasonable or would it divide the package into too many sub packages? I think one advantage would be that Manifolds itself would focus a little more on Riemannian Manifolds and LieGroups.jl would be the extension to Lie groups and focus on operations around that.
A disadvantage of course is, that we then have more packages and dependencies among them.

@mateuszbaran
Copy link
Member

Good idea, although I'd prefer to do it in a few steps:

  1. Moving connections to ManifoldsBase.jl. Connections are tightly integrated with both metric manifold and Lie groups and algebras.
  2. Splitting out LieGroups.jl that depends on Manifolds.jl.
  3. Splitting out LieGroupsBase.jl so that ManifoldDiffEq.jl wouldn't have to load all the Lie group functionality.

One good outcome would be reduction of CI time in Manifolds.jl. Note that step 1 is necessary here, and would probably require more careful distinction between connection manifolds and Riemannian manifolds then what we have now. Probably AbstractManifold would just have a connection and AbstractRiemannianManifold would mean there is a metric? This is one point that's not clear to me.

@kellertuer
Copy link
Member Author

That sounds like a very good plan.. For the AbstractRiemannianManifold I had to think for a moment and was first like: Maybe just a Union{MetricManifold,ConnectionManifold} would be enough, but no, you are right, that would be a reasonable extension. Just a slight different wording that I would use. Instead of “there is a metric” I would use “there is an explicit implementation of a metric, not (just) an implicitly assumed one”?

@mateuszbaran
Copy link
Member

Well, AbstractConnectionManifolds aren't necessarily Riemannian manifolds. And I've also noticed that it's not possible to tell which manifolds are Riemannian through abstract type hierarchy. So AbstractRiemannianManifold doesn't seem like a good idea to me now -- but it could be a trait.

@kellertuer
Copy link
Member Author

Right. But a trait sounds like a good idea.

@kellertuer
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants