### Bipartite Graphs

A graph \(G(V, E)\) is called *bipartite* if its vertices can be divided into two groups \(X\) and \(Y\) such that every edge connects one vertex from \(X\) and one vertex from \(Y\). The graph drawn below is bipartite.

Given a graph, can you determine if it is bipartite?

This problem is pretty straightforward because the vertices of a bipartite graph can be colored with two colors such that every edge connects two vertices of different colors (see above). This property is called 2-colorability. The converse is also true, that is if a graph is 2-colorable, it is also bipartite. Hence, it order to check for bipartiteness, we can run a Breadth First Search on the graph and color the vertices as we discover them. It would take \(O(V+E)\) time and storage.

### An Online Variant

First of all, what is an online algorithm? An online algorithm is an algorithm that processes the input in a piece by piece in a sequential manner and have access to limited storage. These algorithms are useful in many realistic scenarios.

Now consider an online variant of the previous problem: suppose your algorithm gets a single pass over the edges of a graph and has access to only \(O(V)\) storage. In other words, the edges are fed into the algorithm one at a time, but the algorithm cannot store all of them. Can you determine if this graph is bipartite?

This is a practical problem because a graph with \(|V|\) vertices can have as many as \(|V|^2\) edges. For instance, if a graph has \(10^{10}\) vertices, there can be \(O(10^{20})\) edges. Storing them in the memory might be impossible. The problem above attempts to bypass this issue by getting the edges sequentially, and never storing all of them. I’ll show that it is indeed possible to design such an algorithm with only \(O(E\log V)\) runtime.

We’ll use the 2-colorability property once more. In the beginning, the graph is 2-colorable since all the vertices are disjoint. Let’s color all the vertices to be red. Every time a new edge is added to the graph, it connects two vertices of either different or same colors. In the former case, the graph remains bipartite. In the later case, one of the following two scenarios may occur:

- The edge connects two vertices from the same connecting component. Now, if the edge connects two vertices of same color, the graph is no longer 2-colorable. We can output FAIL and stop.
- The edge connects two vertices from different connected components. In this case, if the edge connects two edges of the same color, the graph is still 2-colorable. However, we need to flip colors of all the vertices in one of the connected components (see below).

A naive way to do #2 would be to flip color of every vertex in one of the connected components. This may take \(O(V)\) time for each edge, the total runtime being \(O(EV)\). We need a smarter way.

One potential approach is to do the flipping in a lazy manner: if #2 happens, only *remember* that colors in a connected components need to be flipped, instead of actually flipping them. When the algorithm checks the color of a vertex,

- go through your records to find the connected components the vertex was previously in.
- Observe how many of those connected components had their colors flipped.
- Since all vertices started as red, the number of flips determine current color of that vertex.

This reminds us of a data structure called Union-Find.

### A Quick Intro to Union-Find

This data structure is is essentially a list of mutually disjoint sets. It has three methods:

**make-set:**makes a set with a unique id**find(x):**given element \(x\), finds the id of the set \(x\) belongs to.**union(x, y):**performs the set-union on the sets \(x\) and \(y\) belong to.

Union-Find is usually implemented as a forest of trees, with root of every tree being its id. Every node contains a pointer to its parent. Roots contain pointers to themselves. find(x) looks for the root of a tree. union(x, y) first does find(x) and find(y), then attaches the root of y as a child to the root of x.

In a naive implementation, the cost of the find and union functions are \(O(n)\). However, those can be reduced to \(O(\log n)\) via a technique called union by rank. In this technique, a shorter tree is always attached to a taller tree. You can easily show (by induction) that such a tree with height \(n\) must contain atleast \(2^n\) nodes. In other words, the time complexity for this data structure is \(O(\log n)\).

### Faster Algorithm Using Union Find

In our problem, every connected component can be thought of as a disjoint set. Every node starts in its own set. When two connected components are merged, we perform set-union over their corresponding sets. Now, notice that, the root of every tree can remember if the connected component needs to flip color during the union. When we call find on an element, we’ll pass through all its ancestors, which were roots in some previous connected components. We can check each of them to see if those components had their colors flipped. Since each find costs \(O(\log V)\) time, computing the color of each node requires \(O(\log V)\) time, too. Now, each of the steps #1 and #2 in the previous algorithm takes \(O(\log V)\) time. Hence, the total runtime for our modified algorithm is \(O(E\log V)\).

### Appendix

In Union Find, there is another technique, called *Path Compression*, which (along with Union by Rank) reduces the data structure’s amortized complexity to \(O(\alpha(n))\). The previous algorithm works with path compression, but needs to be modified. This is left as an exercise to the reader.