Thanks for your detailed answer.

##
Constraints

I think the main challenge is really, that in many places the `x`

is assumed not only to be Euclidean, but to be `<:AbstractArray`

â or informally, that `+`

can be used.

*Example 1*: For fixed rank matrices, though one could store the matrix itself, it is much (much much) more efficient to store its SVD, both for memory as well as time consumption. But then `x`

is not from (one) Euclidean space

*Example2*: On the sphere, though that is a subset of its embedded Euclidean space, we can take two points `p,q`

of unit norm but then `r=p+q`

is not of unit norm.

But this might also be something one still can specify in constraints.

So here I think it might be challenging to find all the places where âEuclidean-nessâ is assumed implicitly (I am surprised myself every now and then even in theory).

And sure, if we have an embedded manifold, both using constraints (and Augmented Lagrangian and such) is equivalent to the manifold idea, and even to the case that it might depend on the application, which one is better (I am not claiming manifolds solve everything better ).

And for embedded ones starting with thinking of constraints might be ok, but one thing that does change is, that *intrinsically due to thinking in manifolds* one is *always* feasible. Or: You never leave the manifold (for example since you exchange + with the exponential map).

But this different could â you are right â still be handled with the right set-constraint and then using Manopt.jl as a solver and not a Euclidean one with a constraint solver.

Also the constraint approach might resolve *most* manifolds, so that is why I would even propose to start with that.

##
Non-embedded Manifolds

The other is, that if we start on the lowest level, the set `M`

(that we would equip with a smooth atlas and a Riemannian metric to get a manifold) does not need to be a subset of an Euclidean space, so additionally to the challenges mentioned above.

Hm, A concrete example is maybe a bit harder to come by.

So first imagine that the concept of âglobal constraintsâ (like the norm for the sphere) are not necessary, it is ok to have constraints based on âwhere you areâ on the manifold, as long as the manifold dimension stays constant (that is the âdirections to move intoâ or more precisely the Euclidean space this is locally isomorphic to). This could probably still be captured by `point in Manifold`

, but we surely are not necessarily able to write `p`

in (global) coordinates like your `x`

in the code.

That is maybe the main thing I can see code-wise. We do not have global coordinates `p[1], ..., p[n]`

to work with for a non-embedded manifold.

We might even for now not necessarily have an example implemented, but maybe conceptually in code imagine that `p`

is of a type that is just a struct, that internally does not consist of a (set of) matrices (I think until now all our points are at least a set of matrices/vectors).

Then the check `p in M`

might consist of âfinding the area p is inâ, check the local constraint of said area of the manifold.

Sorry that I can not be more concrete here, if I have a concrete example I definetly mention it

But in these cases

- You can not narrow
`p`

down to something like your `x`

where you can constraint the first 3 entries. This is also already the case for Fixed-rank matrices Âˇ Manifolds.jl the SVD point we use on FixedRankmatrices â but sure there we can map the internal 3 matrices into a large vector if necessary
- You can not specify a âglobalâ constraint, i.e. one (set of) functions
`f_i`

that hold for all `p`

The closest we currently might get to an example is probably the Shape space: All smooth diffeomeorphisms of the sphere, which is an infinite-dimensional manifold; but we also have not yet explored all implementation details of this manifold.

##
Notation / Proposal

Overall â conceptually â I would really prefer a notion

```
@domain (model, Manifold)
```

which in many cases *could* be equivalent to some constraints.

The default is, and that (often not explicitly given) `Euclidean(n)`

, where `n`

is the number of variables, since this is your implicit assumption anywhere.

I would propose to start with the constraint idea, since that (with a proper map to the manifold when calling things in manifolds) might be nice.

Later one could have a domain-to-constraints âtranslatorâ, when such translation makes sense (e.g. for the sphere).

That would be my proposal (without knowing all details of MOI).

Sorry this post got a bit long, but I hope it describes the differences between domain and constraint.