For the decomposition of a graph representing a map, I’m trying to use different algorithms to select the edge to remove.

The question is:

When you have multiple valid choices, which is the best edge to select … if any?

Some basic rule are:

Avoid new F5 to be created

Get rid of F5 whenever is possible, selecting the edge of a face with 2, 3 or 4 edges

Consider to remove an edge from an F5 face only if no faces with 2, 3, 4 edges exist

Here are all possibilities. Last 2 groups (removing edges from F5 and F6) don’t have to be taken into account. I just wanted to see how it continued after the cases with faces made of 2, 3, 4 and 5 edges:

Select an F2, F3 or F4 preferably when it is near an F5 and remove the edge that joins the two faces

Analyse also the balance of the Euler’s identity when removing edges, to decide if it is better to choose other couple: F2 near the highest or other possibilities

Let Deepmind DQN (or Tensorflow) learn the best approach for selecting faces and remove the edges

Controls:

The selection of the face and the edge based on the characteristics of the neighbor faces

Scope:

Avoid the F5 worst case (in the rebuilding phase), when it is necessary to apply the random Kempe’s color switches to solve the impasse

The rule: avoid F5 or at least do not create them.

Remove F2 when near F5 –> Good (will get rid of the F5 and generate an F3)

Remove F3 when near F5 –> Good (will get rid of the F5 and generate an F4)

Remove F4 when near F5 –> NOT Good (will end up with another F5)

Remove F5 when near F5 –> Good (will get rid of the F5 and generate an F6)

Other to avoid:

Remove F2 when near F7 –> NOT Good (will end up with another F5)

Remove F3 when near F6 –> NOT Good (will end up with another F5)

…

NOTE:

It is also important to check what appens to f3 and f4

The algorithm I use to color graphs works pretty well … BUT:

Sometimes (very rarely) it gets into an infinite loop where also random Kempe color switches (around the entire graph) do NOT work. The good is, if I reprocess the same graph from the beginning (since in a part of the code I choose edges randomly), the algorithm usually works fine

So, what now?

I want to try other strategies while removing edges from the original graph, to avoid the above condition. I want to eliminate the need of random swithes.

The sequence I used so far is:

Select an F2 and if an F2 does not exist, select an F3 an so on: F4 and then F5. Once selected the face, I remove a random edge from it, only paying attention not to chose the edge if the resulting graph is 1-connected

I want to try:

Change the order of selecting the faces

Combinations

2, 3, 4, 5 –> This is the default in the current version of the program (22/Nov/2016)

3, 2, 4, 5

4, 2, 3, 5

…

I want to try all possible combinations to see if … may be … if I’m really lucky, some does not require random swithes

Once selected the face, I want to try other strategies to select the edge to remove

random edge –> This is the default in the current version of the program (22/Nov/2016)

Among all the edges of the face, select the one that is shared with the face that has less edges respect to the other F

… that has more …

A planar cubic graphs to visualize what I wrote in this post:

Experimenting with the Python program, I have found that if you have an F5 impasse, a single switch may not be enough to solve the impasse. It means: counterexample found.

This is a bad news, since I believed that a single switch, on an appropriate edge, could have been the key to solve the theorem.

BUT

Since a limited number of switches still work, I am going to study if two switches, on appropriate edges, may work.

Note about the Python program: To try the Python program you need to have Sage. Follow Sage instructions to install it on your computer: http://www.sagemath.org.

The algorithm considers Tait edge coloring and the equivalency of the 3-edge-coloring (known as Tait coloring) and the 4-face-coloring (the original four color theorem for maps).

The algorithm goes like this:

It uses a modified Kempe reduction method: it does not shrink a face (faces <= F5) down to a point, but removes a single edge from it (from faces <= F5)

It uses a modified Kempe chain edge color switching: when restoring edges from the reduced graph, it will swap half of the colored Kempe loop

Note that while rebuilding a map, all Kempe chains are actually Kempe loops!!!

These are the stats:

100 – 196 vertices, 294 edges = 0 seconds

200 – 396 vertices, 594 edges = 1 seconds

300 – 596 vertices, 894 edges = 4 seconds

400 – 796 vertices, 1194 edges = 6 seconds

500 – 996 vertices, 1494 edges = 8 seconds

600 – 1196 vertices, 1794 edges = 10 seconds

700 – 1396 vertices, 2094 edges = 16 seconds

800 – 1596 vertices, 2394 edges = 18 seconds

900 – 1796 vertices, 2694 edges = 22 seconds

1000 – 1996 vertices, 2994 edges = 26 seconds

Almost linear … what do you think?

The first column is the original number of vertices for the planar triangulation from which the dual graph (a cubic planar graph) is computed. The seconds reported above do not consider the time to load or create the imput graph and to compute the planar embedding. You can also upload an already planar embedded graph using the -p option.

The same problem of coloring the egdes using the Sage function edge_coloring() requires very long time. I run 15 tests, and to color random graphs with 196 vertices and 294 edges, took: 7, 73, 54, 65, 216, 142, 15, 14, 21, 73, 24, 15, 32, 72, 232 seconds, for the same case where my algorithm takes less than 1 second: 100 – 196 vertices, 294 edges.

For the F5 case which requires the adjustments, I tried the following:

I tried to swap colors on a local Kempe loop, starting from an edge belonging to the face to restore (local)

It does not always work and for particular cases the algorithm can loop forever

I tried to swap colors on a Kempe loop along the edges of one of the two main loops at e1 or e2 (the two edges where the edge to restore ends),

It does not always work and for particular cases the algorithm can loop forever

I tried to swap colors on random Kempe loops around the map

It always works (so far) and these adjustments (Kempe loop color switches) are rare

The only (!?!?!?!?) thing that needs to be proved is that random switches of colors of Kempe loops is always possible to solve any type of impasse. I mean, for now I’m dealing with random attemps, I need to understand how the Kempe loops are related to each other and then find a way to know on which one I need to swap colors.

Something I need to modify about the Python program:

Read planar embedded graphs as Python list of lists of tuple: [[()()][()()()][()()()]]