2019-11-12 18:05:13 +0200 | received badge | ● Famous Question (source) |

2019-04-30 07:05:28 +0200 | received badge | ● Notable Question (source) |

2016-08-31 09:13:23 +0200 | received badge | ● Notable Question (source) |

2015-10-22 00:53:05 +0200 | received badge | ● Popular Question (source) |

2015-01-17 21:22:48 +0200 | received badge | ● Popular Question (source) |

2012-09-12 19:44:44 +0200 | commented answer | Does Sage keep the order of vertices in a graph and it's group or scramble them? For me it sometime scrambles them. I meant kcrisman, sorry. |

2012-09-12 18:40:13 +0200 | answered a question | Does Sage keep the order of vertices in a graph and it's group or scramble them? For me it sometime scrambles them. I found there is a translation table keyword option for the automorphism_group() call which returns a table showing which vertex indices (which go from 0 to n-1, where n is the group order) match the cycle labels (which go from 1 to n since they must all be > 0 integers). The table tells you how Sage is internally ordering the vertices so you can match up the output group matrices with your original vertex vector space. This helps align your adjacency matrix with the outputs from the automorphism_group method and other items calculated from that group like the matrices. Get more info by typing D.automorphism_group?? where D is a graph based on your input adjacency matrix. Thanks to krisman for suggesting I look at D.automorphism_group?? info. |

2012-09-12 14:40:10 +0200 | commented answer | Does Sage keep the order of vertices in a graph and it's group or scramble them? For me it sometime scrambles them. Thanks for the answer Kcrisman. I looked at automorphism_group?? and I may have found the answer. There is a keyword option 'translation' which gives a dict for mapping from vertices of the graph (dict keys using python indexing from 0) to the permutation elements (1,2,3,...) which must be positive integers. When I printed the dict for a simple graph the 0th vertex is mapped to the last integer, the others appear to be mapped to the same integer as the python index (since those are positive and non-zero). Does this sound right? I will be experimenting with this "reordering" and I'll let you know if it worked. Thanks, you might have solved another group-graph puzzle for me. |

2012-09-12 12:20:15 +0200 | asked a question | Does Sage keep the order of vertices in a graph and it's group or scramble them? For me it sometime scrambles them. I use the Sage automorphism_group function to find the group that leaves an adjacency matric, say C, invariant under a similarity transformation. But sometimes it seems the results are for matrices on a vertex space that is not the same as the original, but is reordered. A simple example on a 3-vertex graph: o--o--o. Adjacency matrix= C = The group is the identity and a reflection about the center vertex: I would have expected the reflection to be, but R is what Sage gives. Sure enough, RCR^-1 gives the following, which is invariant. The last matrix is the C matrix where the vertices are indexed in reverse order. Does Sage have some canonical way it orders the vertices in graphs and groups? A bit more info, maybe. The order of the irreducible representation table seems to give a hint. If the trivial representation is the first row (which it is for some graphs), it appears (from a few tests) that the vertices retain their original order to align with C. If the trivial representation is the last row then the matrix C' is the adjacency matrix (suggesting a reordering of the vertices). I have no idea why this should be related if it is. Bottom line for me is I cannot apply any matrices from the group that come from the matrix() method to C or other objects in my original vertex space since they are ordered differently. I don't see how to find the vertex order sage uses. Any help or insight appreciated. |

2012-09-12 11:01:46 +0200 | answered a question | Order of Irreducible Representation Characters wrong in Sage? Yes, I made the mistake of confusing IRR characters and conjugacy classes. I'm sorry for the confusion and taking so long to respond. Thanks for the many replies. I have that cleared up now. |

2012-09-10 14:42:41 +0200 | commented answer | Order of Irreducible Representation Characters wrong in Sage? I think I am mixing things up. Let me sit back and get it straight. Thank you for helping. |

2012-09-06 12:26:54 +0200 | commented answer | Order of Irreducible Representation Characters wrong in Sage? Running in Sage both character_table() and irreducible_characters() agree with conjugacy_classes_representatives() order. *But when I run from Python the order of characters from both calls are scrambled in the same way and no longer agree with the order as given in Sage or Python for the conjugacy_classes_representatives. So Python give same conjugacy_classes_representatives order as Sage, but not so for character tables done either way. |

2012-09-06 12:19:09 +0200 | received badge | ● Supporter (source) |

2012-09-06 12:19:00 +0200 | commented answer | Order of Irreducible Representation Characters wrong in Sage? I used irreducible_characters() and displayed them with [x.values() for x in irr]. The order appears correct now. Thank you. |

2012-09-06 11:04:45 +0200 | asked a question | Order of Irreducible Representation Characters wrong in Sage? I am using Sage to calculate Irreducible Representations (IRR) of symmetry groups of graphs. Most of the time the order of the IRR characters match the order of the conjugacy class representatives. For example the trivial representation characters are the first row of the character table (1,1,1,1,...,1) and the first conjugacy class is ( ), the identity representation. But in the example below for a star graph (one central vertex, the 4 other vertices on spokes from the center) the trivial representation characters are the Example (star graph). Is this a bug or known issue for Sage? How can I get around it so I know the orders of the characters and representatives match up properly? |

Copyright Sage, 2010. Some rights reserved under creative commons license. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.