Dynamic coloring for Bipartite and General Graphs

09/17/2019 ∙ by Manas Jyoti Kashyop, et al. ∙ Indian Institute Of Technology, Madras 0

We consider the dynamic coloring problem on bipartite and general graphs in the incremental as well as fully-dynamic settings. In this work, we are interested in the following parameters : the update time and query time, the number of colors used, and the number of vertex recolorings per update. Our results reveal the following trade-off for a bipartite graph with n vertices: In the fully dynamic setting, if we restrict the number of colors to 2 then the maximum of update and query time is at least log n. In the incremental setting, using 2 colors we achieve the maximum of update and query time to be O(α(n)), where α(n) is the inverse Ackermann function. We show that by allowing more than two colors we can reduce the query time to O(1) without changing the update time. Our incremental algorithm uses 1+2 logn colors. To the best of our knowledge, there are no known theoretical guarantees for dynamic coloring specific to bipartite graphs. For general graphs we provide a deterministic fully-dynamic algorithm with constant number of recolorings per update. We use Δ+1 colors and achieve O(√(m)) worst case update time with at most one recoloring per update. Here Δ is the maximum degree of a vertex and m denotes the maximum number of edges throughout the update sequence. For graphs of arboricity bounded by γ we maintain a Δ+1 coloring with at most one recoloring per update, an amortized update time of O(γ + logn), and an O(1) query time.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

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 well-known for , deciding whether the given graph has a -coloring is NP-hard [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 .
get-Color: Report the color of vertex .
An incremental coloring algorithm only supports Insert and get-Color 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 get-Color) 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 trade-off 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 trade-off 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 trade-off 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 cell-probe model of computation [Miltersen99cellprobe], any data structure for fully dynamic (implicit or explicit) 2-coloring of bipartite graph satisfies the following trade-offs : = and = . These bounds hold under amortization, non-deterministic 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 lower-bound 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 get-Color using time.
On the other hand, in an explicit coloring the color of each vertex is maintained and the query get-Color 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 union-find data structure for disjoint sets. The lower bound and the above algorithms are presented in Section 2.

  • For the fully dynamic setting, we present, in Section 3, a deterministic implicit -coloring algorithm for bipartite graphs. Our algorithm has an amortized update time and amortized query time (Theorem 3). In the light of Theorem 2.1.1, our result is close to tight.

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 non-adaptive 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 2-coloring of Bipartite Graphs

Barba et al. [Barba] showed that for any , any fully dynamic algorithm that maintains a -coloring of a 2-colorable 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 2-coloring deterministic incremental algorithm that takes time for inserts. The algorithm maintains a 2-coloring 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 2-coloring is at least as hard as connectivity in Bipartite Graphs

Here we reduce the fully dynamic connectivity for bipartite graphs to fully dynamic 2-coloring for bipartite graphs. As a consequence of this reduction we obtain a lower bound for fully dynamic 2-coloring of bipartite graphs in the cell-probe model. The cell-probe 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 trade-off is between the size of the data structure and the running time of the dynamic algorithm (see the survey by Miltersen [Miltersen99cellprobe]). The trade-off 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 trade-off 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/abs-1010-3783]. We now present our reduction to obtain a lower bound for fully dynamic 2-coloring of bipartite graphs.

Let be any fully dynamic algorithm for 2-coloring 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 .get-Color 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 .get-Color and .get-Color.
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 cell-probe model of computation, any data structure for fully dynamic (implicit or explicit) 2-coloring of bipartite graph satisfies the following trade-offs : = and = . These bounds hold under amortization, non-deterministic queries, and randomization, and even if the graph is a disjoint union of paths. Further, . Therefore, in case of explicit 2-coloring 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 sub-logarithmic update time.

2.2 Incremental Implicit 2-Coloring for Bipartite Graphs

In this Section, we present a deterministic near-constant update time incremental algorithm for implicit 2-coloring of bipartite graphs.
Data Structures: We use the disjoint-set data structure from the Union-Find 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 MAKESET-IMPLICIT (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.
Algorithm 1 1:function MAKESET-IMPLICIT() 2:     if  not already present: then 3:         add to the disjoint set tree 4:          5:          6:                   Algorithm 2 1:function FIND() 2:     if  then 3:          4:          5:          XNOR       6:     RETURN Algorithm: We use the Union-Find 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
1:function UNION-IMPLICIT()
2:     
3:     
4:     if  then Both and belong to the same connected component
5:         if  then
6:              ERROR, INVALID EDGE INSERTION
7:         else
8:              RETURN No further processing needed          
9:     else and belong to different connected components
10:         if  then
11:              swap(, ) corresponds to the root of the larger component
12:              swap(, )          
13:         
14:         
15:          XOR      
Algorithm 3

When an edge is inserted, we call UNION-IMPLICIT() (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:

  1. is same as .

    1. 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.

    2. is different from . Then no further processing is required.

  2. 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 UNION-IMPLICIT()
get-Color(x) Call FIND(), Return

The extra running time incurred by the above procedures compared to the standard Union-Find is . Hence, the time complexity for Union-Find 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 2-coloring 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 near-constant 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 Union-Find: Initially, the MAKESET-EXPLICIT(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 UNION-EXPLICIT(see Algorithm 5 in Appendix A) procedure is called on the two vertices. Within the UNION-EXPLICIT 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 Union-Find 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 2-coloring for Bipartite Graphs

In this Section, we present a fully dynamic deterministic algorithm for maintaining an implicit 2-coloring 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 Euler-Tour(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.
Conn-Insert(u,v) : Insert an edge between and . This operation takes time.
Conn-Delete(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 non-tree 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 2-coloring 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 ET-trees 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 Link-Cut trees [ST].
Implicit Coloring using Holm et al. and Link-Cut trees
The Link cut tree supports the following operations in amortized time.
Find-root(v) : Returns root of the tree which contains vertex .
Link(u,v) : Inserts the edge into the link-cut tree and makes a new child of .
Cut(v): Deletes the edge between and parent of where is not a root.
Path-Length(v) : Returns the length of the path from the root of the tree to .
Our data structure for maintaining a 2-coloring 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 link-cut tree are initialized. Every vertex stores an attribute indicating its color. The query get-Color is obtained by first finding the root, say , of the tree containing using Find-root. The length of the path from to is obtained using a query to Path-Length. 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 Find-root and Path-Length 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 get-Color and get-Color, respectively. We have the following cases:

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

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

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

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

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

    2. Case and belong to different components. Call Conn-Insert(u,v) to insert the edge into the Holm et al. data structure. This is followed by a call to Link to update the link-cut 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 Conn-Delete(u,v). We have the following cases based on the return value of Conn-Delete(u,v).

  1. Case edge is a non-tree edge. The forest does not change, and thus the link-cut tree also need not change.

  2. 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 link-cut 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 get-Color will return the correct color of each vertex in a component relative to the color of the root vertex of the component in the link-cut tree. Therefore, the data structure maintains an implicit 2-coloring in the fully dynamic setting. Other than the operations supported by Holm et al. [HK], the link-cut tree and the get-Color 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 link-cut tree, and get-Color. 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 2-coloring 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 high-degree 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 high-degree vertex efficiently. In contrast, for a low-degree 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 :

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

  2. 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.

  3. 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.

  4. 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.

  5. 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 .

  6. 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 high-degree vertices are initialized here although they will not be maintained until the vertex becomes high-degree.
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 out-degree of every vertex in is at most . It is known due to Nash-Williams [Nash-Williams] 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 RECOLOR-LowArboricity (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). RECOLOR-LowArboricity 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 .

1:function MAKESET-EXPLICIT()
2:     if  not already present: then
3:         add to the disjoint set tree
4:         
5:         
6:         
7:         
8:          ( bits)
9:          ( bits)      
Algorithm 4
1:function UNION-EXPLICIT()
2:     
3:     
4:     if  then Both and belong to the same connected component
5:         if  then
6:              ERROR, INVALID EDGE INSERTION
7:         else
8:              RETURN No further processing needed          
9:     else and belong to different connected components
10:         if  then
11:              swap(, )
12:              swap(, )          
13:         
14:         
15:          XOR
16:         if  then
17:               AND
18:               AND
19:         else
20:               AND
21:               AND               
22:     if  then
23:         if  then
24:               = CLZ
25:              
26:         else
27:               = CLZ
28:                             
Algorithm 5

Appendix B Omitted details from Section 4

In this Section we present the pseudo codes omitted from Section 4.

1:function Init
2:     for  do
3:          ; ;
4:         
5:         for  do
6:              Add to               
7:     
Algorithm 6
1:function Insert()
2:     Add to and to
3:     Increment and
4:     if  then
5:         RECOLOR()      
6:     if 
7:         Add to
8:         for  do
9:               =
10:              if  then
11:                  Move from to                             
12:     if 
13:          =
14:         if  then
15:              Move from to               
16:     Repeat steps 6-15 with respect to vertex
Algorithm 7
1:function Delete()
2:     Remove from and from
3:     Decrement and
4:     if  then
5:         for  do
6:              Move from to               
7:     if  then
8:          =
9:         if  then
10:              Move from to               
11:     Repeat steps 4-10 with respect to vertex
Algorithm 8
1:function RECOLOR()
2:     if  then
3:         Select a color from
4:     else
5:         Scan and find a free color      
6:     
7:     
8:     for  do Informing high degree neighbors of the change in color of
9:         if  then
10:               =
11:              if  then
12:                  Move from to               
13:               =
14:              if  then
15:                  Move from to                             
Algorithm 9

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 out-going 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 Update-Orientation (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 re-orientations this step takes time. Therefore, during entire run of the algorithm, this procedure takes amortized time.

  • Edge-Insertion: We call procedure INSERT-LowArboricity(u,v) (see Algorithm 11) when an edge between two vertices and is inserted. We call procedure Update-Orientation(u,v). If vertex has same color as vertex and the edge is directed from to then we call procedure RECOLOR-LowArboricity(v). Otherwise, if vertex has same color as vertex and the edge is directed from to then we call procedure RECOLOR-LowArboricity(u). Other than call to Update-Orientation(u,v), remaining steps in INSERT-LowArboricity(u,v) takes time in the worst case.

  • Edge-Deletion: We call procedure DELETE-LowArboricity(u,v) (see Algorithm 12) when an edge between two vertices and is deleted. We call Update-Orientation(u,v). Other than call to Update-Orientation(u,v), remaining steps in DELETE-LowArboricity(u,v) takes time in the worst case.

1:function Update-Orientation()
2:     Run Algorithm
3:     if  was inserted and directed from to  then if directed from v to u then perform step 4 to 7 with u and v swapped
4:         Insert to
5:         if  is present in  then
6:              Remove from          
7:               
8:     if  was deleted and directed from to  then if directed from v to u then perform step 9 to 12 with u and v swapped
9:         Remove from
10:         
11:         if  then
12:              Insert to               
13:     for every edge that was re-oriented to by algorithm  do
14:         Remove from OUT(x) and Insert to OUT(y)
15:         
16:         
17:         if  then
18:              Insert to          
19:         if  then
20:              Remove from               
Algorithm 10
1:function Insert-LowArboricity(u,v)
2:     Insert to and to
3:     Run Algorithm Update-Orientation(u,v)
4:     if  then
5:         if direction is from to  then
6:              RECOLOR-LowArboricity(v)
7:         else
8:              RECOLOR-LowArboricity(u)               
Algorithm 11
1:function DELETE-LowArboricity(u,v)
2:     Delete to and to
3:     Run Algorithm Update-Orientation(u,v)
Algorithm 12
1:function RECOLOR-LowArboricity(v)
2:     for  do
3:         if  then
4:              Remove from               
5:     Select a color from Free(v)
6:     
7:     
8:     for  do
9:         
10:         if  then
11:              Insert to Free(w)          
12:         
13:         if  then
14:              Remove from Free(w)               
Algorithm 13