A (slightly) more precise `default_vector_transport_method`

[kellertuer]

I would like to shortly check with you about an extension of the default methods. This came up in JuliaManifolds/Manopt.jl#201

The scenario is as follows:

Assume we have a manifold (like Grassmann) with two representations (Stiefel and Projection), and that depending on the representation we have different functions implemented. In the given example

• Stiefel has a ProjectionVectorTransport
• projection does not have a method (would be the same as before dispatch to ParallelTransport and error)

But it might also be that we want to define different defaults per representation.

Proposed way

I propose to handle this as follows

1. Introduce a default_vector_transport_method(M::AbstractManifold, ::Type) to dispatch on different representation types
2. defaulting this to calling the current one (i.e. ignoring the type) that way we are backwards compatible
3. Introduce a nicer interface by default_vector_transport_method(M::AbstractManifold; representation=AbstractArray) having the type as keyword argument.

Let me know what you think, I do not think this is hard to do, just how to best do the interface is a discussion. The same would also be done for retractions and their inverses of course.

[kellertuer]

The reason I would like to dispatch on the type and not the point itself is, that the transport should only depend on how p is represented (so its type) but never its actual values (i.e. where you are at on M).

[mateuszbaran]

Sorry for not commenting on this earlier but I don't exactly understand the motivation. Parallel transport on Grassmann is quite expensive computationally so to me it seems unlikely it's ever preferable to projection transport, regardless of point representation.

[kellertuer]

It is not about Parallel transport.

The thins is that

default_vector_transport_method(M) should return two different things in Grassmann

• if it is a Stiefel/Array representation, then is should return ProjectionTransport()
• if it is a ProjectionRepresentation it should not be defined (that is it defaults to PT that is not defined and errors)

In general, a manifold with different representations (take Hyperbolic for example) might have a “favourite” default depending on the representation.

[kellertuer]

So if we come up with the BaranTransport for Projection representation on Grassman (but do not implement ProjectionTransport, since we do not find a paper for that) then Grassmann with ProjectionRepresentation should default to BaranTransport()while we want to keep the Stiefel default as is.

Currently there is no default yet on Grassman, but when I tried to define it, I noticed this difficulty

[mateuszbaran]

Hm, when we have a transport in one representation (let's say B), then couldn't we just implement it for other representations (A) as "convert from representation A to B, vector transport in B, convert back to A"?

[kellertuer]

If you have proper conversions, sure. What if not? One could also say: We set one default and do not care about the others.

But it might also be that conversion is expensive? And in one representation B is cheap and A in the other? Then we would like to set them as defaults maybe?

[mateuszbaran]

Right, if conversion is very costly or not implemented then it makes sense.

[kellertuer]

And sure I would prefer for most cases using the current variant, that's why the case with a type should also always fall back to the current version – not only to be backward compatible.