Define Meta Manifolds already in ManifoldsBase

[kellertuer]

This allows the user to even use a TangentSpaceAtPoint when only depending on ManifoldsBase. I would like to have this for defining proper/nice/generic subproblems in tangent spaces in Manopt.jl (e.g. for the current trust region rework).

This is breaking (hence also for 0.15) in the sense that with this version otherwise the VectorBundle is defined twice (which kills precompiation).

To do

• [x] moved the ArrayPartition sections to a weak dependency with RecursiveArrayTools.
• [x] We now have a first (non-standard-library) dependency here_ Requires.jl, but I think that is ok
• [x] check documentation
• [x] introduce DocumenterCitations here as well
• [x] bump Documenter to 1.0
• [x] check test coverage

[kellertuer]

Hm remo

I worked a bit further on the docs, but I am again lost on quite a last reference left to [TangentBundle](@ref) for the SasakiRetraction I am unsure how to rephrase this.

Either remove the reference or link to Manifolds.jl docs?

Hm, removing makes the doc string a bit unreadable. So probably then the link over for Manifolds, though I am not the largest fan of that.

It also seems we introduce the CotangentVectorSpaceType but no CotangentSpace is that intentional? I think we could also introduce the cotangent space if we have the vector space type for the fiber already?

CotangentSpaceType has been here for some time but I actually don't need CotangentSpace so I didn't think about it. Feel free to add it.

Ah ok :) Then let's also introduce that just for completeness.

(but not today, it was a long day already)

[kellertuer]

I think I fixed and updated the docs.

One thing we could unify a bit is how we address points / tangent vectors on the tangent space, since a point on TpM could be a p (but we do not want to use names double) or an X, similarly for the second choice X would already be taken, then maybe Z,Y for tangent vectors to the tangent space (since they are also tangent vectors / points again)?

[mateuszbaran]

We could also maybe use more than one character for variable name in case of tangent spaces? I have an even worse problem for vector bundles and using single letters doesn't work at all.

[kellertuer]

What? There exist more letters than p, q, X, Y, Z? Not that I have heard of! ;)

I would like to avoid small greek ones, since they are usually cotangent vectors, but besides that I am open do ideas for sure. Do you have something in mind? A and B for tangents to tangent vectors could work? Since they are still tangent vectors I would maybe stay with capital letters? V and W would also be nice I think.

[mateuszbaran]

I will shock you even more: you can have argument names in Julia that are two or even three letters long! Such as pX, p_M or X_T.

[kellertuer]

😱

I think what I had more in mind with the names is also what we use in the math part of the docs, and there single letters of letters with an index would be more common. I think I like V and W for elements of T_X(T_pM)

[kellertuer]

The two remaining uncovered test lines are false positives, one will be resolved by the other PR. So we just have to unify the variable names in the docs as soon as we agree on a set / idea of letters.

[mateuszbaran]

Sure, it's nice when formulas and variable names are the same. I think I'd prefer to add some indices to letters for tangent spaces.

[mateuszbaran]

For example, how would you write riemann_tensor! signature for TangentSpace without indices and confusion?

[kellertuer]

Probably W1, W2, W3 as tangent vectors to X ? (in math then with W_1)

But I am open to suggestions with other indices.

[mateuszbaran]

I see. I was thinking about X_T, Y_T, Z_T to be more consistent with existing methods but W1, W2, W3 works too.

[kellertuer]

In math that would have to be an \mathrm{T} (since it is not a variable), sure we could do that. I would prefer numbering them, I think.

[mateuszbaran]

OK, let's use numbers then.

[kellertuer]

Nice, will try to find time tomorrow (since for today I started sketching TangentSpaceModelproblems already to make TrustRegions (and probably the ARC solver) nicer.

[kellertuer]

I unified the notation. We should check that retractions (inverse retractions, vector transports) are properly passed down to the single factors in the product manifold (see linked issue from 0.14 / Manifolds)? But besides that this should be good to go :)

[kellertuer]

I would like to sketch a small roadmap. Once the is PR is done (just bumped test coverage hopefully) I would like to

1) Merge this first 2) merge it into the other PR and check whether we can introduce an “automatic product retraction pass down” (as discussed in https://github.com/JuliaManifolds/Manifolds.jl/issues/659) or at least for a few retractions (we could just generate a n-copy-productretraction) 3) Maybe even introduce × for retractions as well. 4) Merge that PR 5) Resolve https://github.com/JuliaManifolds/ManifoldsBase.jl/issues/135 with a third PR 6) register 0.15 🥳

[mateuszbaran]

Sounds good :+1: . I more thing I'd like to do before merging this is making all tests pass (locally) in the Manifolds.jl rework PR.

[kellertuer]

Ah, that sounds like a very good idea 👍

In the mean time I can do the error-keyword-rework already for #135 – that also mainly seems to be a few lines of code and a bit of test adaptions.

[mateuszbaran]

Sure, that should be fairly simple.

[kellertuer]

Sure, that should be fairly simple.

Well, ± ambiguities and a few internals for embedded manifold or such that did change. but I think I am nearly there.

[mateuszbaran]

I've updated PowerManifold so that it can also be optionally static. I opted to use field-size by default because for this manifold it almost never makes sense to store the size statically, IMO.

[kellertuer]

I think I found a way to introduce retractions with non-product retractions as discussed in https://github.com/JuliaManifolds/Manifolds.jl/issues/659, the only “disadvantage” might be, that when margin this into https://github.com/JuliaManifolds/ManifoldsBase.jl/pull/167. we might have to repeat these for the retract as well.

This might be slightly bridging our layers, but layer one says “Note that all other parameters of a function should be as least typed as possible for all parameters besides the manifold.” so that is what I did here for the abstract retraction case and put it on layer 1; currently I also moved the ProductRetraction cases to layer 1, but maybe that is wrong and they should be back on Layer 2.

this is still missing a bit of testing, but I will first check which lines are missing, since also the new cross functions (analogue to product manifold one can now also create product retractions, inverse retractions, vector transports) and new show functions have to be tested.

[mateuszbaran]

I think I found a way to introduce retractions with non-product retractions as discussed in JuliaManifolds/Manifolds.jl#659, the only “disadvantage” might be, that when margin this into #167. we might have to repeat these for the retract as well.

OK, if this doesn't cause any ambiguities then I'm fine with it.

[kellertuer]

I think I found a way to introduce retractions with non-product retractions as discussed in JuliaManifolds/Manifolds.jl#659, the only “disadvantage” might be, that when margin this into #167. we might have to repeat these for the retract as well.

OK, if this doesn't cause any ambiguities then I'm fine with it.

That is exactly why I moved them from L2 to L1, on L2 they caused too many (non-ignorable) ambiguities. I will then write a few tests now :)

[kellertuer]

Oh, two of the function definitions I do not yet hit but I thought I would have. I will only have time tomorrow to check for these as well.

edit: I like what this turned out to be, also the ne ×, thanks for adapting your PR in Manifolds already. I will do something similar in Manopt, but for that it is easier to wait for Manifolds and ManifoldDiff to be bumped to ManifoldBase 0.15.

[mateuszbaran]

Cool. With this latest fix, test are passing in Manifolds.jl PR. I will continue with docs and coverage there.

[kellertuer]

Thanks for fixing one of my a-bit-too-fast copied method. I just extended (hopefully finally) test coverage.

I think now this should be good to go :)

[kellertuer]

We have one false-positive uncovered line left, so code coverage is as best as possible.

[mateuszbaran]

Yes, I think this is pretty much ready and we can work on releasing 0.15.0. I think first, we need to merge all three breaking PRs into one branch and check if the Manifolds.jl PR needs some additional work.

[kellertuer]

Cool. Then let's start with this one, then retractions (since we might want to check that this still works with the new dispatch)  – and then the error PR.