From 4edf7a621c9a0558729c21095bfd5ce4cfb221c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ondra=20Mi=C4=8Dka=20=40=20miles-teg?=
 <mitch.ondra@gmail.com>
Date: Fri, 14 May 2021 15:40:30 +0200
Subject: [PATCH] Grpahs: Init; static path

---
 om-graphs/Makefile   |  3 ++
 om-graphs/graphs.tex | 76 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 79 insertions(+)
 create mode 100644 om-graphs/Makefile
 create mode 100644 om-graphs/graphs.tex

diff --git a/om-graphs/Makefile b/om-graphs/Makefile
new file mode 100644
index 0000000..ba6c63e
--- /dev/null
+++ b/om-graphs/Makefile
@@ -0,0 +1,3 @@
+TOP=..
+
+include ../Makerules
diff --git a/om-graphs/graphs.tex b/om-graphs/graphs.tex
new file mode 100644
index 0000000..5ccc92e
--- /dev/null
+++ b/om-graphs/graphs.tex
@@ -0,0 +1,76 @@
+\ifx\chapter\undefined
+\input adsmac.tex
+\singlechapter{42}
+\fi
+
+\def\TODO{{\bf TODO}}
+
+\chapter[graphs]{Representation of graphs}
+In this chapter we will peek into the area of data structures for representation of
+graphs. Our ultimate goal is to design a data structure that represents a forest with
+weighted vertices and allows efficient path queries (e.g. what is the lightest edge on the
+path between $u$ and $v$) along with weight and structural updates. 
+
+Let us define the problem more formally. We wish to represent a forest $F = (V,
+E)$, where each vertex~$v$ has weight~$w(v)\in\R$.\foot{We could also had weighted edges
+instead.} We would like to support following operations:
+\tightlist{o}
+\:\em{path query}   --- find the vertex with minimum weight on a path $u\to
+v$;\foot{Generally, we can use any associative operation, instead of minimum.}
+\:\em{point update} --- set $w(v) \leftarrow c\in\R$;
+\:\em{path update}  --- increase weight of each vertex on path $u\to v$ by $\delta\in\R$;
+\:\em{structural update} --- connect/disconnect two trees via edge $(u,v)$.
+\endlist
+
+\section[path]{Static path}
+As a warm-up we build a data structure for $F$ being a path and without structural
+updates. This will also be an important building block for the more general case.
+
+Let us denote the vertices $v_1, \dots, v_n$ according to the position on the path and let
+us denote $w_i = w(v_i)$. \TODO\foot{maybe change initial notation} We build an interval
+tree~$T$ over the weights $w_1, \dots, w_n$. That is, $T$ is a complete binary tree with
+$w_1,\dots w_n$ in its leaves (in this order) and inner nodes contain the minimum of their
+children. Note that each node represents a subpath of~$F$ with leaves being the single
+vertices. 
+
+\TODO picture of path and the interval tree
+\figure[]{interval-tree.pdf}{}{\TODO}
+% temporary sketch, not in repository
+
+\theorem{Static path representation via interval tree can perform \em{path query},
+\em{point update}
+and \em{path update} in $\O(\log n)$ time.
+}
+
+\proof
+Any $v_i \to v_j$ subpath of~$F$ forms
+an interval of leaves of~$T$ and each such interval can be exactly covered by $\O(\log n)$
+subtrees and they can be easily found by traversing~$T$ top to bottom. The answer to the
+path query can then be easily calculated from the values in the roots of these subtrees. 
+
+The point update of $w_i$ is simply a matter of recalculating values in the nodes on path
+from root of~$T$ to the leaf~$w_i$, so it takes $\O(\log n)$ time.
+
+The path updates are more tricky. As in the path query, we can decompose the update to
+$\O(\log n)$ subtrees. But we cannot afford to recalculate the values in these subtrees
+directly as they can contain $\Theta(n)$ nodes. But we can be lazy and let others do the
+work for us. 
+
+Instead of recalculating the whole subtree, we put a \em{mark} into the root along with
+the value of~$\delta$. The mark indicates ``everything below should be increased by
+$\delta$''. Whenever an operation touches node during a top-down traversal, it
+checks for the mark. If the node is marked, we update value in the node according to the
+mark and move the mark down to both children. If the children are already marked, we
+simply add the new mark to the existing one. \TODO maybe introduces notation for marks, if
+we use them more later on 
+
+This way, other operations can work as if there were no marks and path updates can be
+performed in~$\O(\log n)$ time. Note that this lazy approach requires other operations to
+always traverse the tree top-down in order to see correct values in the nodes. 
+
+\TODO picture of lazy updates
+\figure[]{lazy-update.pdf}{}{\TODO}
+% temporary sketch, not in repository
+\qed
+
+\endchapter
-- 
GitLab