Opened 19 months ago

Last modified 5 months ago

#31249 new enhancement

Grassmann Manifolds

Reported by: gh-mjungmath Owned by:
Priority: major Milestone: sage-9.7
Component: manifolds Keywords:
Cc: egourgoulhon, tscrim, gh-tobiasdiez Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by gh-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.

Change History (22)

comment:1 Changed 19 months ago by gh-mjungmath

  • Description modified (diff)

comment:2 follow-up: Changed 19 months ago by mkoeppe

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

comment:3 Changed 19 months ago by tscrim

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.

comment:4 in reply to: ↑ 2 Changed 19 months ago by egourgoulhon

+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?

comment:5 follow-up: Changed 19 months ago by gh-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.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 19 months ago by gh-mjungmath

Replying to gh-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.

comment:7 follow-up: Changed 19 months ago by chapoton

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.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 19 months ago by tscrim

Replying to chapoton:

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?

comment:9 in reply to: ↑ 6 Changed 19 months ago by tscrim

Replying to gh-mjungmath:

Replying to gh-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.

comment:10 in reply to: ↑ 8 ; follow-up: Changed 19 months ago by gh-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?

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!

comment:11 in reply to: ↑ 10 Changed 19 months ago by tscrim

Replying to gh-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.

comment:12 Changed 17 months ago by mkoeppe

  • Milestone changed from sage-9.3 to sage-9.4

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.

comment:13 Changed 13 months ago by mkoeppe

  • Milestone changed from sage-9.4 to sage-9.5

comment:14 Changed 8 months ago by mkoeppe

  • Milestone changed from sage-9.5 to sage-9.6

comment:15 Changed 7 months ago by tkarn

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?

comment:16 Changed 7 months ago by tscrim

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.)

comment:17 follow-up: Changed 7 months ago by gh-mjungmath

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?

Last edited 7 months ago by gh-mjungmath (previous) (diff)

comment:18 in reply to: ↑ 17 ; follow-up: Changed 7 months ago by egourgoulhon

Replying to gh-mjungmath:

Eric, what do you think about lazy charts?

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

comment:19 in reply to: ↑ 18 ; follow-up: Changed 7 months ago by tscrim

Replying to egourgoulhon:

Replying to gh-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).

comment:20 in reply to: ↑ 19 ; follow-up: Changed 7 months ago by gh-mjungmath

Replying to tscrim:

Replying to egourgoulhon:

Replying to gh-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.

comment:21 in reply to: ↑ 20 Changed 7 months ago by gh-mjungmath

Replying to gh-mjungmath:

Replying to tscrim:

Replying to egourgoulhon:

Replying to gh-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.

comment:22 Changed 5 months ago by mkoeppe

  • Milestone changed from sage-9.6 to sage-9.7
Note: See TracTickets for help on using tickets.