The.Algorithm.Design.Manual.Springer-Verlag.1998
The.Algorithm.Design.Manual.Springer-Verlag.1998 The.Algorithm.Design.Manual.Springer-Verlag.1998
Drawing Graphs Nicely Next: Drawing Trees Up: Graph Problems: Polynomial-Time Previous: Network Flow Drawing Graphs Nicely Input description: A graph G. Problem description: Draw a graph G so as to accurately reflect its structure. Discussion: Drawing graphs nicely is a problem that constantly arises in applications, such as displaying file directory trees or circuit schematic diagrams. Yet it is inherently ill-defined. What exactly does nicely mean? We seek an algorithm that shows off the structure of the graph so the viewer can best understand it. We also seek a drawing that looks aesthetically pleasing. Unfortunately, these are ``soft'' criteria for which it is impossible to design an optimization algorithm. Indeed, it is possible to come up with two or more radically different drawings of certain graphs and have each be most appropriate in certain contexts. For example, page contains three different drawings of the Petersen graph. Which of these is the ``right'' one? Several ``hard'' criteria can partially measure the quality of a drawing: ● Crossings - We seek a drawing with as few pairs of crossing edges as possible, since they are distracting. ● Area - We seek a drawing that uses as little paper as possible, while ensuring that no pair of file:///E|/BOOK/BOOK4/NODE168.HTM (1 of 4) [19/1/2003 1:31:12]
Drawing Graphs Nicely vertices are placed too close to each other. ● Edge length - We seek a drawing that avoids long edges, since they tend to obscure other features of the drawing. ● Aspect ratio - We seek a drawing whose aspect ratio (width/height) reflects that of the desired output medium (typically a computer screen at 4/3) as close as possible. Unfortunately, these goals are mutually contradictory, and the problem of finding the best drawing under any nonempty subset of them will likely be NP-complete. Two final warnings before getting down to business. For graphs without inherent symmetries or structure to display, it is likely that no really nice drawing exists, especially for graphs with more than 10 to 15 vertices. Even when a large, dense graph has a natural drawing, the shear amount of ink needed to draw it can easily overwhelm any display. A drawing of the complete graph on 100 vertices, , contains approximately 5,000 edges, which on a pixel display works out to 200 pixels an edge. What can you hope to see except a black blob in the center of the screen? Once all this is understood, it must be admitted that certain graph drawing algorithms can be quite effective and fun to play with. To choose the right one, first ask yourself the following questions: ● Must the edges be straight, or can I have curves and/or bends? - Straight-line drawing algorithms are simpler than those with polygonal lines, but to visualize complicated graphs such as circuit designs, orthogonal polyline drawings seem to work best. Orthogonal means that all lines must be drawn either horizontal or vertical, with no intermediate slopes. Polyline means that each graph edge is represented by a chain of straight-line segments, connected by vertices or bends. ● Can you build a natural, application-specific drawing algorithm? - If your graph represents a network of cities and roads, you are unlikely to find a better drawing than placing the vertices in the same position as the cities on a map. This same principle holds for many different applications. ● Is your graph either planar or a tree? - If so, use one of the special planar graph or tree drawing algorithms of Sections and . ● How fast must your algorithm be? - If it is being used for interactive update and display, your graph drawing algorithm had better be very fast. You are presumably limited to using incremental algorithms, which change the positions of the vertices only in the immediate neighborhood of the edited vertex. If you need to print a pretty picture for extended study, you can afford to be a little more extravagant. As a first, quick-and-dirty drawing for most applications, I recommend simply spacing the vertices evenly on a circle, and then drawing the edges as straight lines between vertices. Such drawings are easy to program and fast to construct, and have the substantial advantage that no two edges can obscure each other, since no three vertices will be nearly collinear. As soon as you allow internal vertices into your drawing, such artifacts can be hard to avoid. An unexpected pleasure with circular drawings is the symmetry that is sometimes revealed because consecutive vertices appear in the order they were inserted into the graph. Simulated annealing can be used to permute the circular vertex order so as to minimize file:///E|/BOOK/BOOK4/NODE168.HTM (2 of 4) [19/1/2003 1:31:12]
- Page 451 and 452: Generating Graphs Combinatorica [Sk
- Page 453 and 454: Calendrical Calculations Next: Job
- Page 455 and 456: Calendrical Calculations Gregorian,
- Page 457 and 458: Job Scheduling ● To assign a set
- Page 459 and 460: Job Scheduling shop scheduling incl
- Page 461 and 462: Satisfiability logic, and automatic
- Page 463 and 464: Satisfiability Next: Graph Problems
- Page 465 and 466: Graph Problems: Polynomial-Time rec
- Page 467 and 468: Connected Components Testing the co
- Page 469 and 470: Connected Components discussing gra
- Page 471 and 472: Topological Sorting contradiction t
- Page 473 and 474: Minimum Spanning Tree Next: Shortes
- Page 475 and 476: Minimum Spanning Tree help you sort
- Page 477 and 478: Shortest Path Next: Transitive Clos
- Page 479 and 480: Shortest Path easier to program tha
- Page 481 and 482: Shortest Path Related Problems: Net
- Page 483 and 484: Transitive Closure and Reduction
- Page 485 and 486: Transitive Closure and Reduction Al
- Page 487 and 488: Matching augmenting paths and stopp
- Page 489 and 490: Matching Combinatorica [Ski90] prov
- Page 491 and 492: Eulerian Cycle / Chinese Postman ar
- Page 493 and 494: Eulerian Cycle / Chinese Postman Ne
- Page 495 and 496: Edge and Vertex Connectivity Severa
- Page 497 and 498: Edge and Vertex Connectivity Next:
- Page 499 and 500: Network Flow programming model for
- Page 501: Network Flow Combinatorica [Ski90]
- Page 505 and 506: Drawing Graphs Nicely labs.com/orgs
- Page 507 and 508: Drawing Trees such as the map of th
- Page 509 and 510: Planarity Detection and Embedding N
- Page 511 and 512: Planarity Detection and Embedding p
- Page 513 and 514: Graph Problems: Hard Problems ● C
- Page 515 and 516: Clique approximate even to within a
- Page 517 and 518: Independent Set Next: Vertex Cover
- Page 519 and 520: Independent Set Related Problems: C
- Page 521 and 522: Vertex Cover Vertex cover and indep
- Page 523 and 524: Traveling Salesman Problem Next: Ha
- Page 525 and 526: Traveling Salesman Problem practice
- Page 527 and 528: Traveling Salesman Problem Size is
- Page 529 and 530: Hamiltonian Cycle Eulerian cycle, p
- Page 531 and 532: Graph Partition Next: Vertex Colori
- Page 533 and 534: Graph Partition annealing, is almos
- Page 535 and 536: Vertex Coloring Several special cas
- Page 537 and 538: Vertex Coloring Notes: An excellent
- Page 539 and 540: Edge Coloring The minimum number of
- Page 541 and 542: Graph Isomorphism Next: Steiner Tre
- Page 543 and 544: Graph Isomorphism vertices into equ
- Page 545 and 546: Steiner Tree Next: Feedback Edge/Ve
- Page 547 and 548: Steiner Tree The worst case for a m
- Page 549 and 550: Feedback Edge/Vertex Set Next: Comp
- Page 551 and 552: Feedback Edge/Vertex Set An interes
Drawing Graphs Nicely<br />
Next: Drawing Trees Up: Graph Problems: Polynomial-Time Previous: Network Flow<br />
Drawing Graphs Nicely<br />
Input description: A graph G.<br />
Problem description: Draw a graph G so as to accurately reflect its structure.<br />
Discussion: Drawing graphs nicely is a problem that constantly arises in applications, such as displaying<br />
file directory trees or circuit schematic diagrams. Yet it is inherently ill-defined. What exactly does<br />
nicely mean? We seek an algorithm that shows off the structure of the graph so the viewer can best<br />
understand it. We also seek a drawing that looks aesthetically pleasing. Unfortunately, these are ``soft''<br />
criteria for which it is impossible to design an optimization algorithm. Indeed, it is possible to come up<br />
with two or more radically different drawings of certain graphs and have each be most appropriate in<br />
certain contexts. For example, page contains three different drawings of the Petersen graph. Which of<br />
these is the ``right'' one?<br />
Several ``hard'' criteria can partially measure the quality of a drawing:<br />
● Crossings - We seek a drawing with as few pairs of crossing edges as possible, since they are<br />
distracting.<br />
● Area - We seek a drawing that uses as little paper as possible, while ensuring that no pair of<br />
file:///E|/BOOK/BOOK4/NODE168.HTM (1 of 4) [19/1/2003 1:31:12]
Change language