1 Introduction
Graph coloring is a fundamental and arguably one of the most extensively studied problems in theoretical computer science.
Given an undirected graph , a proper coloring of assigns the vertices
in to color in the set such that no two adjacent vertices
are assigned the same color.
The smallest value of for which a coloring is possible is called the chromatic number of .
It is wellknown for , deciding whether the given graph has a coloring is NPhard [GareyJohnson]; whereas
for , the graph is colorable iff is bipartite [CLRS].
Despite the hardness result for general graphs, it is easily seen that a graph can be vertex colored using at most colors, where is the maximum degree.
The graph coloring problem has several practical applications like scheduling, where the input changes with time. This motivates
the study of the graph coloring problem under the dynamic setting. In the dynamic setting, we are given
a graph with the proper (not necessarily optimal) coloring of the vertices in of . Vertex set is fixed and = . A fully dynamic
coloring algorithm supports the following operations:
Insert: Insert an edge between vertex and vertex .
Delete: Delete the edge .
getColor: Report the color of vertex .
An incremental coloring algorithm only supports Insert and getColor operations.
The goal of an incremental or fully dynamic algorithm for coloring is to maintain a coloring after every update,
ensuring that the update time (time needed to add or delete an edge) and/ or the query time (time needed for getColor)
is as small as possible. In addition, the following two parameters are of interest – (i)
the maximum number of colors used during the algorithm and (ii)
the maximum number of vertices that need to change their color due to an update; this is known as the number of recolorings per update (in literature the number of vertices
or edges affected per update is called as
the adjustment complexity [DBLP:AssadiOSS18]).
Recently, Bhattacharya et al. [BCHN18] present an efficient randomized coloring
algorithm with expected amortized update time. They also present
a fast deterministic coloring algorithm with amortized update time. They
do not focus on
minimizing the number of recolorings per update.
We observe that,
the randomized algorithm in [BCHN18] has recolorings in the worst case.
In a different work, Barba et al. [Barba] study
the tradeoff between the number of colors used and the number of recolorings per update.
For any , they present two algorithms, one using colors and
performing recolorings and the other using colors and performing recolorings, where is the chromatic number.
However, both these algorithms require exponential running time. Very recently, Solomon et al. [SolomonW18] present an algorithm which uses colors and perform recolorings per update, where suppresses polyloglog factors. Their algorithm improves the first tradeoff due to Barba et al.[Barba] exponentially.
In our work we are interested in placing bounds on the query and update times, the number of colors used,
and the number of recolorings. We show the following new results on bipartite and general graphs for dynamic coloring.
To the best of our knowledge, there are no known results for dynamic coloring specific to bipartite graphs.
Results on bipartite graphs:
For bipartite graphs, in the dynamic setting, we aim to maintain efficient update and query
time for coloring of bipartite graphs. The tradeoff between update time () and query time ()
has been well studied for the dynamic connectivity problem [PatrascuD06].
We show that fully dynamic coloring is at least as hard as fully dynamic connectivity in bipartite graphs.

In the cellprobe model of computation [Miltersen99cellprobe], any data structure for fully dynamic (implicit or explicit) 2coloring of bipartite graph satisfies the following tradeoffs : = and = . These bounds hold under amortization, nondeterministic queries, and randomization (Theorem 2.1.1). We strengthen this result by showing that any deterministic incremental algorithm that maintains coloring for a bipartite graph with constant query time must have at least logarithmic amortized update time and linear worst case update time.
To beat the above lowerbound and obtain time for both query and update time, we
use the idea of maintaining an Implicit coloring. In an implicit coloring we do not explicitly maintain the color of every vertex after each update.
However, the correct color of every vertex can be obtained by the query getColor using time.
On the other hand, in an explicit coloring the color of each vertex is maintained and the query getColor gets the color in time. Our next two results
are on implicit coloring of bipartite graphs.

We present a deterministic implicit coloring algorithm for bipartite graphs under incremental updates where the query and update times are both amortized where is inverse Ackermann function (Theorem 2.2). This algorithm is an adaptation of the standard unionfind data structure for disjoint sets. The lower bound and the above algorithms are presented in Section 2.
Next, we turn our attention to explicit coloring in bipartite graphs by using more than 2 colors.

We complement the implicit incremental algorithm by a deterministic explicit coloring, with at most one recoloring per update for bipartite graphs under incremental updates. The algorithm has an amortized update time and worst case query time. (Theorem 2.3).
Result on General Graphs: In Section 4 we present our result on maintaning an explicit coloring for the fully dynamic setting in general graphs.

We present a deterministic coloring algorithm with at most one recoloring per update for fully dynamic updates on general graphs. Our algorithm has a worst case update time and worst case query time, where is the maximum degree of a vertex and is the maximum number of edges in the graph at any point during the update sequence (Theorem 4).
We use the same number of colors as the randomized algorithm due to Bhattacharya et al.[BCHN18] while improving the number of recolorings from to constant per update in the worst case. Bhattacharya et al. algorithm has an expected amortized update time of and it can be in the worst case. In contrast, our deterministic algorithm has a worst case update time of . Because of deterministic nature, our algorithm (Theorem 4) works even against an adaptive adversary, whereas the randomized algorithm in [BCHN18] assumes that adversary is nonadaptive and oblivious. This is similar to the case of the fully dynamic maximal matching problem where the best randomized algorithm takes update time [DBLP:conf/focs/Solomon16] while the best known deterministic algorithm takes update time [Neiman]. Our final result, presented in Section 4.1 is for the special case of bounded arboricity graphs.

For graphs with arboricity bounded by , we present a fully dynamic deterministic (+1)coloring algorithm with at most one recoloring per update. Our algorithm has an amortized update time of and worst case query time of , where is the number of vertices in the graph (Theorem 4.1).
2 Incremental Implicit and Explicit coloring of Bipartite Graphs
In this Section we present two deterministic incremental algorithms for coloring of bipartite graphs. We present an incremental algorithm for Implicit coloring in Section 2.2 and an incremental algorithm for Explicit coloring in Section 2.3. It is known that a connected bipartite graph has unique bipartition. For a connected component in a bipartite graph, if we select any arbitrary vertex, say , in the component and fix its color, then a vertex which is in the same part of the bipartition as gets the same color as and a vertex which is not in the same part of the bipartition as gets the other color. We refer to vertex
as root of the component. We observe that after an insert or delete, we only need to update the colors for the roots of the components. When the color of a vertex is queried, we compute the parity of its distance from the root of the component to which it belongs and output the color of the root if the parity is even and the other color if the parity is odd. We call this approach as maintaining an
Implicit coloring. In an Explicit coloring once the color of a vertex in a component changes, we update the color of all the vertices in the component. Before presenting our algorithms, we show our lower bound results for explicit coloring which motivate the need to consider implicit coloring in Section 2.1.2.1 Lower bounds on Explicit 2coloring of Bipartite Graphs
Barba et al. [Barba] showed that for any , any fully dynamic algorithm that maintains a coloring of a 2colorable graph on vertices must recolor at least vertices per update. Their result immediately implies that if we use only two colors for bipartite graphs, then the worst case update time for any fully dynamic explicit coloring algorithm is . We observe that the linear lower bound for worst case update time holds even in the incremental setting. In the incremental setting we further claim that amortized update time for a deterministic explicit coloring algorithm is , even for a path. We start with an empty graph with vertices. We have two colors in our palette and we consider a vertex coloring maintained by an algorithm. We know that no matter what the coloring, at least vertices will get the same color. Since our algorithm is deterministic, an adaptive adversary can force every alternate insert to happen between two vertices of the same color such that the insertion merges two disjoint paths and creates a new path, and the lengths of any two disjoint paths are within a factor of 2 of each other. This ensures that the total update time over inserts is . For bipartite graphs, we present an explicit 2coloring deterministic incremental algorithm that takes time for inserts. The algorithm maintains a 2coloring using an idea similar to the decremental algorithm for connectivity due to Even and Shiloach [Shiloach:1981:OEP:322234.322235]. It works as follows : We maintain the color for every vertex. If an edge insertion between two vertices of same color merges two connected component then we update the color for the vertices in the smaller component. For a vertex belonging to a smaller component, the component size it is present in has at least doubled after merging. Therefore, a vertex can participate in at most merges where it is part of the smaller component. Therefore, the total update time is time.
2.1.1 2coloring is at least as hard as connectivity in Bipartite Graphs
Here we reduce the fully dynamic connectivity for bipartite graphs to fully dynamic 2coloring for bipartite graphs. As a consequence of this reduction we obtain a lower bound for fully dynamic 2coloring of bipartite graphs in the cellprobe model. The cellprobe model has been a standard for proving dynamic data structure lower bounds, as in the works of Fredman and Saks [Fredman:1989:CPC:73007.73040] and Pătraşcu and Demaine [PatrascuD06]. In this model the memory is organized into words and a data structure occupies a certain number of words. The queries are processed by an online algorithm which may update the data structure. As the query sequence is processed one query after the other, the online algorithm proceeds by reading from or writing words into the data structure. The running time of the dynamic algorithm is defined to be equal to the number of probes into the data structure. One natural tradeoff is between the size of the data structure and the running time of the dynamic algorithm (see the survey by Miltersen [Miltersen99cellprobe]). The tradeoff between the query time (time to read the data structure) and the update time (time to write into the data structure) is also of interest. Pătraşcu has proved lower bounds on the tradeoff between and , and some of these are proved based on a lower bound on the communication complexity of lopsided (asymmetric) set disjointness [DBLP:journals/corr/abs10103783]. We now present our reduction to obtain a lower bound for fully dynamic 2coloring of bipartite graphs.
Let be any fully dynamic algorithm for 2coloring of bipartite graphs. reports violation of bipartiteness if insertion of an edge creates an odd length cycle and supports the following operations: .Insert to insert an edge between and , .Delete to delete the edge between and , and .getColor to report the color of vertex .
We use algorithm to solve fully dynamic connectivity in bipartite graphs. To insert an edge we call .Insert. To delete the edge we call .Delete. A connectivity query is of the form : are and connected? To answer the connectivity query we do the following:
We query for the color of and using .getColor and .getColor.
case : and are of same color. Therefore, if and are connected then and are in the same bipartition. Call .Insert and .Insert where and are dummy vertices. Then call .Insert. If and are connected then insertion of edge creates an odd length cycle and reports violation of bipartiteness. Therefore, if reports violation of bipartiteness on insertion of , we output and are connected. Otherwise, we output and are not connected. Finally, call .Delete, .Delete, and .Delete.
case : and are of different color. Therefore, if and are connected then and are not in the same bipartition. Call .Insert where is a dummy vertex. Then call .Insert. If and are connected then insertion of edge creates an odd length cycle and reports violation of bipartiteness similar to case . Finally, call .Delete and .Delete.
Let be the update time and be the query time for algorithm . As a consequence of this reduction and the known lower bound for fully dynamic connectivity for bipartite graphs from Pătraşcu et al. [PatrascuD06] we conclude Theorem 2.1.1.
In the cellprobe model of computation, any data structure for fully dynamic (implicit or explicit) 2coloring of bipartite graph satisfies the following tradeoffs : = and = . These bounds hold under amortization, nondeterministic queries, and randomization, and even if the graph is a disjoint union of paths.
Further, .
Therefore, in case of explicit 2coloring of bipartite graphs, and consequently, by Theorem 2.1.1, = . This motivates us to study Implicit coloring for bipartite graphs, and algorithms which use more than colors for maintaining an explicit proper coloring of bipartite graphs in order to achieve sublogarithmic update time.
2.2 Incremental Implicit 2Coloring for Bipartite Graphs
In this Section, we present a deterministic nearconstant update time incremental algorithm for implicit 2coloring of bipartite graphs.
Data Structures:
We use the disjointset data structure from the UnionFind algorithm. In addition to parent and size, here, each element also has an attribute called flag. It is a boolean attribute. For a vertex , iff and are in the same bipartition in G. In other words, iff and its parent have the same color. The flag attribute can be thought of as the relative coloring between a vertex and its parent. So, the flag for a vertex changes only when its parent changes. We have two colors in our palette: and . The flag and the color of the root are always . This means that if is the root, then represents its color.
Preprocessing:
We call MAKESETIMPLICIT (see Algorithm 1) operation on all vertices in the graph. This is to initialize the vertices and their attributes. Each vertex is the root of its singleton component and its flag is set to . The size attribute of a vertex is relevant only if the vertex is a root.
1:function MAKESETIMPLICIT()
2: if not already present: then
3: add to the disjoint set tree
4:
5:
6:
1:function FIND()
2: if then
3:
4:
5: XNOR
6: RETURN
Algorithm:
We use the UnionFind algorithm with path compression and union by size. As is well known, during path compression the parent of a vertex might change. This is when its flag also needs to be updated.
FIND() procedure (see Algorithm 2) returns the root of the component containing and the updated flag of (note that flag of represents color of because parent of is root after FIND).
Inside FIND() procedure, we make a recursive call to FIND() which returns the root of the component and updated flag of . If is not in the same bipartition as the root in G (i.e ) and and are in the same bipartition in G (i.e. ), then is not in the same bipartition as the root in G. Its flag must be changed to
while updating its parent as root. The table below considers all the possible combinations and it corresponds to the XNOR gate.
Updated  

When an edge is inserted, we call UNIONIMPLICIT() (see Algorithm 3). The procedure works as follows : We call FIND() and FIND(). FIND() returns root of (denoted by ) and color of (denoted by ). Similarly, FIND() returns root and color of . We have the following cases:

is same as .

is same as . Then this edge insertion introduces an odd length cycle violating the bipartiteness property of the graph. Hence, such edge insertions are invalid.

is different from . Then no further processing is required.


is different from . Then, the insert merges two components. To complete merging, without loss of generality, we assume that belongs to the larger component. We make the parent of . If and have the same color, then the colors of all vertices in ’s component need to be flipped. But in Implicit coloring we only need to change color for and this is achieved by changing to . This implicitly recolors all vertices in ’s component as their flags represent relative coloring. can be obtained by using the XOR operation on and . Note that is the only vertex whose parent has been updated and hence the only vertex whose flag needs to be updated.
Update/Query  Action 

Insert()  Call UNIONIMPLICIT() 
getColor(x)  Call FIND(), Return 
The extra running time incurred by the above procedures compared to the standard UnionFind is . Hence, the time complexity for UnionFind holds here. The amortized running time per operation is , where is the inverse Ackermann function. is less than for any that can be expressed in the physical universe. Hence, each of the above operations run in near constant time. We get the following Theorem: Starting with an empty bipartite graph with vertices, an implicit 2coloring can be maintained deterministically over any sequence of insertion in amortized update time and amortized query time, where is inverse Ackermann function.
2.3 Incremental Explicit ()coloring for Bipartite Graphs
In this Section, we present a deterministic nearconstant update time incremental algorithm for explicit coloring of bipartite graphs using at most colors. Our algorithm performs at most recoloring per update. Our algorithm is adapted from the online algorithm for coloring bipartite graphs from [Lovsz].
Algorithm:
We have a palette of colors and the colors are numbered from to . We start with an empty graph consisting of vertices and no edges.
Initially, all vertices are assigned color . An edge insertion leads to recoloring of a vertex only if both endpoints of the edge are of the same color. Otherwise, no recoloring is required. When an edge is inserted between two vertices of the same color, we arbitrarily choose one of the vertices for recoloring.
We consider the bipartition, into two independent sets, of the connected component containing the chosen vertex. Compute the smallest color not used by any vertex in the partition not containing this vertex.
This color is used to recolor the vertex. Lemma 2.3 bounds the number of colors used by our algorithm. This lemma is similar to analogous lemma in [Lovsz], however we need a different set of arguments for our dynamic setting.
If a connected component in the graph has a vertex with color , then the component has at least vertices. Therefore, total number of colors used by our algorithm is at most .(see Appendix A for the proof)
Implementation using UnionFind:
Initially, the MAKESETEXPLICIT(see Algorithm 4 in Appendix A) procedure is called on each vertex. Each vertex has the standard and attributes and also the attribute introduced in the previous Section. In addition, each vertex also has the attributes , two binary words and of bits where the bits are indexed by the integers to from right to left, respectively. The attribute is initialized to , and as the algorithm progresses the of each vertex is a proper coloring and it is explicitly maintained. Like , and are only maintained by the root of the component. After an update step if a vertex is not the root of a set, then and maintained for the vertex are not used subsequently. For each vertex and are status words which indicate which colors are unused (a bit is set if it’s index is unused in the corresponding part) in the two parts of the connected component associated with the set for which the vertex is the root. The word is associated with the part which contains the root.
Whenever an edge is inserted, the UNIONEXPLICIT(see Algorithm 5 in Appendix A) procedure is called on the two vertices. Within the UNIONEXPLICIT operation, the FIND (see Algorithm 2) procedure is called on both vertices to find the roots of their components. If they have the same root, then they both belong to the same component. If both have same flag also, then they belong to the same partition which violates bipartiteness of the graph. Otherwise, it is a valid insertion. If both have different roots, the two components are merged by taking the union of the two corresponding sets, and making one of the two roots as the root of the resulting set. Further, and associated wtih the root of the new component is obtained by performing a bitwise AND of the appropriate words associated with the pervious two roots. In particular, the () of the root is obtained by taking the bitwise AND of its () before the union with the () of the other vertex before the union. Once maintaining the component information is done we check the colors of and . If they are different nothing needs to be done. If they are same, one of them needs to be recolored. We recolor the vertex in the same part of the bipartition as the root, which is the part , and this is found by computing the flag of the vertex. The least unused color in is the maximum index of a bit which is a 1 in associated with the root. This can be found in constant time using the CLZ(count leading zeros) hardware instruction. We use this color to recolor the vertex and then ensure that this color is set to 0 in to indicate that it is used to color a vertex in . The running time of this algorithm is same as the standard UnionFind algorithm as maintaining the additional attributes and the word operations are all operations. Hence, the amortized running time per operation is bounded by the inverse Ackermann function which is near constant. We get the following Theorem. Starting with an empty bipartite graph with vertices, an explicit coloring, performing at most one recoloring per update, can be maintained deterministically over any sequence of insertions in amortized update time and worst case query time, where is inverse Ackermann function.
3 Fully Dynamic Implicit 2coloring for Bipartite Graphs
In this Section, we present a fully dynamic deterministic algorithm for maintaining an implicit 2coloring of bipartite graphs. If we use only two colors for coloring a bipartite graph and if we insert an edge between two vertices of the same color in a connected component then this insertion creates an odd length cycle and such an insertion is forbidden.
Therefore, during an insert, it is important to know whether both the endpoints are in the same connected component.
We use the fully dynamic connectivity algorithm due to Holm et al. [HLT] to check whether two vertices belong to the same component.
The high level idea for their algorithm is to store a spanning tree for every connected component of the input graph . The input graph is hierarchically partitioned into levels, where is the total number of vertices, by assigning levels to the edges. The level of an edge is an integer in the interval .
The algorithm maintains the invariant that the level of an edge can only decrease over time and this is crucially used to achieve the amortized bounds in the algorithm. For each , is the subgraph of composed of edges of level at most . Therefore, is . Further, for each , is the spanning forest of in which each edge has a weight which is the level of the edge. Therefore, is the spanning forest for with one tree for each connected component of . Every spanning forest is maintained using the EulerTour(ET) tree data structure [HK].
The data structure due to Holm et al. supports the following operations:
Connected(u,v) : Reports if and are in the same connected component in time.
ConnInsert(u,v) : Insert an edge between and . This operation takes time.
ConnDelete(u,v) : Delete the edge . This operation takes amortized time. We use the data structure with a minor modification to the Delete in Holm et al. [HK] by ensuring that it returns a value. If is a nontree edge, then a 0 is returned. If is a tree edge that has a replacement edge as computed by Holm et al. algorithm, that edge is returned. Otherwise 1 is returned.
To maintain a 2coloring not only do we need the connectivity information, but we also need the information regarding of the parity of the path length. The problem with ETtrees is that it does not provide for an efficient way to extract the path information. We address this problem by additionally maintaining a copy of using LinkCut trees [ST].
Implicit Coloring using Holm et al. and LinkCut trees
The Link cut tree supports the following operations in amortized time.
Findroot(v) : Returns root of the tree which contains vertex .
Link(u,v) : Inserts the edge into the linkcut tree and makes a new child of .
Cut(v): Deletes the edge between and parent of where is not a root.
PathLength(v) : Returns the length of the path from the root of the tree to .
Our data structure for maintaining a 2coloring has two colors in its palette : TRUE and FALSE. It is initialized with an empty graph on vertices with TRUE as the vertex color. Then, the data structures of Holm et al. and the linkcut tree are initialized.
Every vertex stores an attribute indicating its color. The query getColor is obtained by first finding
the root, say , of the tree containing using Findroot. The length of the path from to is obtained using a query to PathLength. If the length is even, then we output the color of as the color of , otherwise we output the negation of the color of . This operation takes the same time as Findroot and PathLength and hence contributes to the amortized running time. The updates Insert and Delete are described below.
Insert(u,v): On the insert of an edge , the color of and is computed using getColor and getColor, respectively. We have the following cases:

Color of is different from color of , no recoloring is required. Call Connected.

Case when and belong to the same component. Call ConnInsert(u,v) to insert the edge into the Holm et al. data structure.

Case when and belong to different components. Call ConnInsert(u,v) to insert the edge into the Holm et al. data structure. This is followed by a call to Link to update the linkcut tree, since the edge will be added to the forest .


Color of is same as color of , this necessitates a possible recoloring. Call Connected.

Case and belong to the same component. Then, edge is ignored and no data structure is udpated.

Case and belong to different components. Call ConnInsert(u,v) to insert the edge into the Holm et al. data structure. This is followed by a call to Link to update the linkcut tree, since the edge will be added to the forest , thus reducing the number of components.

Delete(u,v): Deletion does not necessitate any color change. However, the connectivity information must be appropriately updated. Call ConnDelete(u,v). We have the following cases based on the return value of ConnDelete(u,v).

Case edge is a nontree edge. The forest does not change, and thus the linkcut tree also need not change.

Case edge is a tree edge. Wlog let be parent of in prior to the delete. If does not have a replacement edge, then the forest has one more component after the delete, then the linkcut tree is updated by a call to Cut. On the other hand, if the replacement edge is , then call Cut followed by a call to Link.
Analysis : Since the colors of all the vertices were initialized to True, throughout the execution each vertex has some color associated with it. In a bipartite connected graph the color of one vertex fixes the colors of all the components. Therefore, the getColor will return the correct color of each vertex in a component relative to the color of the root vertex of the component in the linkcut tree. Therefore, the data structure maintains an implicit 2coloring in the fully dynamic setting. Other than the operations supported by Holm et al. [HK], the linkcut tree and the getColor operation, every other operation in our algorithm takes constant time. In any update step, there are at most a constant many calls to the Holm et al. data structure, the linkcut tree, and getColor. Therefore, our algorithm supports updates in amortized time and reports the color of a vertex in amortized time. Thus, we have the following Theorem. Starting with an empty bipartite graph with vertices, an implicit 2coloring can be maintained deterministically over any sequence of insertion and deletion in amortized update time and amortized query time.
4 Fully Dynamic coloring for General Graphs
In this Section, we present a deterministic fully dynamic algorithm for coloring with constant number of recolorings
and worst case update time of . Recall that
is the maximum degree of a vertex in the graph and is the maximum number of edges in the graph at any point during the update sequence. Our algorithm
is inspired by the deterministic dynamic algorithm for maintaining a maximal matching by Neiman and Solomon [Neiman]; however we require a different set of data structures.
Overall approach:
We partition the vertex set into two sets and .
If then ; otherwise, .
Thus, and as in [Neiman], our goal is to have a bounded number of highdegree vertices.
We say that a color is used for a vertex if it is assigned to at least one of its neighbors; otherwise we
say that the color is free for the vertex. For every vertex , we maintain the set of used colors and free colors .
We aim to find a free color for a highdegree vertex efficiently. In contrast, for a lowdegree vertex we can scan
all its neigbhors to find a free color.
Data Structures:
We assume that we have colors numbered as .
We maintain the following data structures :

Color of a vertex: For every vertex , we store the color assigned to .

Degree of a vertex: For every vertex , we maintain its degree as an integer. This allows us to check if a vertex is of high degree or not in time.

Neigbhorhood of a vertex: For every vertex , we maintain the set of edges incident on as a doubly linked list . In addition, for every vertex we maintain an array() of size which augments the list . If the edge is present in , then at index in the array, we store the pointer to the edge in . Otherwise the index in the array points to NULL.

Lists of Free and Used colors: If , then we maintain two separate lists and as doubly linked lists. The list contains the set of colors used by the neighbors of , whereas the list contains the set of colors which are not used by the neighbors of . We remark that the color is contained in . We augment these doubly linked lists with arrays and of size .

If color is in then entry , that is, the th entry of the free array contains a pointer to the node in the doubly linked list which stores the color . The entry , that is, the th entry of used array contains NULL.

If color is in then entry , that is, the th entry of the used array contains a pointer to the node in the doubly linked list which stores the color . The entry , that is, the th entry of free array contains NULL.
It is easy to verify that using the above data structures we perform the following operations in constant time: (i) check whether a given color is free or used for a vertex , (ii) change the status of a given color for a vertex from used to free and vice versa.


Count of neighbours of each color: For every high degree vertex , we maintain an array of size . The th index of denotes the number of neighbors of which are colored using the color .

List of high degree vertices: We maintain the list of high degree vertices as a doubly linked list . Clearly .
Initialization:
We call INIT (see Algorithm 6 in Appendix B) to initialize the data structures required for each vertex. Even the data structures used only by highdegree vertices are initialized here although they will not be maintained until the vertex becomes highdegree.
Edge Insertion:
We call INSERT(u,v) (see Algorithm 7 in Appendix B) when an edge between vertices and is inserted. If vertex has the same color as vertex the we call Procedure RECOLOR() (see Algorithm 9 in Appendix B). Procedure RECOLOR() works as follows: If vertex is of high degree then a color is selected from the list . Otherwise, we search neighbors of and find a free color . We assign color to vertex and inform all its high degree neighbors about the change in color of . Time taken by RECOLOR() is . It is straightforward that INSERT runs in time.
Edge Deletion:
We call DELETE(u,v) (see Algorithm 8 in Appendix B) when an edge between vertices and is deleted.
It is straightforward that DELETE(u,v) runs in time.
Therefore, updates in our algorithm take time and queries can be answered in constant time in the worst case.
Starting with an empty graph with vertices, a coloring, performing at most one recoloring, can be maintained deterministically over any sequence of insertion and deletion in worst case update time and worst case query time.
4.1 Low Arboricity Graphs
In this Section we present a fully dynamic algorithm for maintaining a coloring in graphs with bounded arboricity. Arboricity of a graph is defined as:
where = . A dynamic graph is said to have arboricity iff the arboricity of the graph remains bounded by after any update. A orientation of an undirected graph is a directed graph where contains the edges in with a direction assigned to it such that the outdegree of every vertex in is at most . It is known due to NashWilliams [NashWilliams] that a graph has arboricity iff can be partitioned as such that is a forest for all . This implies that a graph with arboricity has a orientation. Brodal and Fagerberg [DBLP:conf/wads/BrodalF99] studied the problem of maintaining orientation for a graph with arboricity in the fully dynamic setting. We use the following result from their paper [DBLP:conf/wads/BrodalF99] for our fully dynamic coloring algorithm. [DBLP:conf/wads/BrodalF99] There exists a fully dynamic algorithm that maintains an orientation with an amortized update time of in a dynamic graph with vertices and arboricity . Overall approach: Every vertex maintains a list of neighbors N(v) and a list of outgoing neighbors OUT(v) (it contains if there is an edge directed from to ). Along with this, every vertex maintains a partially correct list Free(v) of free colors. The list is partially correct because if a color is present in the list Free(v) then is not used by any of its neighbors in N(v) OUT(v) but may be used by some neighbors in OUT(v). Therefore, the free color information is correct with respect to the neighbors in N(v) OUT(v) (whose size is unbounded) but may be incorrect with respect to the neighbors in OUT(v) (whose size is at most ). During our algorithm, a vertex is responsible for notifying its color to all the neighbors in OUT(v). Therefore, whenever we need to recolor a vertex , we call procedure RECOLORLowArboricity (see Algorithm 13 in Appendix C) which works as follows: For every vertex , if is present in Free(v) then we remove from Free(v). We pick a color from Free(v) and assign it to . For every vertex , if color is present in Free(w) then it is removed from Free(w). RECOLORLowArboricity takes time in the worst case. We defer the details to Appendix C and conclude with the following theorem. Starting with an empty graph with vertices with arboricity bounded by , a coloring, performing at most one recoloring, can be maintained deterministically over any sequence of insertion and deletion in amortized update time and worst case query time.
References
Appendix A Omitted details from Section 2.3
In this Section we present the proof of Lemma 2.3 and pseudo codes omitted from Section 2.3.
Proof of Lemma 2.3:
The claim is trivially true for a vertex of color . We proceed by induction on the color . Let and be the two independent sets in the bipartition of the connected component containing , and contains .
Let the color of be . Since we are in an incremental setting, components can only merge with updates. Given that the graph is bipartite, if a vertex is in
it continues to remain so after all subsequent updates. When was colored , must have had at least one vertex of each color from to and no vertex of color . Let and be vertices in colored and , respectively. Similarly, when was colored , must have had a vertex of color . We have the following cases:
case : Color of is at the time of assigning color to . This means that both and have a vertex of color . This could not have happened if both and belonged to the same component the last time either of them were recolored. This implies that two components, each of them with a vertex of color , merged to form the current component.
case : Color of is not at the time of assigning color to . The only way the color of could have changed is if there was an edge inserted which is incident on and another vertex of color , say . This insertion could have led to the merging of two components, both with a vertex of color . If not, both these vertices are in the same connected component before the insertion of and they were already both colored . Since the graph is bipartite, and belong to different partitions of the connected component containing them prior to the insertion of . Like the argument in Case , we observe that the last time either of or was recolored, they must have been in two different connected components. Subsequent to the recoloring after which both and had the color , the two components merged to form the current component.
From the induction hypothesis we get that in both cases the current component has at least vertices. Hence, by the principle of mathematical induction, our claim is true for all natural numbers . Therefore, total number of colors used by our algorithm is at most .
Appendix B Omitted details from Section 4
In this Section we present the pseudo codes omitted from Section 4.
Appendix C Omitted details from Section 4.1
In this Section we present the details of data structures and procedures to handle updates along with pseudo codes omitted from Section 4.1.
Data Structures: We maintain the following for every vertex :

We store the color assigned to .

List of neighbors N(v) as doubly linked list augmented with an array of size .

List of outgoing neighbors OUT(v) as doubly linked list augmented with an array of size .

Partially correct list of free colors Free(v) augmented with an array of size .

An array of size . The th index of denotes the number of neighbors of in which are colored using the color .
Insert, Delete, and Search operations in the above data structures takes time. Our algorithm works as follows:

Orientation: We call procedure UpdateOrientation (see Algorithm 10) after every update. We use algorithm to maintain orientation. Then we update our data structures OUT and Free. If there are total edge reorientations this step takes time. Therefore, during entire run of the algorithm, this procedure takes amortized time.

EdgeInsertion: We call procedure INSERTLowArboricity(u,v) (see Algorithm 11) when an edge between two vertices and is inserted. We call procedure UpdateOrientation(u,v). If vertex has same color as vertex and the edge is directed from to then we call procedure RECOLORLowArboricity(v). Otherwise, if vertex has same color as vertex and the edge is directed from to then we call procedure RECOLORLowArboricity(u). Other than call to UpdateOrientation(u,v), remaining steps in INSERTLowArboricity(u,v) takes time in the worst case.

EdgeDeletion: We call procedure DELETELowArboricity(u,v) (see Algorithm 12) when an edge between two vertices and is deleted. We call UpdateOrientation(u,v). Other than call to UpdateOrientation(u,v), remaining steps in DELETELowArboricity(u,v) takes time in the worst case.
Comments
There are no comments yet.