Skip to content
Snippets Groups Projects
Commit df863910 authored by Ondřej Mička's avatar Ondřej Mička
Browse files

Graphs: Analysis of Expose

parent 4e67c1f0
Branches
No related tags found
No related merge requests found
......@@ -294,7 +294,7 @@ tree is defined as the sum of the ranks of all its nodes.
The key claim about the complexity of the $\Splay$ operation is the access lemma:
\theoremn{Access lemma}{
Let~$t$ be the root of splay tree. Then $\Splay(v)$ costs $\O(r(t) - r(v))$ rotations.
Let~$t$ be the root of splay tree. Then $\Splay(v)$ costs at most $3(r(t) - r(v)) + 1$ rotations.
}
By setting all weights to one, the size of the node is exactly the size of the
......@@ -341,7 +341,9 @@ Apart from left and right son,
we allow each node~$v$ in a splay tree to have multiple \em{middle sons}. Middle sons
represent the thin edges leading into a vertex~$v$. More precisely, if there is a thin edge
leading from a fat path~$A$ into the vertex~$v$, then the root of the splay tree representing~$A$
is a middle son of~$v$. \TODO picture of a middle sons (left part: "true" structure of
is a middle son of~$v$. To distinguish between middles sons and left and right son, we
will call left and right son \em{proper sons}.
\TODO picture of a middle sons (left part: "true" structure of
fat paths, right part: representation with splay trees).
However, a node does not know about its middle sons. We do not store a pointer from a
......@@ -377,8 +379,76 @@ of~$p$. Then we move to the next step, where vertex~$p$ takes the role of vertex
In the end, when~$v$ and~$\Root(v)$, are within the same splay tree, we splay~$v$.
\subsection{Analysis of \Expose}
For the sake of analysis we split $\Expose(v)$ into three phases. Let $(r_1, p_1),\dots,
(r_k, p_k)$ be the thin edges on the path from~$v$ to the root of the virtual tree, see
Figure~\TODO. Let us
also denote $p_0 = v$. In the first phase, we splay all of $p_0, \dots, p_k$ into the roots
of their respective splay trees. After first phase, $p_k$ is the root of the virtual tree
and $p_0, \dots, p_k$ form a path made of thin edges. In the second phase, we turn edges
$(p_0, p_1), (p_1, p_2), \dots, (p_{k-1}, p_k)$ into proper splay tree edges and left sons
of $p_1, \dots, p_k$ into middle sons, just as described in the previous section. Now that
$p_0, \dots, p_k$ form a path inside one splay tree, we splay $p_0 = v$ into the root of
that tree -- this is the third phase.
\TODO picture of phases
The key phase we need to deal with in our analysis the first phase. Third phase is a
simple splay in a splay tree, which should have have $\O(\log n)$ amortized complexity,
unless we break potential in previous phases, of course. Real cost of the second phase can
be bounded by
the real cost of the third phase, so the third phase can also pay for the second phase.
However, we somehow have to make sure that swapping thin edges and splay edges does not
break the potential stored in the respective trees.
The first phase, on the other hand, performs a series of splay operation and each of them
possible costs up to $\Omega(\log n)$ amortized, if we use the basic bound on the
complexity of splay. So, how are we going to achieve the complexity we promised?
The trick is to set weights of nodes in splay trees in a way that the whole virtual tree
basically acts as one large splay tree. Recall that in the analysis of the splay tree, we
assign an arbitrary non-negative weight to each node of the tree. In our analysis, we set
the weight of a node to be
$$ w(v) = 1 + \sum_{u\in M(v)} s(u),$$
where $M(v)$ is the set of middle sons of~$v$. That is, size of~$v$, $s(v)$, is the number
of nodes in the subtree below~$v$ \em{including all nodes reachable through middle sons}.
We define a potential~$\Phi$ of the virtual tree~$T$ to be the sum of the potential of each
splay tree. This also means that $\Phi = \sum_{v\in T} r(v)$, where $r(v) = \log(s(v))$ is
the rank of~$v$.
Let us star with the third phase. We have only a single splay in a splay tree, so
according to Access lemma we get amortized complexity $\O(r(p_k) - r(v) + 1)$, where the ranks
are just before the third phase. Since size of any node is bound by the total number of
vertices, we get amortized complexity of third phase to be $\O(\log n)$.
\obs{Turning a proper son into a middle son and vice versa does not change the potential.}
This observation ensures that second phase does not change the potential. Thus, third
phase can completely pay for the second phase.
Finally, the dreaded first phase. We perform $k$ splays in $k$ different splay trees.
According to the Access lemma, the total amortized cost is at most
$$\sum_{i=1}^{k+1} 3(r(r_i) - r(p_{i-1})) + 1,$$
where $r_{k+1}$ is the root of the virtual tree before the first phase. Observe that this
sum telescopes! Since $r_i$ is a middle son of $p_i$, we have $s(r_i) < s(p_i)$ and by
monotonicity the same holds for the ranks. Using this we get that the amortized complexity
is $\O(r(r_{k+1}) - r(v) + k) = \O(\log n + k)$. This is still not the desired logarithmic
complexity as $k$ can be possibly quite large, perhaps $\Theta(n)$. But do not despair,
the third phase can save us. Notice that $\O(k)$ can be upper-bounded by the real cost of
the third phase. Thus, third phase will also pay for the $+k$ part of the first phase.
There is one last subtle problem we have to deal with. The problem is that structural
updates can change the potential of the virtual tree outside of the $\Expose$.
The simple case is $\Cut$. Since we remove a subtree from the virtual tree, we only
decrease the potential in the original virtual tree and the potential of the new tree is
paid by the potential of the removed subtree.
$\Link(u,v)$ is slightly more complicated, since adding a subtree means increasing
size of some nodes. However, notice that after $\Expose(u)$ the node~$u$ has no right
son as it is the last vertex on the fat path and also the root of the virtual tree. Thus,
by linking $u$ and $v$ we only increase the size of $u$ and we increase it by at most $n$,
so only need to pay $\O(\log n)$ into the potential.
\TODO
\section{Application: Faster Dinic's algorithm}
\TODO
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment