Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
D
ds2-notes
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Deploy
Releases
Model registry
Analyze
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
GitLab community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
datovky
ds2-notes
Commits
4edf7a62
Commit
4edf7a62
authored
4 years ago
by
Ondřej Mička
Browse files
Options
Downloads
Patches
Plain Diff
Grpahs: Init; static path
parent
66411d7c
No related branches found
No related tags found
No related merge requests found
Changes
2
Show whitespace changes
Inline
Side-by-side
Showing
2 changed files
om-graphs/Makefile
+3
-0
3 additions, 0 deletions
om-graphs/Makefile
om-graphs/graphs.tex
+76
-0
76 additions, 0 deletions
om-graphs/graphs.tex
with
79 additions
and
0 deletions
om-graphs/Makefile
0 → 100644
+
3
−
0
View file @
4edf7a62
TOP
=
..
include
../Makerules
This diff is collapsed.
Click to expand it.
om-graphs/graphs.tex
0 → 100644
+
76
−
0
View file @
4edf7a62
\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
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment