1 2 Week 5 3 4 5
General remarks We finish, by analysing it. Then we consider the second main graph- algorithm, depth-first (). And we consider one application of, of graphs. Reading from CLRS for week 5 Chapter 22, Sections 22.2, 22.3, 22.4.
Recall: (G,s) 1 for each u V(G) 2 d[u] = 3 π[s] = nil 4 d[s] = 0 5 Q = (s) 6 while Q () 7 u = Dequeue[Q] 8 for each v Adj[u] 9 if d[v] = 10 d[v] = d[u]+1 11 π[v] = u 12 Enqueue(Q, v)
Analysis of Correctness Analysis: At termination of (G, s), for every vertex v reachable from s: Time Analysis: v has been encountered; d[v] holds the length of the shortest path from s to v; π[v] represents an edge on a shortest path from v to s. The initialisation takes time Θ(V). Each vertex is Enqueued once and Dequeued once; these queueing operations each take constant time, so the queue manipulation takes time Θ(V) (altogether). The Adjacency list of each vertex is scanned only when the vertex is Dequeued, so scanning adjacency lists takes time Θ(E) (altogether). The overall time of is thus Θ(V +E).
Why do we get shortest paths? Is it really true that we get always shortest paths (that is, using the minimum number of edges)? Let s assume that to some vertex v there exists a shorter path P in G from s to v than found by. Let this length be d < d[v]. 1 v s, since the distance from s to s is zero (using the path without an edge), and this is correctly computed by. 2 Consider the predecessor u on that shorter path P. 3 If also d[u] would be wrong (that is, too big), than we could use u instead of v. Thus w.l.o.g. d[u] is correct. 4 Now when exploring the neighbours of u, in case v is still unexplored, it would get the correct distance d = d[u]+1. 5 So v must have been explored already earlier (than u). 6 So at the time of determining the distance d[u] d[v] 2, the distance d[v] must have been already set. 7 However the distances d[w] set by are non-decreasing!
The role of the queue A crucial property of is that the distances set in step 10 of the algorithm are non-decreasing, that is, if we imagine a watch-point set at step 10, and monitor the stream of values d[v], then we will see 0,1,...,1,2,...,2,3,...,3,... Why is this the case? This must be due to the queue used whose special properties we haven t yet exploited! Since in step 12, directly after setting the distance, we put the vertex into the queue, the above assertion is equivalent to the statement, that the distances of the vertices put into the queue are non-decreasing (in the order they enter the queue). Now why is this the case?
The role of the queue (cont.) First we need to notice that once a distance d[v] is set, it is never changed again. The vertices are taken off the queue ( dequeued ) from the left, and are added ( enqueued ) to the right ( first in, first out ). What is added has a distance one more than what was taken away. We start with 0, and add some 1 s. Then we take those 1 s, and add 2 s. Once the 1 s are finished, we take the 2 s, and add 3 s. And so on that why the sequence of distances is non-decreasing.
Running on directed graphs We can run also on a digraph G, with start-vertex s: 1 For digraphs we have directed spanning trees/forests. 2 Only the vertices reachable from s following the directions of the edges are in that directed tree (directed from s towards the leaves). 3 Still the paths in the directed tree, from s to any other vertex, are shortest possible (given that we obey the given directions of the edges). For a graph (i.e., undirected graph), we need to restart (to obtain a spanning forest, not just a spanning tree) only if the graph is disconnected. However for a digraph there is a much higher chance, that we need to restart in order to cover all vertices. We thus more often need a directed spanning forest, not just a directed spanning tree.
Restart typically needed for digraphs to cover all vertices Consider the simple digraph 1 2 3 In order to cover all vertices, one needs to run at least two times (and if the first time you start it with s = 1, then you need to run it three times). So even for the above apparently very simple graph we need a directed spanning forest. Note that the obtained directed trees (given by π) overlap. So in such a directed forest there is typically a certain overlap between the directed trees in it.
Arcs of different lengths The edges of (di-)graphs have (implicitly) a length of one unit. If arbitrary non-negative lengths are allowed, then we have to generalise to Dijkstra s algorithm. This generalisation must keep the essential properties, that the distances encountered are the final ones and are non-decreasing. But now not all edges have unit-length, and thus instead of a simple queue we need to employ a priority queue. A priority queue returns the vertex in it with the smallest value (distance).
() is another simple but very important technique for ing a graph. Such a constructs a spanning forest for the graph, called the depth-first forest, composed of several depth-first trees, which are rooted spanning trees of the connected components. recursively visits the next unvisited vertex, thus extending the current path as far as possible; when the gets stuck in a corner it backtracks up along the path until a new avenue presents itself. computes the parent π[u] of each vertex u in the depth-first tree (with the parent of initial vertices being nil), as well as its discovery time d[u] (when the vertex is first encountered, initialised to ) and its finishing time f[u] (when the has finished visiting its adjacent vertices).
The algorithm (G) 1 for each u V(G) 2 d[u] = 3 time = 0 4 for each u V(G) 5 if d[u] = 6 π[u] = nil 7 -Visit(u) -Visit(u) 1 time = time +1 2 d[u] = time 3 for each v Adj[u] 4 if d[v] = 5 π[v] = u 6 -Visit(v) 7 time = time +1 8 f[u] = time Analysis: -Visit(u) is invoked exactly once for each vertex, during which we scan its adjacency list once. Hence, like, runs in time Θ(V +E).
illustrated 1 /nil / / / 1 /nil 2 /1 / / 1 2 4 6 d[u] 1 2 4 6 f[u] /π[u] u 3 5 7 / / / 3 5 7 (labelling) / / / Stack = () u = 1 Stack = (1) u = 2 1 /nil 2 /1 / / 1 /nil 2 /1 4 /3 / 1 2 4 6 1 2 4 6 3 5 7 3 5 7 3 /2 / / 3 /2 / / Stack = (2,1) u = 3 Stack = (3,2,1) u = 4 1 /nil 2 /1 4 /3 / 1 /nil 2 /1 4 /3 / 1 2 4 6 1 2 4 6 3 5 7 3 /2 5 /4 / 3 5 7 3 /2 5 /4 6 /5 Stack = (4,3,2,1) u = 5 Stack=(5,4,3,2,1) u = 7 1 /nil 2 /1 4 /3 9 /4 1 2 4 6 1 14 /nil 2 /1 4 13 11 /3 9 /4 10 1 2 4 6 3 5 7 3 /2 5/4 6/5 8 7 Stack = (4,3,2,1) u = 6 3 5 7 3 12 /2 5/4 6/5 8 7 Stack = ()
Running on directed graphs Again (as with ), we can run on a digraph G. Again, no longer do we obtain spanning trees of the connected components of the start vertex. But we obtain a directed spanning tree with exactly all vertices reachable from the root (when following the directions of the edges). Different from, the root (or start vertex) normally does not play a prominent role for : 1 Thus we did not provide the form of with a start vertex as input. 2 But we provided the forest-version, which tries all vertices (in the given order) as start vertices. 3 This will always cover all vertices, via a directed spanning forest.
What are the times good for? (Directed) trees do not contain shortest paths to that end their way of exploring a graph is too adventuresomely (while is very cautious ). Nevertheless, the information gained through the computation of discovery and finish times is very valuable for many tasks. We consider the example of scheduling later. In order to understand this example, we have first to gain a better understanding of the meaning of discovery and finishing time.
Existence of a path versus finishing times Lemma 1 Consider a digraph G and nodes u,v V(G) with d[u] < d[v]. Then there is a path from u to v in G if and only if f[u] > f[v] holds. In words: If node u is discovered earlier than node v, then we can reach v from u iff v finishes earlier than u. Proof. If there is a path from u to v, then, since v was discovered later than u, the recursive call of -Visit(v) must happen inside the recursive call of -Visit(u) (by construction of the discovery-loop), and thus v must finish before u finishes. In the other direction, if v finishes earlier than u, then the recursive call of -Visit(v) must happen inside the recursive call of -Visit(u) (since the recursion for u must still be running). Thus, when discovering v, we must be on a path from u to v.
Existence of a path versus finishing times Lemma 1 Consider a digraph G and nodes u,v V(G) with d[u] < d[v]. Then there is a path from u to v in G if and only if f[u] > f[v] holds. In words: If node u is discovered earlier than node v, then we can reach v from u iff v finishes earlier than u. Proof. If there is a path from u to v, then, since v was discovered later than u, the recursive call of -Visit(v) must happen inside the recursive call of -Visit(u) (by construction of the discovery-loop), and thus v must finish before u finishes. In the other direction, if v finishes earlier than u, then the recursive call of -Visit(v) must happen inside the recursive call of -Visit(u) (since the recursion for u must still be running). Thus, when discovering v, we must be on a path from u to v.
Directed acyclic graphs An important applications of digraphs G is with scheduling: The vertices are the jobs (actions) to be scheduled. A directed edge from vertex u to vertex v means a dependency, that is, action u must be performed before action v. Now consider the situation where we have three jobs a,b,c and the following dependency digraph: G = a b Clearly this can not be scheduled! 8 8888888 c In general we require G to by acyclic, that is, G must not contain a directed cycle. A directed acyclic graph is also called a dag.
Topological Given a dag G modelling a scheduling task, a basic task is to find a linear ordering of the vertices ( actions ) such that all dependencies are respected. This is modelled by the notion of. A sort of a dag is an ordering of its vertices such that for every edge (u,v), u appears before v in the ordering. For example consider G = a 8888888 b 8 c The two possible s of G are a,c,b and c,a,b.
Finishing times in DAGs Lemma 2 After calling on a dag, for every edge (u,v) we have f[u] > f[v]. Proof. There are two cases regarding the discovery times of u and v: 1 If d[u] < d[v], then by Lemma 1 we have f[u] > f[v] (since there is a path from u to v (of length 1)). 2 Now assume d[u] > d[v]. If f[u] > f[v], then we are done, and so assume that f[u] < f[v]. But then by Lemma 1 there is a path from v to u in G, and this together with the edge from u to v establishes a cycle in G, contradicting that G is a dag.
Finishing times in DAGs Lemma 2 After calling on a dag, for every edge (u,v) we have f[u] > f[v]. Proof. There are two cases regarding the discovery times of u and v: 1 If d[u] < d[v], then by Lemma 1 we have f[u] > f[v] (since there is a path from u to v (of length 1)). 2 Now assume d[u] > d[v]. If f[u] > f[v], then we are done, and so assume that f[u] < f[v]. But then by Lemma 1 there is a path from v to u in G, and this together with the edge from u to v establishes a cycle in G, contradicting that G is a dag.
Topological via Corollary 3 To ly sort a dag G, we run on G and print the vertices in reverse order of finishing times. (We can put each vertex on the front of a list as they are finished.)
Topological illustrated Consider the result of running the algorithm on the following dag. 1/20 21/26 22/25 27/28 3/4 m n o p q r s 2/5 6/19 t u v w 7/8 10/17 x y z 11/12 9/18 14/15 (labelling: d[u]/f[u]) 23/2413/16 Listing the vertices in reverse order of finishing time gives the following of the vertices: u : p n o s m r y v w z x u q t f[u]: 28 26 25 24 20 19 18 17 16 15 12 8 5 4
Deciding acyclicity For a graph G (i.e., undirected) detecting the existence of a cycle is simple, via or : G has a cycle (i.e., is not a forest) if and only if resp. will discover a vertex twice. One has to be a bit more careful here, since the parent vertex will always be discovered twice, and thus has to be excluded, but that s it. However for digraphs it is not that simple do you see why?
Revisiting the lemma for In Lemma 2 we said: If G has no, then along every edge the finishing times strictly decrease. So if we discover in digraph G an edge (u,v) with f[u] < f[v], then we know there is a cycle in G. Is this criterion also sufficient? YES: just consider a cycle, and what must happen with the finishing times on it. Lemma 4 Consider a digraph G. Then G has a cycle if and only if every run of on G yields some edge (u,v) E(G) with f[u] < f[v].
Revisiting the lemma for In Lemma 2 we said: If G has no, then along every edge the finishing times strictly decrease. So if we discover in digraph G an edge (u,v) with f[u] < f[v], then we know there is a cycle in G. Is this criterion also sufficient? YES: just consider a cycle, and what must happen with the finishing times on it. Lemma 4 Consider a digraph G. Then G has a cycle if and only if every run of on G yields some edge (u,v) E(G) with f[u] < f[v].
Revisiting the lemma for In Lemma 2 we said: If G has no, then along every edge the finishing times strictly decrease. So if we discover in digraph G an edge (u,v) with f[u] < f[v], then we know there is a cycle in G. Is this criterion also sufficient? YES: just consider a cycle, and what must happen with the finishing times on it. Lemma 4 Consider a digraph G. Then G has a cycle if and only if every run of on G yields some edge (u,v) E(G) with f[u] < f[v].
Revisiting the lemma for In Lemma 2 we said: If G has no, then along every edge the finishing times strictly decrease. So if we discover in digraph G an edge (u,v) with f[u] < f[v], then we know there is a cycle in G. Is this criterion also sufficient? YES: just consider a cycle, and what must happen with the finishing times on it. Lemma 4 Consider a digraph G. Then G has a cycle if and only if every run of on G yields some edge (u,v) E(G) with f[u] < f[v].