Ordering issue about networkx HOT 2 CLOSED

Good point --
Looking at how isomorphVF2.py handles this we should probably check some obvious things before ever giving the graphs to the isomorphism solver:

• number of nodes (== for ISO problem, <= for sub_iso and for mono)
• sorted degree values agree (== for ISO, might need to count how many of each and <= for sub_iso and mono)
• sorted label values agree (== for ISO, again might need to count and <= for sub_iso and mono)

I think the ordering should assume that we have made these checks. The difference between problem types might affect something here -- but I think it doesn't. You/we should think that through at some point. The ordering requires the initial F_M_L be set based on G2 label. We should think about whether those values can become negative as we update F_M_L while creating the ordering. G1 must be <= G2 for the sub_iso and mono problems. So I think we will never get negative values so long as we make sure the counts are <=. But I am not entirely sure -- this is my intuition.

When you say that the ordering crashes, what do you actually see? I assume it "raises" because Python doesn't "crash" very often :) What is the exception that is raised when the labels are not the same? Will these kinds of checks avoid these problems?

from networkx.

Good point -- Looking at how isomorphVF2.py handles this we should probably check some obvious things before ever giving the graphs to the isomorphism solver:

• number of nodes (== for ISO problem, <= for sub_iso and for mono)
• sorted degree values agree (== for ISO, might need to count how many of each and <= for sub_iso and mono)
• sorted label values agree (== for ISO, again might need to count and <= for sub_iso and mono)

I think the ordering should assume that we have made these checks. The difference between problem types might affect something here -- but I think it doesn't. You/we should think that through at some point. The ordering requires the initial F_M_L be set based on G2 label. We should think about whether those values can become negative as we update F_M_L while creating the ordering. G1 must be <= G2 for the sub_iso and mono problems. So I think we will never get negative values so long as we make sure the counts are <=. But I am not entirely sure -- this is my intuition.

When you say that the ordering crashes, what do you actually see? I assume it "raises" because Python doesn't "crash" very often :) What is the exception that is raised when the labels are not the same? Will these kinds of checks avoid these problems?

This is handled in the updated version. I created a function "precheck" that performs all the necessary checks before calling the solver as you suggested. I also added multiple unit tests.

from networkx.