Grassmann Manifolds

[mjungmath]

Grassmannian manifolds are extremely important in (differential) geometry. Thus, we want to add them to the catalog of manifolds in Sage.

The following notes introduce charts and their transition maps very straightforwardly:

http://www.math.toronto.edu/mgualt/courses/18-367/docs/DiffGeomNotes-2.pdf

However, the number of charts grows extremely fast, namely ncr(n,k). One approach could be to parallelize the initialization process to reach at least low dimensional Grassmannians in a reasonable time.

Apart from that, it could be enough to start with only one chart since this should already cover enough (in particular, everything except a set of measure zero). That should give enough freedom to do almost everything on Grassmannians already.

Part of metaticket #30189.

CC: @egourgoulhon @tscrim @tobiasdiez

Component: manifolds

Issue created by migration from https://trac.sagemath.org/ticket/31249

[mkoeppe]

comment:2

I think this is a good opportunity to investigate possible connections to pymanopt (#30495)...

[tscrim]

comment:3

Another possible approach is to have a way to construct things lazily. So you have the charts, but all of the additional initialization and constructions would not be done until you actually do something with the chart. However, this would require a major overhaul to the manifolds implementation.

[egourgoulhon]

comment:4

+1 for including Grassmannians (with projective spaces as special case).

Replying to @mkoeppe:

I think this is a good opportunity to investigate possible connections to pymanopt (#30495)...

Could you elaborate a little bit about this?

[tobiasdiez]

comment:5

Or, more generally, flag manifolds.

For the charts, maybe it is convenient to use the fact that these examples are homogeneous spaces, so that one only needs to define the chart at the identity coset. The other charts can be then generated dynamically by translation on the group.

[mjungmath]

comment:6

Replying to @tobiasdiez:

Or, more generally, flag manifolds.

For the charts, maybe it is convenient to use the fact that these examples are homogeneous spaces, so that one only needs to define the chart at the identity coset. The other charts can be then generated dynamically by translation on the group.

We neither have Lie groups nor group actions at the moment. And elements of e.g. GL(R, n) are represented by matrices in the (by nature) inexact "field" of floating-point reals. I suspect some problems here.

[fchapoton]

comment:7

Using the cluster charts (namely minors of matrices) and cluster mutations may be a good way, that would give as a bonus the positive grassmanians.

[tscrim]

comment:8

Replying to @fchapoton:

Using the cluster charts (namely minors of matrices) and cluster mutations may be a good way, that would give as a bonus the positive grassmanians.

You are thinking about representing the charts in terms of Plücker coordinates, correct?

[tscrim]

comment:9

Replying to @mjungmath:

Replying to @tobiasdiez:

Or, more generally, flag manifolds.

For the charts, maybe it is convenient to use the fact that these examples are homogeneous spaces, so that one only needs to define the chart at the identity coset. The other charts can be then generated dynamically by translation on the group.

We neither have Lie groups nor group actions at the moment. And elements of e.g. GL(R, n) are represented by matrices in the (by nature) inexact "field" of floating-point reals. I suspect some problems here.

I think there is still something you can do by considering the free parameters of the corresponding matrices to define the coordinate chart. So you don't really need the actual Lie group implemented as a manifold I believe.

[mjungmath]

comment:10

Replying to @tscrim:

You are thinking about representing the charts in terms of Plücker coordinates, correct?

Unfortunately, I don't know Plücker coordinates. I have to read some things first...any idea where to start?

Replying to @tscrim:

I think there is still something you can do by considering the free parameters of the corresponding matrices to define the coordinate chart. So you don't really need the actual Lie group implemented as a manifold I believe.

Ah, alright. That could actually work! Nice!

[tscrim]

comment:11

Replying to @mjungmath:

Replying to @tscrim:

You are thinking about representing the charts in terms of Plücker coordinates, correct?

Unfortunately, I don't know Plücker coordinates. I have to read some things first...any idea where to start?

Wikipedia

The short version is Plücker coordinates are the minors for a matrix representing a point in the Grassmannian and give an embedding in projective space. The transition maps are quadratic and considered as cluster relations.

[mkoeppe]

comment:12

Sage development has entered the release candidate phase for 9.3. Setting a new milestone for this ticket based on a cursory review of ticket status, priority, and last modification date.

[trevorkarn]

comment:15

Does it make sense to first make a projective space manifold and then make the Grassmannian as a submanifold (via the Plucker embedding)? If so, should it have interaction with sage.schemes.projective.projective_space.ProjectiveSpace_field or should it be just a separate thing altogether?

I'm also wondering if it makes sense to use multiple realizations (see https://doc.sagemath.org/html/en/reference/categories/sage/categories/with_realizations.html#sage.categories.with_realizations.WithRealizations), with one for the Plucker embedding and one for a collection of charts. In this case, however, would it make more sense to define the Grassmannian on its own rather than as a submanifold of projective space?

[tscrim]

comment:16

We do not yet have projective space implemented as a manifold example yet (this would good to do). However, I don't think it reduces the problem of having to initialize a lot of information upon creation.

Perhaps one way around this is to define a special class specifically for the Grassmannian that has special methods to generate the standard charts (see the corresponding Wikipedia page). This would also be useful as it could take input thinking of it as a symmetric space (mainly, matrices as input). I think this is justified because Grassmannians are a very special example (similar to Euclidean space). (Side note: I also think projective space should receive a similar special treatment.)

[mjungmath]

comment:17

I must agree with Travis. The number of transition maps that need to be initialized go out of hand very quickly. A special treatment is required if we want to use projective spaces / Grassmannians even in reasonably low dimensions.

One sensible way would be to introduce lazy charts, as suggested by Travis in comment:3. I think this is a good idea, not only for this particular problem but also in general. This could solve a lot of computational time, because sometimes it is sufficient to know what happens on a smaller set (for example dense sets). Eric, what do you think about lazy charts?

[egourgoulhon]

comment:18

Replying to @mjungmath:

Eric, what do you think about lazy charts?

Why not? if they are useful in the present case.

[tscrim]

comment:19

Replying to @egourgoulhon:

Replying to @mjungmath:

Eric, what do you think about lazy charts?

Why not? if they are useful in the present case.

This will likely be a major rewrite of the SageManifolds codebase because the laziness will likely need to extend fairly deep into the codebase with additional linking between objects (so they know how to construct their relevant data). For the top-level charts, this can be done by a (hidden) method that generates the basic data. It might be possible to just do a small-scale version of this with just the top-level charts, but I suspect the work done will likely want to incorporate changes throughout the chart creation (which will likely benefit all of this code with creation time for charts that it “knows” but the user may not need to work with).

[mjungmath]

comment:20

Replying to @tscrim:

Replying to @egourgoulhon:

Replying to @mjungmath:

Eric, what do you think about lazy charts?

Why not? if they are useful in the present case.

This will likely be a major rewrite of the SageManifolds codebase because the laziness will likely need to extend fairly deep into the codebase with additional linking between objects (so they know how to construct their relevant data). For the top-level charts, this can be done by a (hidden) method that generates the basic data. It might be possible to just do a small-scale version of this with just the top-level charts, but I suspect the work done will likely want to incorporate changes throughout the chart creation (which will likely benefit all of this code with creation time for charts that it “knows” but the user may not need to work with).

Mh. Good point. But I suspect this can be circumvented by introducing lazy versions of CoordChange rather than Chart. This would make sense because the transition maps (and their inverses) are the most computationally heavy parts.

A flag like lazy_init=True for charts could make sure that corresponding transition maps are always initialized lazily.

[mjungmath]

comment:21

Replying to @mjungmath:

Replying to @tscrim:

Replying to @egourgoulhon:

Replying to @mjungmath:

Eric, what do you think about lazy charts?

Why not? if they are useful in the present case.

This will likely be a major rewrite of the SageManifolds codebase because the laziness will likely need to extend fairly deep into the codebase with additional linking between objects (so they know how to construct their relevant data). For the top-level charts, this can be done by a (hidden) method that generates the basic data. It might be possible to just do a small-scale version of this with just the top-level charts, but I suspect the work done will likely want to incorporate changes throughout the chart creation (which will likely benefit all of this code with creation time for charts that it “knows” but the user may not need to work with).

Mh. Good point. But I suspect this can be circumvented by introducing lazy versions of CoordChange rather than Chart. This would make sense because the transition maps (and their inverses) are the most computationally heavy parts.

A flag like lazy_init=True for charts could make sure that corresponding transition maps are always initialized lazily.

Let's move the discussion to #33225.