Degree sequences and signatures are related, so it seems reasonable that Faulon's orbit-saturation algorithm for enumerating molecules should also work for just degree sequences. For example, height-1 signatures for a carbon skeleton are practically identical to a degree sequence. See this image for details:
On the left is a target signature, with its corresponding carbon skeleton below. On the right is the equivalent degree sequence, and its simple graph. Of course, signatures can handle multiple bonds, and different elements, but the principle is the same.
So the major problem with Király's method for enumerating graphs from their degree sequences is that it produces isomorphic solutions. The problem I had with Faulon's method was that I couldn't get it to work! A functional implementation for the (much simpler) degree sequence problem should help.
Encouragingly, the initial crude implementation does work for simple examples. The key seems to be to check that a solution is canonical by permuting within the original orbits, and not the final ones. The example I have been using is the sequence [3, 3, 2, 2, 1, 1] and one of its solutions is instructive here:
These two graphs are isomorphic, but the one on the left is the canonical form according to its adjacency matrix (below each graph). The matrix can be converted to a string by reading left-to-right and top-to-bottom (below each matrix). These strings can be compared to find a maximum one - which is the left hand one in this case as 11100... is greater than 10011... (etc).
To efficiently generate graphs, it is necessary to be able to test these strings without storing all the already generated isomorphs. A simple way to test for a canonical graph is to try all permutations of labels on the vertices; in other words, renumber the graph. Now clearly the only way to renumber the left hand graph here to get the right is to permute labels on vertices 0 and 1.
However, in the final graphs, these are in different orbits! So it may be that it is necessary to use the original orbits - which is just that induced by the degree sequence, or [{0, 1}, {2, 3}, {4, 5}]. Time will tell...
One final problem is that this simple canonical checking procedure is very expensive for large regular graphs. For [3, 3, 3, 3, 3, 3, 3, 3] (38) we get various graphs, including a cube and a cuneane-like graph, but the canonical check has to try 8 factorial (8!) permutations for each successful solution.
Luckily there is a solution - the good old partition refiner :) It seems to work so far.
So the major problem with Király's method for enumerating graphs from their degree sequences is that it produces isomorphic solutions. The problem I had with Faulon's method was that I couldn't get it to work! A functional implementation for the (much simpler) degree sequence problem should help.
Encouragingly, the initial crude implementation does work for simple examples. The key seems to be to check that a solution is canonical by permuting within the original orbits, and not the final ones. The example I have been using is the sequence [3, 3, 2, 2, 1, 1] and one of its solutions is instructive here:
To efficiently generate graphs, it is necessary to be able to test these strings without storing all the already generated isomorphs. A simple way to test for a canonical graph is to try all permutations of labels on the vertices; in other words, renumber the graph. Now clearly the only way to renumber the left hand graph here to get the right is to permute labels on vertices 0 and 1.
However, in the final graphs, these are in different orbits! So it may be that it is necessary to use the original orbits - which is just that induced by the degree sequence, or [{0, 1}, {2, 3}, {4, 5}]. Time will tell...
One final problem is that this simple canonical checking procedure is very expensive for large regular graphs. For [3, 3, 3, 3, 3, 3, 3, 3] (38) we get various graphs, including a cube and a cuneane-like graph, but the canonical check has to try 8 factorial (8!) permutations for each successful solution.
Luckily there is a solution - the good old partition refiner :) It seems to work so far.
Comments