Compute the category of a polygon gluing

[videlec]

We have different relevant "categories" of geometric structures on surfaces (the class SimilaritySurface and its subclasses in the current code). The relevant smallest category associated to a given polygon gluing (ie an object of type Surface) can easily be determined. One just need to compute the smallest group that contains all edge gluings among

• the affine group (SimilaritySurface)
• isometries (ConeSurface)
• isometries with finite order linear part (RationalConeSurface)
• isometries with order at most 2 linear part (HalfTranslationSurface)
• dilations (DilationSurface)
• translations (TranslationSurface) The current code implemented in the various _test_edge_matrix checks that the edge gluing belongs to the given group. But we are lacking the computation the other way around. We should just implement Surface.edge_gluing_category (or anything under a better name).

Note that the group determined by edge gluing is not a "mathematical" answer : it would rather the group containing the holonomy of the geometric structure (which is made of compositions of edge gluings along loops in the surface). The latter should be accessible as well. Maybe via Surface.holonomy_category (or anything under a better name).

Note that there is always a way to change the polygons via some affine transformation so that the "edge gluing category" and the "holonomy category" coincide. Namely, we just pick a spanning tree of the dual, and make trivial the gluings along the edge of the spanning tree. We should have a method that provides this cleaning. Something like Surface.clean.

[wphooper]

I've been doing some work related to the Surface.clean idea. I've been working on "canonicalization" of surfaces as we have now for translation surfaces, which gives a new presentation of a translation surface with the property that if two presentations agree as translation surfaces, then their canonicalized versions are identical.

The new scheme works for Similarity, Dilation, Half-Dilation, Half-Translation and Translation surfaces (but not for Cone surfaces without a new idea). First you do a Delaunay Decomposition. The main difficulty in this is then choosing a base polygon, choosing a zero vertex for the base polygon, and positioning the base polygon in the plane. Once this is done, the SurfaceWalker (obtainable as s.walker where s is a Surface) does a breadth-first walk of the labels in the surface. Using this:

• Polygons are relabeled by integers according to the order visited by the walker (so the base label becomes 0).
• Polygons other than the base polygon are combinatorially rotated (edges relabeled cyclically) such that the edge the walker comes through to first visit the polygon is edge 0.
• Polygons other than the base polygon are transformed by the similarity which makes its edge zero differ from the edge it is glued to by translation.

The four bulleted steps above seem similar to your clean idea, but also relabel the polygons, and I already have code for them. I was already planning on incorporating this code, but I've been too busy lately. I should have some time in January.

[videlec]

Canonicalization is much more subtle then what I want to do here. To do category detection, we just need to compute the holonomy of the affine structure.

[wphooper]

Sorry, I don't think I was clear about the relation to what you propose.

As you suggest, we should certainly have something like Surface.edge_gluing_category.

I have written code that moves the polygons so that edges in a spanning tree differ by translation (as suggested for the Surface.clean). This is reposition_polygons in one of my branches, though a minor difference is that I was working in SimilaritySurface.

As you indicated, to get Surface.holonomy_category, you can apply this reposition_polygons method and then the to be written Surface.edge_gluing_category.

[videlec]

Indeed, this is what I was intended to code here. Though, why not having it directly as a method of Surface ?

[wphooper]

I think it was mainly a slight difference in philosophy. I tended to think of Surface as just a vehicle for the storage of a presentation and use SimilaritySurface for everything else. Most of the time when I actually make use of the program, I want access to a SimilaritySurface (or TranslationSurface etc.) and forget about the underlying Surface once it is constructed. From this point of view, putting the method in Surface just makes it less accessible.

As I said, I was viewing this as a step in canonicalization, and for this it makes sense to have an explicit geometric structure selected (though again maybe there are different philosophies here too).

I suspect it would be easy to adapt the code to include it in Surface instead if that is what is preferred. I don't feel that strongly.