The.Algorithm.Design.Manual.Springer-Verlag.1998
The.Algorithm.Design.Manual.Springer-Verlag.1998 The.Algorithm.Design.Manual.Springer-Verlag.1998
War Story: Getting the Graph ``We are going to need a data structure consisting of an array with one element for every vertex in the original data set. This element is going to be a list of all the triangles that pass through that vertex. When we read in a new triangle, we will look up the three relevant lists in the array and compare each of these against the new triangle. Actually, only two of the three lists are needed, since any adjacent triangle will share two points in common. For anything sharing two vertices, we will add an adjacency to our graph. Finally, we will add our new triangle to each of the three affected lists, so they will be updated for the next triangle read.'' She thought about this for a while and smiled. ``Got it, Chief. I'll let you know what happens.'' The next day she reported that the graph could be built in seconds, even for much larger models. From here, she went on to build a successful program for extracting triangle strips, as reported in Section . The take-home lesson here is that even elementary problems like initializing data structures can prove to be bottlenecks in algorithm development. Indeed, most programs working with large amounts of data have to run in linear or almost linear time. With such tight performance demands, there is no room to be sloppy. Once you focus on the need for linear-time performance, an appropriate algorithm or heuristic can usually be found to do the job. Next: Traversing a Graph Up: Graph Algorithms Previous: Data Structures for Graphs Algorithms Mon Jun 2 23:33:50 EDT 1997 file:///E|/BOOK/BOOK2/NODE62.HTM (3 of 3) [19/1/2003 1:29:05]
Traversing a Graph Next: Breadth-First Search Up: Graph Algorithms Previous: War Story: Getting the Traversing a Graph Perhaps the most fundamental graph problem is to traverse every edge and vertex in a graph in a systematic way. Indeed, most of the basic algorithms you will need for bookkeeping operations on graphs will be applications of graph traversal. These include: ● Printing or validating the contents of each edge and/or vertex. ● Copying a graph, or converting between alternate representations. ● Counting the number of edges and/or vertices. ● Identifying the connected components of the graph. ● Finding paths between two vertices, or cycles if they exist. Since any maze can be represented by a graph, where each junction is a vertex and each hallway an edge, any traversal algorithm must be powerful enough to get us out of an arbitrary maze. For efficiency, we must make sure we don't get lost in the maze and visit the same place repeatedly. By being careful, we can arrange to visit each edge exactly twice. For correctness, we must do the traversal in a systematic way to ensure that we don't miss anything. To guarantee that we get out of the maze, we must make sure our search takes us through every edge and vertex in the graph. The key idea behind graph traversal is to mark each vertex when we first visit it and keep track of what we have not yet completely explored. Although bread crumbs or unraveled threads are used to mark visited places in fairy-tale mazes, we will rely on Boolean flags or enumerated types. Each vertex will always be in one of the following three states: ● undiscovered - the vertex in its initial, virgin state. ● discovered - the vertex after we have encountered it, but before we have checked out all its incident edges. ● completely-explored - the vertex after we have visited all its incident edges. Obviously, a vertex cannot be completely-explored before we discover it, so over the course of the traversal the state of each vertex progresses from undiscovered to discovered to completely-explored. We must also maintain a structure containing all the vertices that we have discovered but not yet file:///E|/BOOK/BOOK2/NODE63.HTM (1 of 2) [19/1/2003 1:29:05]
- Page 175 and 176: Exercises used to select the pivot.
- Page 177 and 178: Dynamic Programming Next: Fibonacci
- Page 179 and 180: Fibonacci numbers Next: The Partiti
- Page 181 and 182: Fibonacci numbers Next: The Partiti
- Page 183 and 184: The Partition Problem . What is the
- Page 185 and 186: The Partition Problem Figure: Dynam
- Page 187 and 188: Approximate String Matching Next: L
- Page 189 and 190: Approximate String Matching The val
- Page 191 and 192: Longest Increasing Sequence Will th
- Page 193 and 194: Minimum Weight Triangulation Next:
- Page 195 and 196: Limitations of Dynamic Programming
- Page 197 and 198: War Story: Evolution of the Lobster
- Page 199 and 200: War Story: Evolution of the Lobster
- Page 201 and 202: War Story: What's Past is Prolog Ne
- Page 203 and 204: War Story: What's Past is Prolog th
- Page 205 and 206: War Story: Text Compression for Bar
- Page 207 and 208: War Story: Text Compression for Bar
- Page 209 and 210: Divide and Conquer Next: Fast Expon
- Page 211 and 212: Fast Exponentiation Next: Binary Se
- Page 213 and 214: Binary Search Next: Square and Othe
- Page 215 and 216: Exercises Next: Implementation Chal
- Page 217 and 218: Exercises whose denominations are ,
- Page 219 and 220: The Friendship Graph Next: Data Str
- Page 221 and 222: The Friendship Graph friendship gra
- Page 223 and 224: Data Structures for Graphs linked t
- Page 225: War Story: Getting the Graph ``Well
- Page 229 and 230: Breadth-First Search Next: Depth-Fi
- Page 231 and 232: Depth-First Search Next: Applicatio
- Page 233 and 234: Depth-First Search Next: Applicatio
- Page 235 and 236: Connected Components Next: Tree and
- Page 237 and 238: Two-Coloring Graphs Next: Topologic
- Page 239 and 240: Topological Sorting Next: Articulat
- Page 241 and 242: Modeling Graph Problems Next: Minim
- Page 243 and 244: Modeling Graph Problems good line s
- Page 245 and 246: Minimum Spanning Trees ● Prim's A
- Page 247 and 248: Prim's Algorithm inserted edge (x,y
- Page 249 and 250: Kruskal's Algorithm a tree of weigh
- Page 251 and 252: Dijkstra's Algorithm Next: All-Pair
- Page 253 and 254: All-Pairs Shortest Path Next: War S
- Page 255 and 256: War Story: Nothing but Nets Next: W
- Page 257 and 258: War Story: Nothing but Nets ``You a
- Page 259 and 260: War Story: Dialing for Documents Ne
- Page 261 and 262: War Story: Dialing for Documents If
- Page 263 and 264: War Story: Dialing for Documents CO
- Page 265 and 266: Exercises Next: Implementation Chal
- Page 267 and 268: Exercises Prove the statement or gi
- Page 269 and 270: Backtracking report it. kth element
- Page 271 and 272: Constructing All Subsets Next: Cons
- Page 273 and 274: Constructing All Paths in a Graph N
- Page 275 and 276: Search Pruning Next: Bandwidth Mini
War Story: Getting the Graph<br />
``We are going to need a data structure consisting of an array with one element for every vertex in the<br />
original data set. This element is going to be a list of all the triangles that pass through that vertex. When<br />
we read in a new triangle, we will look up the three relevant lists in the array and compare each of these<br />
against the new triangle. Actually, only two of the three lists are needed, since any adjacent triangle will<br />
share two points in common. For anything sharing two vertices, we will add an adjacency to our graph.<br />
Finally, we will add our new triangle to each of the three affected lists, so they will be updated for the<br />
next triangle read.''<br />
She thought about this for a while and smiled. ``Got it, Chief. I'll let you know what happens.''<br />
<strong>The</strong> next day she reported that the graph could be built in seconds, even for much larger models. From<br />
here, she went on to build a successful program for extracting triangle strips, as reported in Section .<br />
<strong>The</strong> take-home lesson here is that even elementary problems like initializing data structures can prove to<br />
be bottlenecks in algorithm development. Indeed, most programs working with large amounts of data<br />
have to run in linear or almost linear time. With such tight performance demands, there is no room to be<br />
sloppy. Once you focus on the need for linear-time performance, an appropriate algorithm or heuristic<br />
can usually be found to do the job.<br />
Next: Traversing a Graph Up: Graph <strong>Algorithm</strong>s Previous: Data Structures for Graphs<br />
<strong>Algorithm</strong>s<br />
Mon Jun 2 23:33:50 EDT 1997<br />
file:///E|/BOOK/BOOK2/NODE62.HTM (3 of 3) [19/1/2003 1:29:05]