UNIVERSITY OF LJUBLJANA

FACULTY OF MATHEMATICS AND PHYSICS

Financial mathematics – 1st cycle

Tanja Luštrek, Anej Rozman

Rich-Neighbor Edge Colorings

Term Paper in Finance Lab

Long Presentation

Advisers: Assistant Professor Janoš Vidali,

Professor Riste Škrekovski

Ljubljana, 2023
 Contents
1. Introduction 3
2. Algorithms 4
2.1. Integer Programming 4
2.2. Iterative Algorithm 6
3. Complete Search 7
3.1. Graph Generation 7
4. Random Search 7
4.1. Graph Generation 8
5. Checking the Coloring 8
6. Findings 10
6.1. Problems 10
6.2. Conclusion 10
References 10
 1. Introduction
In this paper we set out to analyse an open conjecture in a modern graph theory
problem known as rich-neighbor edge coloring.

Definition 1.1. In an edge coloring, an edge e is called rich if all edges adjacent
to e have different colors. An edge coloring is called a rich-neighbor edge coloring
if every edge is adjacent to some rich edge.
′
Definition 1.2. Xrn (G) denotes the smallest number of colors for which there exists
a rich-neighbor edge coloring.
′
Conjecture 1.3. For every graph G of maximum degree ∆, Xrn (G) ≤ 2∆−1 holds.

In the paper we focus on analysing the conjecture only for regular graphs. We
did this by implementing an integer programming model that finds a rich-neighbor
edge coloring for a given graph using the smallest number of colors possible.

Example 1.4. Let’s take a look at the Petersen graph and an example of a rich-
neighbor edge coloring.

1
5 2
5 2

4 3

4 3

We can see that for the Petersen graph (which is 3-regular) we can find an appropri-
′
ate coloring with 5 colors so Xrn ≤ 5 ≤ 2 · 3 − 1 = 5. This shows that the conjecture
holds for this graph. ♢
i
i
i
i
i
i
i
i
i
i
i

3
 2. Algorithms
2.1. Integer Programming
Using SageMath we implement an integer program that finds a rich-neighbor
edge coloring for a given graph using the smallest number of colors possible. Writen
matematically, our interger program looks like this:

minimize t P2∆−1 we minimize the number of colors we need

subject to ∀e : i=1 xei = 1 each edge is exactly one color

∀i ∀u ∀v, w ∼ u, v ̸= u : xuv,i + xuw,i ≤ 1

hihi edges with the same vertex are a different color

∀e ∀i : xei · i ≤ t we use less or equal to t colors

∀i ∀uv ∀w ∼ u, w ̸= v ∀z ∼ v, z ̸= u, w : xuw,i + xvz,i + yuv ≤ 2

hihi uv is a rich edge ⇔ all adjacent edges are a different color
P
∀e : f ∼e yf ≥ 1 every edge is adjacent to some rich edge

∀e : 0 ≤ ye ≤ 1, ye ∈ Z solutions are binary variables

∀e ∀i : 0 ≤ xei ≤ 1, xei ∈ Z,

where

( (
1, if edge e is color i 1, if edge e is rich
xei = and ye =
0, otherwise 0, otherwise.

In our implementation of the ILP we fix the number of colors to 2∆ − 1 by adding

the following constraint t = 2∆ − 1. We do this since the coloring can’t be made
with less colors, because every edge has 2∆ − 2 neighboring edges and the edge itself
has to be a different color.

k −1
.. 2k ..
. 1 .
a b k+
2 1

And since any coloring with more than 2∆ − 1 colors does not satisfy the conjec-
ture, we only check if the program has a solution that satisfies all the constraints.
In theory this doesn’t make the program faster, but in our practice tests it did make
a significant differnece.

4
 Our actual implementation of the ILP is demonstrated in the following code.

Algorithm 1: richNeighbor
Input: graph G
Output: colors of edges colors, rich edges richEdges
p ← MixedIntegerLinearProgram(maximization = False)
x ← p.new variable(binary = True)
y ← p.new variable(binary = True)
t ← p.new variable(integer = True)
p.set objective(t[0])
maxCol ← 2 · G.degree()[0] − 1
p.add constraint(t[0] = maxCol)
for e in G.edges(labels = False) do
p.add constraint( maxCol
P
i=1 x[Set(e), i] = 1)
for (u, v) in G.edges(labels
P = False) do P
p.add constraint( j∈G[u] y[Set((u, j))] + l∈G[v] y[Set((l, v))] −
2y[Set((u, v))] ≥ 1)
for e in G.edges(labels = False) do
for i in 1 to maxCol do
p.add constraint(i · x[Set(e), i] ≤ t[0])
for i in 1 to maxCol do
for (u, v) in G.edges(labels = False) do
for w in G[u] do
if w = v then
continue
p.add constraint(x[Set((u, v)), i] + x[Set((u, w)), i] ≤ 1)
for z in G[v] do
if z = u then
continue
p.add constraint(x[Set((u, v)), i] + x[Set((v, z)), i] ≤ 1)

for (u, v) in G.edges(labels = F alse) do

for w in G.neighbors(u) do
for z in G.neighbors(v) do
if w = v or z = u then
continue
for i in 1 to maxCol do
p.add constraint(x[Set((u, w)), i] + x[Set((v, z)), i] +
y[Set((u, v))] ≤ 2)

return colors, richEdges

5
Example 2.1. Using the richNeighbor algorithm on the Petersen graph gives us
the following output.

colors = {({0, 1}, 1) : 0.0, ({0, 1}, 2) : 0.0, ({0, 1}, 3) : 0.0, ({0, 1}, 4) : 0.0,
({0, 1}, 5) : 1.0, ({0, 4}, 1) : 0.0, ({0, 4}, 2) : 0.0, ({0, 4}, 3) : 1.0,
···
({9, 6}, 3) : 0.0, ({9, 6}, 4) : 0.0, ({9, 6}, 5) : 0.0, ({9, 7}, 1) : 0.0,
({9, 7}, 2) : 0.0, ({9, 7}, 3) : 0.0, ({9, 7}, 4) : 1.0, ({9, 7}, 5) : 0.0}

richEdges = {{0, 1} : 1.0, {0, 4} : 0.0, {0, 5} : 0.0, {1, 2} : 1.0, {1, 6} : 0.0,
{3, 4} : 0.0, {9, 4} : 1.0, {5, 7} : 0.0, {8, 5} : 1.0, {2, 3} : 1.0,
{2, 7} : 0.0, {8, 6} : 0.0, {9, 6} : 0.0, {8, 3} : 1.0, {9, 7} : 1.0}

Both colors and richEdges are dictionaries and their key-value pairs are structured
like
( (
1.0, if edge e is color i 1.0, if edge e is rich
(e, i) : and e:
0.0, otherwise 0.0, otherwise.
♢

2.2. Iterative Algorithm

We debated implementing an iterative algorithm that finds a rich neighbor edge
coloring, but we were not able to come up with anything that runs in polynomial
time. From [1] we know that integer linear programs are NP-complete problems, so
it did’t make much sense implementing another slow algorithm, since it wouldn’t
make much of a difference in the number of graphs we would be able to check. i
i
i
i
i
i
i
i
i
i
i
i
i
i
i
i

6
 3. Complete Search
As illustrated in Table 1, the number of k-regular graphs on n vertices grows
exponentially with n. This poses a computational challenge, as checking all graphs
becomes impossible for larger values of n. However, we can still check all graphs for
smaller values of n up to 13.
Vertices Degree 4 Degree 5 Degree 6 Degree 7
5 1 0 0 0
6 1 1 0 0
7 2 0 1 0
8 6 3 1 1
9 16 0 4 0
10 59 60 21 5
11 265 0 266 0
12 1544 7848 7849 1547
13 10778 0 367860 0
14 88168 3459383 21609300 21609301
15 805491 0 1470293675 0
16 8037418 2585136675 113314233808 733351105934

Table 1. Number of k-regular graphs on n vertices [2]

3.1. Graph Generation

Graphs for the complete search were taken from a collection of files, provided by
Professor Škrekovski. The files contain all k-regular graphs on n vertices up to 15
vertices, since the number of graphs beyond that is too much to handle.

4. Random Search
In addition to examining the hypothesis for smaller graphs, we were also interested
in checking if the conjecture holds for larger graphs. The challenge here is testing
all possible colorings in graphs with many vertices. Recognizing the enormity of this
task, a random search algorithm seemed like a natural continuation of our problem.
Here we opted for a modification approach.

We start with a random graph and use our ILP to check if the conjecture holds for
it. Then, we modify the graph in a way that preserves its regularity and connected-
ness. We repeat this process indefinitely, or actually, until we stop our program. We
know that if a rich-neighbor edge coloring exists in a given graph, there is a higher
probability that it also exists in similar graphs. Therefore, on every iteration, we
keep a small probability that we generate a completely new random graph and start
again.

i
i
i
i

7
 Written below is the algorithm tweak for modifying graphs. First it selects two
random edges and deletes them. Then it generates a random number p from [0, 1)
and based on the value of p it adds back two different edges in one of two possible
ways that preserve the regularity of the graph. Since there is a chance that the
newly formed graph is not connected, we check for that and if it is not, we restart
the process until we get a connected graph.

Algorithm 2: tweak
Input: graph G
Output: tweaked graph T
T ← graph.copy()
e1 ← T.random edge()
u1 , v1 , ← e1
T.delete edge(e1 )
e2 ← T.random edge()
u2 , v2 , ← e2
T.delete edge(e2 )
p ← random()
if p < 0.5 then
T.add edge(u1 , u2 )
T.add edge(v1 , v2 )
else
T.add edge(u1 , v2 )
T.add edge(v1 , u2 )
if not T .is connected() then
return tweak(G)
return T

4.1. Graph Generation

Since we only need one graph to start our iterative process, we can generate it
randomly, using the built-in SageMath function graphs.RandomRegular.

5. Checking the Coloring

In order to make sure that our ILP implentation is without fault, we also imple-
ment the functions checkColoring and checkRichness which check if our program
always returns a proper coloring, and if the coloring is actually a rich-neighbor edge
coloring.
i
i
i

8
 checkColoring takes a graph G and the output colors of our ILP. It iterates
over each vertex in the graph, checks all edges adjacent to it, and returns false if it
finds two or more edges with the same color.

Algorithm 3: checkColoring
Input: graph G, colors of edges coloring
Output: Boolean indicating proper coloring
for v in G.vertices() do
col ← set()
for w in G.neighbors(v) do
for i in range(1, 2 · G.degree()[0]) do
if coloring[(Set((v, w)), i)] = 1 then
col.add(i)

if len(col) ̸= len(G.neighbors(v)) then

return False
return True

checkRichness takes a graph G and the output richEdges of our ILP. It iterates
over each edge in the graph, checks all edges adjacent to it, and returns false if it
doesn’t find a rich edge.

Algorithm 4: checkRichness
Input: graph G, rich edges richEdges
Output: Boolean indicating proper rich-neighbor edge coloring
for (u, v) in G.edges(labels = F alse) do
S←0
for w in G.neighbors(u) do
if w = v then
S ← S + richEdges[Set((u, w))]
for z in G.neighbors(v) do
if z = u then
S ← S + richEdges[Set((v, z))]
if S = 0 then
return False
return True

9
 6. Findings
With the help of Professor Riste Škrekovski, we were able to use external servers
to run our algorithms for an extended period of time. We ran a complete search for
all regular graphs up to 15 vertices and a random search for regular graphs with 16
vertices or more. The output of our scripts can be seen in the folders Complete and
Random in our GitHub repository at github/anejrozman. Table 2 shows the number
of checked graphs using the random search algorithm for certain classes of graphs.

Degree \Vertices 16 17 18 19 20
4 216190 344180 199300 321970 182260
5 97340 / 88420 / 81390
6 49220 87710 44210 79790 40390
7 22500 / 19430 / 18230
8 6860 13910 5990 12310 5270
9 3530 / 2970 / 2570
10 1830 760 50 2920 1280
11 70 / 220 / 90
12 <10 <10 <10 10 <10

Table 2. Number of checked graphs with random search

We can clearly see that our ILP slows down significantly with the regularity of the
graphs. This makes intuitive sense since the number of constraints that we have
to solve is O(k 4 n) where k is the regularity and n is the number of vertices in the
graph we are using our ILP on to find a rich-neighbor edge coloring.

6.1. Problems
When going through the complete search file outputs we noticed that each file
stopped at 100-th iteration and found that it had a minor bug. We ran it again on
our computer and checked all regular graphs up to 13 vertices instead of 15 because
the task was to intense for a personal computer.

6.2. Conclusion
We can confirm that every graph that was checked by our algorithm satisfies the
conjecture, so based on this it seems likely that the conjecture could hold for all
regular graphs. However, we can’t be sure of this since, if a counterexample exists
it could quite possibly be a very large graph that is very unlikely to be found by
any of our algorithms.

References
[1] Ravindran Kannan and Clyde L. Monma. On the computational complexity of integer program-
ming problems. In Rudolf Henn, Bernhard Korte, and Werner Oettli, editors, Optimization and
Operations Research, pages 161–172, Berlin, Heidelberg, 1978. Springer Berlin Heidelberg.
[2] M. Meringer. Fast generation of regular graphs and construction of cages. Journal of Graph
Theory, 30:137–146, 1999.

10