Manifolds.jl
Manifolds.jl copied to clipboard
1.0 release planning
I'd like to collect in one place items that we'd like to do before releasing 1.0 of Manifolds.jl and ManifoldsBase.jl. I'm not going to specifically focus on these but I think it'd be nice to have some sort of a roadmap. Please feel free to propose changes, this is just a list of a few things that came to my mind.
ManifoldsBase.jl:
- [x] Solve https://github.com/JuliaManifolds/ManifoldsBase.jl/issues/88 . I would expect it to be only slightly breaking for any external codebase that relies on it.
- [ ] Rethink inverse retraction-based distance (ref. https://github.com/JuliaManifolds/Manopt.jl/pull/144 )
- [ ] Maybe rethink curve specification for vector transports along.
Now that we don't import all symbols exported by ManifoldsBase.jl to Manifolds.jl we can move things from Manifolds.jl to ManifoldsBase.jl without tagging a breaking release.
Manifolds.jl:
- [ ] https://github.com/JuliaManifolds/ManifoldsBase.jl/pull/84
- [ ] JuliaManifolds/Manifolds.jl#357
- [ ] the tangent space and functions more unified, i.e. provide default basis for local_metric functions and make the basis parameter hence optional JuliaManifolds/Manifolds.jl#424 with the basis.
- [ ] Figuring out geodesics on metric manifolds (and polishing metric manifolds in general).
- [ ] Move distributions of manifolds to a separate package (ref. JuliaManifolds/Manifolds.jl#57 ref. #693 ).
- [x] Move the differentiation API to a separate package (#329 ?) (the package: https://github.com/JuliaManifolds/ManifoldDiff.jl )
- [ ] More comprehensive atlas/chart support (maybe).
- [ ] JuliaManifolds/Manifolds.jl#471
- [x] JuliaManifolds/Manifolds.jl#527
- [x] JuliaManifolds/Manifolds.jl#625
- [ ] #701
- [ ] #683
I would like to also have
- [ ] the tangent space and functions more unified, i.e. JuliaManifolds/Manifolds.jl#424 with the basis.
But overall I think our interface is stable enough (after the changes you proposed already) to go towards a 1.0, yes. I will check whether there is a specific feature we might want to support for manifolds in general.
Sure, I've added it to the list. Metric manifold stuff seems to be the least mature part of our interface.
Regarding additional features, there is still quite a lot that could be added, and I haven't even documented everything in issues yet.
Let's maybe collect a few features that we might want to have for a stable 1.0 release, though we have more open issues by this approach.
Concerning the metric manifold ideas, I can look into that but I first wanted to consider Hessians.
Concerning the metric manifold ideas, I can look into that but I first wanted to consider Hessians.
Sure, Hessians would be a nice addition for Manopt.jl. Concerning metric manifolds, I'd suggest mainly focusing on working in charts.
I don't think we need to rush to a 1.0. It implies an extreme stability and is quite limiting when it comes to making changes. In particular, I would like to see the interface battle tested by a large variety of packages before considering this. If packages aren't using it, there's no need for a 1.0. And if they are, and we're finding the interface needs no changes, then we can consider it.
A roadmap in general is a good idea though.
You are right, we should definitely not rush and there might be changes coming when the package is used more and we should not rush to a 1.0 before the “battle testing” has happened to some extend.
I think the idea here is exactly to collect points and features towards a 1.0.
Yes, exactly, I don't want to rush 1.0 but just have a place to discuss what breaking changes are planned.
I was looking around a bit whether we can reduce our issues a bit by solving the easier ones at least. I would add one point to the list before w go 1.0
- [ ] Decide whether the abstract types should have abstract in their names
We currently have that somewhere introduced (for Manifolds for example), but the more I see those names they feel like they have their type in their name, which I do like less and less. But my main point is, we are not consistent. So we should check that and aim for a consistent naming scheme (where I would prefer to avoid AbstractX
names, by now though I might have introduced a few of them myself).
Hm, I actually somewhat like the AbstractX
names. When I see a method f(::AbstractType)
I can quickly see if it dispatches on abstract or concrete type. But I can definitely live without that.
While I have a slight tendency towards not having that, I see mine as just a personal feeling, so if you have a reason that simplifies your workflow, we can go with your idea as well; I think my main argument was more to then unify that throughout the packages.
I just feel sometimes it is a bit clumsy and yields long names with the Abstract
upfront and usually the docs (for me on mouse hover) tell the type (whether its abstract or not) anyways real quick.