Add symplectic structures

[tobiasdiez]

This ticket implements the basics of symplectic structures, like Poisson brackets and Hamiltonian vector fields.

TODO (as follow-up tickets):

• Extract general coordinate stuff from EuclideanSpace to new class VectorSpace, and let SymplecticVectorSpace derive from VectorSpace

CC: @tscrim @nthiery @mjungmath @egourgoulhon @mkoeppe

Component: manifolds

Author: Tobias Diez

Branch: b78d8a2

Reviewer: Eric Gourgoulhon, Michael Jung, Matthias Koeppe, Travis Scrimshaw

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

[mjungmath]

comment:114

Another thing. I think it is better to use Sage's factorial function in symplectic_form.py, and import this function in the only method where it is needed, namely volume_form:

 from __future__ import annotations
 from six.moves import range
 from typing import Dict, Union, Optional
-from math import factorial

             sage: vol = omega.volume_form() ; vol
             4-form mu_omega on the 4-dimensional symplectic vector space R4
             sage: vol.display()
             mu_omega = dq1∧dp1∧dq2∧dp2
         """
+        from sage.functions.other import factorial
+
         if self._vol_form is None:

[tobiasdiez]

comment:115

Replying to @mkoeppe:

The new class is called SymplecticVectorSpace but as far as I can see there is no vector space structure implemented: Elements are points and cannot be added or scaled.

That's true. As written in the ticket description, the plan is to provide a "vector space as a manifold" example that should be used as the base class for SymplecticVectorSpace.

.. or perhaps AffineSymplecticSpace.

Not sure if one needs this generalization, and even then one probably wants to say that its an affine space modeled on a symplectic vector space.

[tobiasdiez]

comment:116

Replying to @mjungmath:

Another thing. I think it is better to use Sage's factorial function in symplectic_form.py

I was wondering about this too, but in the end decided for the built-in factorial since the numbers for which one calculates this are very small (and are dominated by the n-th wedge product anyway). So I used the factorial from math to not pull-in some dependencies. But I can change this of course.

[mkoeppe]

comment:117

Replying to @tobiasdiez:

to not pull-in some dependencies.

This does not matter here because sage.manifolds already depends on all of sage.symbolic and sage.functions

[mkoeppe]

comment:118

Replying to @tobiasdiez:

.. or perhaps AffineSymplecticSpace.

Not sure if one needs this generalization, and even then one probably wants to say that its an affine space modeled on a symplectic vector space.

I don't know, one could just say it's an affine space with a translation-invariant symplectic form.

[mkoeppe]

Replying to @tobiasdiez:

TODO (as follow-up tickets):

• Extract general coordinate stuff from EuclideanSpace to new class VectorSpace, and let SymplecticVectorSpace derive from VectorSpace

We will have to be very careful with the design of this so that we do not add a 4th incompatible implementation of finite-dimensional vector spaces in Sage in this way. (We already have 3, implemented in sage.modules, sage.combinat.free_module, and sage.tensor.modules, respectively, see the constructor in https://doc.sagemath.org/html/en/reference/modules/sage/modules/free_module.html#sage.modules.free_module.FreeModule)

That's why I would urge to set the vector space side of things aside and only focus on the (affine) symplectic space here on this ticket.

The relation of

• free modules with a symplectic form to SymplecticSpace
• free modules with a positive definite form to EuclideanSpace should be done in one follow up ticket.

[mjungmath]

comment:120

Replying to @mkoeppe:

Replying to @tobiasdiez:

to not pull-in some dependencies.

This does not matter here because sage.manifolds already depends on all of sage.symbolic and sage.functions

Unfortunately, I am not an expert in this import business. Why does sage.manifolds matter here? And doesn't factorial belong to sage.functions.other? Wouldn't that make a difference, too? Notice that you did the same in diff_form.py:

@@ -732,9 +746,22 @@ class DiffForm(TensorField):
         :meth:`~sage.manifolds.differentiable.metric.PseudoRiemannianMetric.hodge_star`
         for more examples.
         """
-        if metric is None:
-            metric = self._vmodule._ambient_domain.metric()
-        return metric.hodge_star(self)
+        from sage.functions.other import factorial

[egourgoulhon]

comment:121

Replying to @mkoeppe:

Replying to @tobiasdiez:

TODO (as follow-up tickets):

• Extract general coordinate stuff from EuclideanSpace to new class VectorSpace, and let SymplecticVectorSpace derive from VectorSpace

We will have to be very careful with the design of this so that we do not add a 4th incompatible implementation of finite-dimensional vector spaces in Sage in this way. (We already have 3, implemented in sage.modules, sage.combinat.free_module, and sage.tensor.modules, respectively, see the constructor in https://doc.sagemath.org/html/en/reference/modules/sage/modules/free_module.html#sage.modules.free_module.FreeModule)

+1

That's why I would urge to set the vector space side of things aside and only focus on the (affine) symplectic space here on this ticket.

The relation of

• free modules with a symplectic form to SymplecticSpace
• free modules with a positive definite form to EuclideanSpace should be done in one follow up ticket.

+1

In the current state, SymplecticVectorSpace is simply a subclass of EuclideanSpace, which is fine at this stage. Maybe, following Matthias' recommendation, just rename it to AffineSymplecticSpace (despite there is no affine structure explicitly implemented). IMHO, SymplecticSpace would be too general, sounding like a synonym for SymplecticManifold.

Besides, I agree with Michael: import factorial as in diff_form.py.

[mjungmath]

comment:122

To keep the old behavior of hodge_dual, I'd suggest to fall back on the metric if no input has been given, otherwise an AttributeError will be thrown (which didn't happen before):

         from sage.functions.other import factorial
         from sage.tensor.modules.format_utilities import format_unop_txt, \
                                                          format_unop_latex

+        if nondegenerate_tensor is None:
+            nondegenerate_tensor = self._vmodule._ambient_domain.metric()

         p = self.tensor_type()[1]
         eps = nondegenerate_tensor.volume_form(p)

Accordingly, this behavior should be documented.

[mjungmath]

comment:123

Replying to @mjungmath:

To keep the old behavior of hodge_dual, I'd suggest to fall back on the metric if no input has been given, otherwise an AttributeError will be thrown (which didn't happen before):

         from sage.functions.other import factorial
         from sage.tensor.modules.format_utilities import format_unop_txt, \
                                                          format_unop_latex

+        if nondegenerate_tensor is None:
+            nondegenerate_tensor = self._vmodule._ambient_domain.metric()

         p = self.tensor_type()[1]
         eps = nondegenerate_tensor.volume_form(p)

Accordingly, this behavior should be documented.

In any case, if we really want to change this behavior, I'd opt for a more meaningful error message than NoneType object has no attribute....

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from ee5b552 to afefe4a

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

afefe4a

Improve hodge_dual and use right factorial

[tobiasdiez]

comment:125

I've now implemented the your suggestions except for the name change to "AffineSymplecticSpace". I agree that from a mathematical perspective "affine" has some justification, but in the end a affine symplectic space is diffeomorphic (even symplectomorphic) to a symplectic vector space; thus from a manifolds perspective there is no difference. More importantly, this class is meant as an example for symplectic manifolds (mostly for the doctests) and all textbooks talk about symplectic vector space but almost no one is interested in affine ones (google has like 800 hits for "affine symplectic space").

[mkoeppe]

comment:126

How is the vector space structure used? It seems to me that there is some conflation of the space and its (constant) tangent space happening.

[mkoeppe]

comment:127

Note that also most linear algebra textbooks also talk about vector spaces all the time even when they manipulate points in an affine space, not vectors in a vector space.

[tobiasdiez]

comment:128

The manifold package currently doesn't provide a way to define a manifold abstractly (i.e. by specifying its points), instead a manifold is given in terms of its chart. But an affine and a vector space both have a single chart covering the whole space, the only difference being that there is no "canonical" choice in the affine case while there is one in the vector space setting.

The "correct" name of this class would be "a symplectic manifold symplectomorphic to R2n with its standard symplectic form". For me "symplectic vector space" is a good-enough approximation to this truth.

[mkoeppe]

comment:129

This would be fine in a specialized system focused only on manifolds; but Sage covers many mathematical areas, and I am concerned that it is misleading to introduce a class that is called ...VectorSpace but is not in the category VectorSpaces.

[mjungmath]

comment:130

Replying to @tobiasdiez:

The manifold package currently doesn't provide a way to define a manifold abstractly (i.e. by specifying its points), instead a manifold is given in terms of its chart.

All points on a manifold are already uniquely determined in terms of charts. In fact, due to the manifold structure, specifying a manifold by its points or by its charts is equivalent.

Replying to @mkoeppe:

This would be fine in a specialized system focused only on manifolds; but Sage covers many mathematical areas, and I am concerned that it is misleading to introduce a class that is called ...VectorSpace but is not in the category VectorSpaces.

I agree. I also think that the best compromise for now is AffineSymplecticSpace.

[tobiasdiez]

comment:131

But its currently neither an affine nor a vector space... so the question would be: should sage (at some point) has a proper implementation of an affine symplectic space or of a symplectic vector space? In my opinion, for practical purposes, the vector version should be sufficient - if you really only have an affine space, then just don't use the fact that you could add vectors.

Even if we should go with affine symplectic, how would one express the fact that the chart depends on a choice of a base point?

[mkoeppe]

comment:132

A key difference is that we do not currently have a category for affine spaces. There's merely one implementation, in sage.schemes, that implements AffineSpace from a scheme-theoretic viewpoint. Its category is just the category of schemes, nothing more detailed than that.

[mjungmath]

comment:133

Replying to @tobiasdiez:

But its currently neither an affine nor a vector space... so the question would be: should sage (at some point) has a proper implementation of an affine symplectic space or of a symplectic vector space? In my opinion, for practical purposes, the vector version should be sufficient - if you really only have an affine space, then just don't use the fact that you could add vectors.

The important difference here is that, in a strict sense, the affine version has no vector space structure. If I understand Matthias's objection correctly, this is exactly the punchline.

[mjungmath]

comment:134

In addition, notice that EuclideanSpace is meant to represent an affine space, too:

An *Euclidean space of dimension* `n` is an affine space `E`, whose associated
vector space is a `n`-dimensional vector space over `\RR` and is equipped with
a positive definite symmetric bilinear form, called the *scalar product* or
*dot product* [Ber1987]_. An Euclidean space of dimension `n` can also be
viewed as a Riemannian manifold that is diffeomorphic to `\RR^n` and that
has a flat metric `g`. The Euclidean scalar product is then that defined
by the Riemannian metric `g`.

From that viewpoint, since you derive from EuclideanSpace, it is only natural to view your implementation as an affine symplectic space.

[mkoeppe]

comment:135

Replying to @tobiasdiez:

the question would be: should sage (at some point) has a proper implementation of an affine symplectic space or of a symplectic vector space?

To make it a "proper" affine space, one only needs to implement lines, easy to do.

On the other hand, to make it a vector space, one would need to identify the space with its tangent space -- so that the bilinear form can be applied to elements of the space.

[mjungmath]

comment:136

@Eric: Speaking of which, that brings to my mind: do we want to implement a method vector_space for EuclideanSpace that returns the corresponding underlying vector space (w.r.t. a given frame)?

[mjungmath]

comment:137

I think, affinness is sufficiently represented by:

sage: EuclideanSpace(3) is EuclideanSpace(3)
False

Thus, you get two distinct affine spaces, you may (or may not) relate to each other. Of course, lines would make this construction mathematically more rigorous.

[egourgoulhon]

comment:138

Replying to @tobiasdiez:

More importantly, this class is meant as an example for symplectic manifolds (mostly for the doctests) and all textbooks talk about symplectic vector space but almost no one is interested in affine ones (google has like 800 hits for "affine symplectic space").

This is a good point. Let us forget then about AffineSymplecticSpace. What about StandardSymplecticSpace? This would be in line with https://en.wikipedia.org/wiki/Symplectic_vector_space#Standard_symplectic_space.

[egourgoulhon]

comment:139

Replying to @mjungmath:

@Eric: Speaking of which, that brings to my mind: do we want to implement a method vector_space for EuclideanSpace that returns the corresponding underlying vector space (w.r.t. a given frame)?

This should probably be discussed in the follow up ticket mentioned in comment:119, in particular to decide which (Sage) type of vector space we want to return.

[mjungmath]

comment:140

Replying to @egourgoulhon:

Replying to @tobiasdiez:

More importantly, this class is meant as an example for symplectic manifolds (mostly for the doctests) and all textbooks talk about symplectic vector space but almost no one is interested in affine ones (google has like 800 hits for "affine symplectic space").

This is a good point. Let us forget then about AffineSymplecticSpace. What about StandardSymplecticSpace? This would be in line with https://en.wikipedia.org/wiki/Symplectic_vector_space#Standard_symplectic_space.

I am open to other suggestions, but I'd like to point out that the above implementation in fact represents an affine symplectic space since it derives from EuclideanSpace. Thus, there is no other more appropriate name than AffineSymplecticSpace.

And indeed, textbooks usually use symplectic vector spaces as primary example. But most textbooks also talk about the Euclidean vector space RR^n as primary example for Riemannian manifolds. Nevertheless, we decided for the affine version in Sage for the sake of convenience and (imho) accuracy. I say we should not break with it now.

[tobiasdiez]

comment:141

Replying to @mkoeppe:

Replying to @tobiasdiez:

the question would be: should sage (at some point) has a proper implementation of an affine symplectic space or of a symplectic vector space?

To make it a "proper" affine space, one only needs to implement lines, easy to do.

On the other hand, to make it a vector space, one would need to identify the space with its tangent space -- so that the bilinear form can be applied to elements of the space.

Well, you just declare the chart to be a linear isomorphism and your done carrying all the (vector space) structure over from Rn. Also easy ;-) To be precise, the new "SymplecticVectorSpace" class currently represents nothing else then R2n with a fixed basis and its canonical symplectic form, with addition and scalar multiplation forgotten/not yet implemented. You could view this as an abstract affine symplectic space with a chart; but in order to define a chart on an affine space one needs to choose a base point and a basis.

For these reasons I really like the idea

What about StandardSymplecticSpace

Should I go ahead and rename everything?

In addition, notice that EuclideanSpace is meant to represent an affine space, too:

The documentation is at least claiming this, but EuclideanSpace is also not a proper affine space either. You cannot subtract elements (at least I couldn't figure out how) and there is only one chart - but on an affine space you don't have a canonical chart; and once you fix a base point you have a vector space. Moreover, what are "polar coordinates" on an affine space? I think "EuclideanSpace" is also just Rn with its Euclidean metric, so maybe it should be renamed to StandardEuclideanSpace in a follow-up ticket?

Sorry for being so stubborn on this, but I would bet that an average graduate student has never seen the definition of an affine symplectic space (I certainly didn't) and so far I cannot see any good examples / uses cases why one would actually need them, especially for a CAS. I agree that the current implementation is not satisfying, but that's why I'd added it as a follow-up todo to implement the "vector space" part. Finally, and most importantly for me, I think the docstrings should try to be as understandable as possible, hiding as much mathematical complexity and focus on how the method/class are used - thus, I would like to use a symplectic vector space as a primary example in the documentation of a symplectic form and not an abstract concept one first has to lookup and understand.

[egourgoulhon]

comment:142

Replying to @tobiasdiez:

For these reasons I really like the idea

What about StandardSymplecticSpace

Should I go ahead and rename everything?

Yes please go on. If you agree with this name, this makes at least two of us and it does not collide with the name VectorSpace. We could still revert to SymplecticVectorSpace later on. IMHO, this nomenclature debate should not prevent this ticket to make its way into Sage 9.5, which is about to be released.

In addition, notice that EuclideanSpace is meant to represent an affine space, too:

The documentation is at least claiming this, but EuclideanSpace is also not a proper affine space either.

Actually, the documentation is not claiming that EuclideanSpace is an affine space, because the sentence just after the quoted one in comment:134 is

The current implementation of Euclidean spaces is based on the second point 
of view.

This second point of view is that of a Riemannian manifold, not of an affine space.

Sorry for being so stubborn on this, but I would bet that an average graduate student has never seen the definition of an affine symplectic space (I certainly didn't) and so far I cannot see any good examples / uses cases why one would actually need them, especially for a CAS.

+1

I agree that the current implementation is not satisfying, but that's why I'd added it as a follow-up todo to implement the "vector space" part. Finally, and most importantly for me, I think the docstrings should try to be as understandable as possible, hiding as much mathematical complexity and focus on how the method/class are used - thus, I would like to use a symplectic vector space as a primary example in the documentation of a symplectic form and not an abstract concept one first has to lookup and understand.

+1

[mkoeppe]

comment:143

Replying to @egourgoulhon:

What about StandardSymplecticSpace?

+1, this is a great suggestion

[mjungmath]

comment:144

Replying to @egourgoulhon:

Actually, the documentation is not claiming that EuclideanSpace is an affine space, because the sentence just after the quoted one in comment:134 is

The current implementation of Euclidean spaces is based on the second point 
of view.

This second point of view is that of a Riemannian manifold, not of an affine space.

Fair enough.

All fine by me. :)

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from afefe4a to cdffbb2

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

91fb04d	Merge branch 'develop' of https://github.com/sagemath/sage into public/manifolds/symplectic
cdffbb2	Rename to standard symplectic space

[mjungmath]

comment:146

-        return f"{self._dim}-dimensional symplectic vector space {self._name}"
+        return f"Standard symplectic vector space {self._name}"

This looks like cheating to me. Please correct me if I'm wrong, but wasn't the whole point that this implementation does not constitute a vector space? This would still leave the impression to the user that they can add/substract or scale points.

For the sake of consistency, I opt for:

-        return f"Standard symplectic vector space {self._name}"
+        return f"Standard symplectic space {self._name}"

Otherwise, we have to rename Euclidean space to Euclidean vector space, too. Which wouldn't make sense to me due to the aforementioned reasons.

[mjungmath]

comment:147

Replying to @tobiasdiez:

Sorry for being so stubborn on this, but I would bet that an average graduate student has never seen the definition of an affine symplectic space (I certainly didn't) and so far I cannot see any good examples / uses cases why one would actually need them, especially for a CAS. I agree that the current implementation is not satisfying, but that's why I'd added it as a follow-up todo to implement the "vector space" part. Finally, and most importantly for me, I think the docstrings should try to be as understandable as possible, hiding as much mathematical complexity and focus on how the method/class are used - thus, I would like to use a symplectic vector space as a primary example in the documentation of a symplectic form and not an abstract concept one first has to lookup and understand.

Matthias already pointed out in comment:113 that symplectic vector spaces are at present part of Sage. More reasonable, in my opinion, would be a link between both implementations instead of equipping StandardSymplecticSpace with an additional vector space structure. See for example #30832 for a vaguely similar attempt.

[mjungmath]

comment:148

@Tobias: I'd like to point out that I perfectly understand your concerns. Actually, I dealt with similar issues when I started in the Sage project. Mathematical accuracy and implementation details cannot always be aligned, unfortunately. That being said, we cannot create Sage objects that unify all their mathematical properties. That's something Travis taught me with hours of patience. Isn't that right Travis? :D

[tobiasdiez]

comment:149

Replying to @mjungmath:

-        return f"{self._dim}-dimensional symplectic vector space {self._name}"
+        return f"Standard symplectic vector space {self._name}"

This looks like cheating to me. Please correct me if I'm wrong, but wasn't the whole point that this implementation does not constitute a vector space? This would still leave the impression to the user that they can add/substract or scale points.

For the sake of consistency, I opt for:

-        return f"Standard symplectic vector space {self._name}"
+        return f"Standard symplectic space {self._name}"

Otherwise, we have to rename Euclidean space to Euclidean vector space, too. Which wouldn't make sense to me due to the aforementioned reasons.

I wasn't sure about this one. The "vector space" part was meant to convey that "R2" is really the vector space R^2 one knows and that the symplectic form is constant. Can be changed of course.

[tobiasdiez]

comment:150

Replying to @mjungmath:

@Tobias: I'd like to point out that I perfectly understand your concerns. Actually, I dealt with similar issues when I started in the Sage project. Mathematical accuracy and implementation details cannot always be aligned, unfortunately. That being said, we cannot create Sage objects that unify all their mathematical properties. That's something Travis taught me with hours of patience. Isn't that right Travis? :D

I guess I still have much to learn ;-). So thanks for everyone's patience. Also, as a physicist by education, it is perhaps easier for me to ignore fine mathematical details (affine vs vector space) or mathematical structure (category theory) if that makes the implementation easier.

---

That being said, I still think it would be handy in applications if points of EuclideanSpace could be added and scaled (without the need to resort to explicit coordinates).

[egourgoulhon]

comment:151

Replying to @tobiasdiez:

Replying to @mjungmath:

-        return f"{self._dim}-dimensional symplectic vector space {self._name}"
+        return f"Standard symplectic vector space {self._name}"

This looks like cheating to me. Please correct me if I'm wrong, but wasn't the whole point that this implementation does not constitute a vector space? This would still leave the impression to the user that they can add/substract or scale points.

For the sake of consistency, I opt for:

-        return f"Standard symplectic vector space {self._name}"
+        return f"Standard symplectic space {self._name}"

Otherwise, we have to rename Euclidean space to Euclidean vector space, too. Which wouldn't make sense to me due to the aforementioned reasons.

I wasn't sure about this one. The "vector space" part was meant to convey that "R2" is really the vector space R^2 one knows and that the symplectic form is constant. Can be changed of course.

Yes please change it for consistency, albeit I agree that "vector space" in the name would make perfectly clear that the object is what the user expect.

[egourgoulhon]

comment:152

Replying to @tobiasdiez:

That being said, I still think it would be handy in applications if points of EuclideanSpace could be added and scaled (without the need to resort to explicit coordinates).

This would be handy indeed and there is no reason why this cannot be implemented in a future ticket.

[mjungmath]

comment:153

Replying to @tobiasdiez:

I wasn't sure about this one. The "vector space" part was meant to convey that "R2" is really the vector space R^2 one knows and that the symplectic form is constant. Can be changed of course.

Well, the Euclidean space is abbreviated with E^n and not R^n. Perhaps we should do the same here, too?

At least until we have the vector space structure on Euclidean space (though, I'd personally prefer an affine structure).

This all is indeed a bit of a hassle, and a lot of subtleties lie on the path. Maybe it is a good idea to nudge a discussion with the Sage (manifolds) community?

[mjungmath]

comment:154

In my head, these things make perfect sense for me:

• Euclidean space in Sage is an affine vector space.
• The symplectic space above is an affine space, too, endowed with a symplectic structure.
• As for the vector space structure, I think we should link the Euclidean space to preexisting vector spaces endowed with bilinear forms.

I am open to suggestions, different opinions and arguments. :)

But that's not for this ticket.

[egourgoulhon]

comment:155

By the way, why don't you add StandardSymplecticSpace to the manifold catalog? This would avoid having to import it:

- sage: from sage.manifolds.differentiable.examples.symplectic_space import StandardSymplecticSpace
- sage: M.<q, p> = StandardSymplecticSpace(2, symplectic_name='omega')
+ sage: M.<q, p> = manifolds.StandardSymplecticSpace(2, symplectic_name='omega')

To do this, simply add

_lazy_import('sage.manifolds.differentiable.examples.symplectic_space',
             'StandardSymplecticSpace')

to the file src/sage/manifolds/catalog.py (see e.g. the example of Sphere in that file).

[egourgoulhon]

comment:156

Replying to @mjungmath:

Well, the Euclidean space is abbreviated with E^n and not R^n. Perhaps we should do the same here, too?

-1. R^n is certainly much more standard here.

[mjungmath]

comment:157

Replying to @egourgoulhon:

Replying to @mjungmath:

Well, the Euclidean space is abbreviated with E^n and not R^n. Perhaps we should do the same here, too?

-1. R^n is certainly much more standard here.

Mhm. Well, since StandardSymplecticSpace inherits from EuclideanSpace, such an object still carries the structure of Euclidean space. I see your point though. Difficult...

[mjungmath]

comment:158

Replying to @egourgoulhon:

By the way, why don't you add StandardSymplecticSpace to the manifold catalog? This would avoid having to import it:

- sage: from sage.manifolds.differentiable.examples.symplectic_space import StandardSymplecticSpace
- sage: M.<q, p> = StandardSymplecticSpace(2, symplectic_name='omega')
+ sage: M.<q, p> = manifolds.StandardSymplecticSpace(2, symplectic_name='omega')

To do this, simply add

_lazy_import('sage.manifolds.differentiable.examples.symplectic_space',
             'StandardSymplecticSpace')

to the file src/sage/manifolds/catalog.py (see e.g. the example of Sphere in that file).

Big +1.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

cfe6a24

Remove vector

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from cdffbb2 to cfe6a24

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from cfe6a24 to 2208dfc