-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Relabeling #17
Comments
@pdobsan: let me know if you'd like me to take a look at the code at any point, or contribute in any other way. Happy to help! |
On Sat, Jul 17, 2021 at 05:29:07PM -0700, sammorley-short wrote:
@pdobsan: let me know if you'd like me to take a look at the code at
any point, or contribute in any other way. Happy to help!
Yes please have a look at it. As you can see the isomorphism tests pass
for all graphs. The canonical labeling however seems to be not invariant
under random relabeling. The canon_label tests fall for most graphs,
depending on the relabeling. Multiple runs gives different results,
sometimes with very long running times.
|
I have cleaned all tests up a bit. In particular I removed the
`delete_random_edge` part from `test_canonlabel.py`. It did not make any
sense, non isomorphic graphs can have the same canonical labeling. I am
not clear about isomorphic ones yet.
Made a target just for canonlabel, invoke it as `make canonlabel-test`.
Most graphs "fail" when the random permutation of vertices is applied.
|
Hi! I was surprised to find that re-applying @sammorley-short could you possibly look into that and fix the function? I can provide examples of (simple) graphs where the function failed for me. |
Because the graph is simple (just 4 nodes) I'll leave it here:
To my understanding |
What seems to work for now is creating the canon graph from the certificate as described here: #30 (comment) In my case:
|
P.S.: It was even possible to remove one direction of each undirected edge to get
For which Note: to get a relabeling I then used networkx's |
On Wed, Sep 20, 2023 at 01:43:45PM -0700, CharHeap wrote:
What seems to work for now is creating the canon graph from the
certificate as described here:
#30 (comment) for
which `canon_label` returns the identity.
Please note that a canon_graph() function is already implemented but not
released yet. So with the current repo, your graph should work like below.
In [3]: g1 = Graph(number_of_vertices = 4, directed = False,
...: adjacency_dict = {
...: 0: [2, 3],
...: 1: [2, 3],
...: },
...: vertex_coloring = [
...: ],
...: )
In [4]: canon_label(canon_graph(g1))
Out[4]: [0, 1, 2, 3]
|
Thanks for your reply. It's true that canon_label returns the identity after canon_graph has been applied, but that is not what I need. I need/was expecting canon_label(g1) to return a re-labeling that, when applied to g1, makes it canon.
EDIT: I compared the mappings I had tediously computed with networkx and the output of canon_label and noticed that I had just interpreted the output wrongly. As an example: [3, 4, 0, 1, 2], here I though I had to map 0 to 3, 1 to 4, 2 to 0 and so on.. When in fact I need to map it the other way around! 3 to 0, 4 to 1, 0 to 2.. So at index
|
Write a procedure to create a new graph by relabeling an existing graph according to a permutation of its vertices.
Rewrite/extend isomorphism and canonical labeling tests using relabeling by random permutations.
Related branch: relabeling
The text was updated successfully, but these errors were encountered: