(Special) Orthogonal / Unitary / Euclidean groups

[kellertuer]

This PR aims to provide the special orthogonal group and the first concrete semidirect product: Special Euclidean, since the complex case is similar, this will also cover the special unitary case.

This PR resolves #15, since it introduces point and (Lie algebra) tangent vector types and carefully introduces all necessary passthroughs.

🛣️🗺️

• implement OrthogonalGroup
• Implement SpecialOrthogonalGroup
• Implement SpecialEuclideanGroup
• Implement UnitrayGroup
• Implement SpecialUnitaryGroup
• improve test coverage on the semidirect product groups.
• read the documentation carefully since we changed exp(G, Id, X) to exp(G,X) and similarly log(G, Ig, g) to log(G, g)

[codecov]

Codecov Report

Attention: Patch coverage is 99.21645% with 8 lines in your changes missing coverage. Please review.

Project coverage is 99.50%. Comparing base (e43ad02) to head (25ed327).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/interface.jl	93.27%	8 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #17      +/-   ##
==========================================
+ Coverage   99.20%   99.50%   +0.30%     
==========================================
  Files          13       21       +8     
  Lines         756     1625     +869     
==========================================
+ Hits          750     1617     +867     
- Misses          6        8       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kellertuer]

Status update 1: In theory SE(n) is defined, in practice I am not able to dispatch on the new const. Hence the constructor still falls back to calling the general show (of semidirect product) @mateuszbaran can you maybe take a look? After an hour of trying I am a bit out of ideas what is wrong with my constant SpecialEuclideanGroup definition.

[mateuszbaran]

I've fixed the issue with SpecialEuclideanGroup alias 🙂

[kellertuer]

Nice. I would not have noticed the tuple necessary during the rest of the year.

You changed one . to a map. Should I do that for the rest as well?

[kellertuer]

Oh and sorry for the capitalisation foo – Mac OS does not distinguish that on files when loading them … super annoying.

[mateuszbaran]

You changed one . to a map. Should I do that for the rest as well?

I generally prefer map over . when both are applicable because for the compiler it's much easier to optimize map.

Oh and sorry for the capitalisation foo – Mac OS does not distinguish that on files when loading them … super annoying.

No problem, that was an easy fix 🙂

[kellertuer]

The main work today was a bit of structure, since now one of my main worries already works – compose! – the remaining functions are hopefully just stuff to transfer from manifolds.jl the todo list is basically all commented our functions in the two new test files.

So I am confident that this should not be too complicated – and am quite happy with how semidirect turned out.

[kellertuer]

All dummies are there, now the rest is mainly getting all functions from the test suite implemented and tested.

[kellertuer]

Final update for today (got a bit carried away)

• For adjoint I would wait for a manifold that wraps and has a nice adjoint – for example the ValidationLieGroup planned soon
• similarly for the conjugate jacobian I would wait for a Lie group having this.

Since we at least make code cov already happy with only 8 new lines – we had 6 before, but this PR is larger than all previous code... maybe that is ok?

[mateuszbaran]

Nice! I think we can skip adjoint for now but I'd prefer to finish jacobian_conjugate. We could just have a default implementation based on diff_conjugate, similarly to what we have for adjoint_matrix in Manifolds.jl. Something more or less like this:

function jacobian_conjugate!(
    G::LieGroup, J, g, h; B::AbstractBasis=DefaultLieAlgebraOrthogonalBasis()
)
    Bb = get_basis(G, h, B)
    Vs = get_vectors(G, h, Bb)
    for i in eachindex(Vs)
        get_coordinates!(G, view(J, :, i), g, diff_conjugate(G, g, h, Vs[i]), B)
    end
    return J
end

This doesn't work because there are some issues with bases which we also might want to resolve here. I'm not 100% sure if I didn't mix g and h here so this also needs to be checked after bases work.

[kellertuer]

Hm, I do not yet understand this – neither your proposed code, nor why we have “some issues with bases” (and where), so I have to first read up on all that.

[mateuszbaran]

This is calculating Jacobian by separately passing each basis vector through the diff function. I think this should be a standard fallback pattern for Jacobians in general?

[mateuszbaran]

Anyway, you'll see the issue when you try running this code.

[kellertuer]

I mainly mean all the nitty gritty details, that the differential could be seen as a map between tangent spaces but for us the tangent spaces are all identified with the Lie group – but does that then involve divv_inv_left_compose or not or what do we expect the differential to be given in...?

The docs on the Jacobian are still a bit short on that so I have to track that down first before I can say something about your code – and I also would need a concrete example to run this on, otherwise I can not just run that code.

[mateuszbaran]

Right, it might not be that straightforward and isn't crucial to this PR. I will just open an issue about jacobian_conjugate.

[kellertuer]

thanks – I do agree that that should be provided, but I would need probably a day or two to get the notation in the docs right, understand the form and implement it correctly.

I can do that after the ValidationLieGroup (which is my next plan after this PR)

[mateuszbaran]

There is no rush, I'd just like to have jacobian_conjugate working here before groups are removed from Manifolds.jl.

[kellertuer]

I do fully agree on that. Then it is very good to have an issue open about that.

[mateuszbaran]

I think this is good enough now. I've opened one issue to check some aspects of SE(N) which are handled by Manifolds.jl but probably not here but it can be handled later (though before removing groups from Manifolds.jl). We should also note that quaternionic unitary needs to be handled (though just a point on the roadmap is enough).

[kellertuer]

SE(n) should be more generic here, because it works on (R,t), (R,t) and the matrix containing R t in homogeneous coordinates – but sure, performance is not my main area of expertise.

[mateuszbaran]

I know, and that's good. I mean primarily performance, support for AD and handling different numeric types.

[kellertuer]

Yes, very good to keep these in mind and have those aspects covered as well. Thanks for having that in mind.

I will merge this later today after my meetings and lectures then.