The.Algorithm.Design.Manual.Springer-Verlag.1998
The.Algorithm.Design.Manual.Springer-Verlag.1998 The.Algorithm.Design.Manual.Springer-Verlag.1998
Correctness example.'' That is 100% true, at least until we rotate our example 90 degrees. Now all points are equally leftmost. If the point `0' were moved just slightly to the left, it would be picked as the starting point. Now the robot arm will hopscotch up-down-up-down instead of left-right-left-right, but the travel time will be just as bad as before. No matter what you do to pick the first point, the nearest neighbor rule is doomed not to work correctly on certain point sets. Maybe what we need is a different approach. Always walking to the closest point is too restrictive, since it seems to trap us into making moves we didn't want. A different idea would be to repeatedly connect the closest pair of points whose connection will not cause a cycle or a three-way branch to be formed. Eventually, we will end up with a single chain containing all the points in it. At any moment during the execution of this closest-pair heuristic, we will have a set of partial paths to merge, where each vertex begins as its own partial path. Connecting the final two endpoints gives us a cycle. In pseudocode: ClosestPairTSP(P) paths and d = dist(,t) Let n be the number of points in set P. For i=1 to n-1 do For each pair of endpoints (,t) of distinct partial Connect by an edge Connect the two endpoints by an edge if then , , This closest-pair rule does the right thing on the example in Figure . It starts by connecting `0' to its immediate neighbors, the points 1 and -1. Subsequently, the next closest pair will alternate left-right, growing the central path by one link at a time. The closest-pair heuristic is somewhat more complicated and less efficient than the previous one, but at least it gives the right answer. On this example. file:///E|/BOOK/BOOK/NODE8.HTM (3 of 5) [19/1/2003 1:28:06]
Correctness Figure: A bad example for the closest-pair heuristic. But not all examples. Consider what the algorithm does on the point set in Figure (a). It consists of two rows of equally spaced points, with the rows slightly closer together (distance 1-e) than the neighboring points are spaced within each row (distance 1+e). Thus the closest pairs of points stretch across the gap, not around the boundary. After we pair off these points, the closest remaining pairs will connect these pairs alternately around the boundary. The total path length of the closest-pair tour is . Compared to the tour shown in Figure (b), we travel over 20% farther than necessary when . Examples exist where the penalty is considerably worse than this. Thus this second algorithm is also wrong. Which one of these algorithms performs better? You can't tell just by looking at them. Clearly, both heuristics can end up with very bad tours on very innocent-looking input. At this point, you might wonder what a correct algorithm for the problem looks like. Well, we could try all enumerating all possible orderings of the set of points, and then select the ordering that minimizes the total length: OptimalTSP(P) For each of the n! permutations of points P Return If then and Since all possible orderings are considered, we are guaranteed to end up with the shortest possible tour. This algorithm is correct, since we pick the best of all the possibilities. The problem is that it is also extremely slow. The fastest computer in the world couldn't hope to enumerate all 20! = 2,432,902,008,176,640,000 orderings of 20 points within a day. For real circuit boards, where , forget about it. All of the world's computers working full time wouldn't come close to finishing your problem before the end of the universe, at which point it presumably becomes moot. The quest for an efficient algorithm to solve this so-called traveling salesman problem will take us through much of this book. If you need to know how the story ends, check out the catalog entry for the traveling salesman problem in Section . Hopefully, this example has opened your eyes to some of the subtleties of algorithm correctness. Ensuring the optimal answer file:///E|/BOOK/BOOK/NODE8.HTM (4 of 5) [19/1/2003 1:28:06]
- Page 55 and 56: References AS89 Ata83 Ata84 problem
- Page 57 and 58: References BJL 91 A. Blum, T. Jiang
- Page 59 and 60: References BS81 BS86 BS93 BS96 BS97
- Page 61 and 62: References J. M. Chambers. Partial
- Page 63 and 64: References CT80 CT92 1971. G. Carpa
- Page 65 and 66: References K. Daniels and V. Milenk
- Page 67 and 68: References (FOCS), pages 60-69, 199
- Page 69 and 70: References FM71 M. Fischer and A. M
- Page 71 and 72: References History of Computing, 7:
- Page 73 and 74: References N. Gibbs, W. Poole, and
- Page 75 and 76: References Hof82 Hof89 Hol75 C. M.
- Page 77 and 78: References IK75 Ita78 O. Ibarra and
- Page 79 and 80: References Kir83 D. Kirkpatrick. Ef
- Page 81 and 82: References object in 2-dimensional
- Page 83 and 84: References LT79 LT80 8:99-118, 1995
- Page 85 and 86: References Mil97 V. Milenkovic. Dou
- Page 87 and 88: References Theoretical Computer Sci
- Page 89 and 90: References Pav82 T. Pavlidis. Algor
- Page 91 and 92: References Rei72 Rei91 Rei94 E. Rei
- Page 93 and 94: References Prentice Hall, Englewood
- Page 95 and 96: References SR95 SS71 SS90 SSS74 ST8
- Page 97 and 98: References Tin90 Mikkel Thorup. On
- Page 99 and 100: References Wel84 T. Welch. A techni
- Page 101 and 102: References Algorithms Mon Jun 2 23:
- Page 103 and 104: Correctness and Efficiency Next: Co
- Page 105: Correctness NearestNeighborTSP(P) P
- Page 109 and 110: Efficiency Next: Expressing Algorit
- Page 111 and 112: Keeping Score Next: The RAM Model o
- Page 113 and 114: The RAM Model of Computation substa
- Page 115 and 116: Best, Worst, and Average-Case Compl
- Page 117 and 118: The Big Oh Notation Figure: Illustr
- Page 119 and 120: Logarithms Next: Modeling the Probl
- Page 121 and 122: Logarithms justified in ignoring th
- Page 123 and 124: Modeling the Problem Figure: Modeli
- Page 125 and 126: About the War Stories Next: War Sto
- Page 127 and 128: War Story: Psychic Modeling Next: E
- Page 129 and 130: War Story: Psychic Modeling have pu
- Page 131 and 132: War Story: Psychic Modeling Next: E
- Page 133 and 134: Exercises (b) If I prove that an al
- Page 135 and 136: Fundamental Data Types Next: Contai
- Page 137 and 138: Containers Next: Dictionaries Up: F
- Page 139 and 140: Dictionaries Next: Binary Search Tr
- Page 141 and 142: Binary Search Trees BinaryTreeQuery
- Page 143 and 144: Priority Queues Next: Specialized D
- Page 145 and 146: Specialized Data Structures Next: S
- Page 147 and 148: Sorting Next: Applications of Sorti
- Page 149 and 150: Applications of Sorting Figure: Con
- Page 151 and 152: Data Structures Next: Incremental I
- Page 153 and 154: Incremental Insertion Next: Divide
- Page 155 and 156: Randomization Next: Bucketing Techn
Correctness<br />
Figure: A bad example for the closest-pair heuristic.<br />
But not all examples. Consider what the algorithm does on the point set in Figure (a). It consists of two rows of equally<br />
spaced points, with the rows slightly closer together (distance 1-e) than the neighboring points are spaced within each row<br />
(distance 1+e). Thus the closest pairs of points stretch across the gap, not around the boundary. After we pair off these points,<br />
the closest remaining pairs will connect these pairs alternately around the boundary. <strong>The</strong> total path length of the closest-pair<br />
tour is . Compared to the tour shown in Figure (b), we travel over 20% farther<br />
than necessary when . Examples exist where the penalty is considerably worse than this.<br />
Thus this second algorithm is also wrong. Which one of these algorithms performs better? You can't tell just by looking at<br />
them. Clearly, both heuristics can end up with very bad tours on very innocent-looking input.<br />
At this point, you might wonder what a correct algorithm for the problem looks like. Well, we could try all enumerating all<br />
possible orderings of the set of points, and then select the ordering that minimizes the total length:<br />
OptimalTSP(P)<br />
For each of the n! permutations of points P<br />
Return<br />
If then and<br />
Since all possible orderings are considered, we are guaranteed to end up with the shortest possible tour. This algorithm is<br />
correct, since we pick the best of all the possibilities. <strong>The</strong> problem is that it is also extremely slow. <strong>The</strong> fastest computer in the<br />
world couldn't hope to enumerate all 20! = 2,432,902,008,176,640,000 orderings of 20 points within a day. For real circuit<br />
boards, where , forget about it. All of the world's computers working full time wouldn't come close to finishing your<br />
problem before the end of the universe, at which point it presumably becomes moot.<br />
<strong>The</strong> quest for an efficient algorithm to solve this so-called traveling salesman problem will take us through much of this book.<br />
If you need to know how the story ends, check out the catalog entry for the traveling salesman problem in Section .<br />
Hopefully, this example has opened your eyes to some of the subtleties of algorithm correctness. Ensuring the optimal answer<br />
file:///E|/BOOK/BOOK/NODE8.HTM (4 of 5) [19/1/2003 1:28:06]
Change language