The only way "my" ribbon graphs differ from rotation systems is that rotation systems are closed ribbon graphs. I would also have boundary points where the involution is not defined. Then I have implemented a "cobordism category" of such things.
On Oct 3, 9:04 pm, Tom Boothby <[email protected]> wrote: > Bruce, > > Please keep posting here; or at the very least, copy me on the > conversation. I'm curious how your "ribbon graphs" differ from > orientable maps. I implemented Graph.genus(), which enumerates > "rotation systems" which represent a given graph embedded on an > orientable surface. > > To me, a rotation system is a fixed-point free involution (e) and > another permutation (v). If #p is the number of orbits of a > permutation, the Euler characteristic of the rotation system is > #v-#e+#(ev). > > The definition of a ribbon graph that I've seen is a topological > structure where vertices of a graph are taken to be discs, and edges > are taken to be 'ribbons' glued to the boundary of the discs, possibly > with twists and knotting. Seehttp://arxiv.org/abs/math-ph/9811024 > for some example pictures. > > On Mon, Oct 3, 2011 at 5:24 AM, Bruce <[email protected]> wrote: > > > On Oct 3, 11:16 am, Vincent Delecroix <[email protected]> > > wrote: > >> As far as I understand, your index.html should be built from the > >> source. But I read the source and I find it not well documented from > >> the point of vue of programmer. I'm really interested in your code as > >> I implement similar stuff and it would be "time saving" to merge our > >> classes. Moreover, I could help to submit your code to Sage. > > At the moment I don't know what you have done or what you are trying > > to do. > > >> 1) You wrote : "A Ribbon graph is a finite set with an involution and > >> a bijection". You did not precise that the involution is without fixed > >> point ? Is that volunteer ? In the book I mentionned, the author even > >> authorize any permutations. This is useful from the point of vue of > >> Grothendieck's "dessin d'enfants" as a Ribbon graph also encode a > >> ramified covering of the sphere over three points. > > > Yes, the involution has no fixed points and it would have been helpful > > if I had said this. The book you mentioned has been taken out of > > the library. I have recalled it but for now I have to wait. > > >> 2) The advantage I get from the representation with three permutations > >> (s,a,f) (s for vertices, a for edges and f for faces) is that it is > >> immediate to get the inverse. Moreover, it emphasize a duality (s,a,f) > >> -> (f^-1, a^-1, s^-1) which corresponds to the standard duality of > >> embedded graphs. But perhaps, it is out of your interest (but your > >> function anti (which is NOT documented) seems to do that operation). > > > I am not familiar with your notation. In the notation I adopted you > > move > > around an vertex clockwise. The function anti just moves > > anticlockwise. > > The dual graph is constructed by replacing the clockwise map c by > > either > > ce (or ec) where e is the involution. > > >> 3) As I mentionned, I only deal with subsets of {0,1,...,n-1} where > >> you seem to be interested in more general subsets. The way > >> permutations are actually implemented with Sage suggest that the base > >> class deal with subsets of {0,1, ..., n-1} and a derived class could > >> use a permutation with domain (which is just a mapping from {0,1, ..., > >> n-1} to a subset of size n). But on the other hand, there are very > >> standard operations which consists to remove edges and it is very > >> natural in that context tu use "partial permutation". > > I don't follow you. > > >> 4) Your main class halfedge contains two mysterious arguments "IsI" > >> and "decorations". What are they ? > > The IsI is for technical reasons. The decorations is to allow edges to > > be drawn differently. > > >> 5) If you intend to put your code inside Sage, I find the way > >> classes/functions are implemented is not clear. Why join is a function > >> and not a method (as union for Python set) ? Moreover, in Sage, there > >> is a convention that any class should be denoted in Wiki syntax as > >> MyFavoriteClass and functions should use lower case with underscore as > >> my_favorite_function (There are counterexample inside Sage). In your > >> case, you should be much more precise in the choosen names : Embedding > >> should become for example RibbonGraphEmbedding or similar. > > I think it is clear. I accept I may not have followed conventions. > > I have no problem with editing names. > > >> I have many more comments, but I would like to have more > >> specifications in each of the methods (and not more example). I want > >> to understand what is implemented (and how) and not what the code can > >> do. > > Maybe we should discuss this further off-line. Please feel free to e- > > mail me. > > >> Cheers, > >> Vincent > > > -- > > You received this message because you are subscribed to the Google Groups > > "sage-combinat-devel" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/sage-combinat-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
