80 likes | 199 Views
6 The Mathematics of Touring. 6.1 Hamilton Paths and Hamilton Circuits 6.2 Complete Graphs? 6.3 Traveling Salesman Problems 6.4 Simple Strategies for Solving TSPs 6.5 The Brute-Force and Nearest-Neighbor Algorithms 6.6 Approximate Algorithms 6.7 The Repetitive Nearest-Neighbor Algorithm
E N D
6 The Mathematics of Touring 6.1 Hamilton Paths and Hamilton Circuits 6.2 Complete Graphs? 6.3 Traveling Salesman Problems 6.4 Simple Strategies for Solving TSPs 6.5 The Brute-Force and Nearest-Neighbor Algorithms 6.6 Approximate Algorithms 6.7 The Repetitive Nearest-Neighbor Algorithm 6.8 The Cheapest-Link Algorithm
Approximate Algorithms A really good algorithm for solving TSPs in general would have to be bothefficient(like the nearest-neighbor algorithm) and optimal(like the brute-forcealgorithm). In practice this would ensure that we could find the optimal solutionto any TSP. Unfortunately, nobody knows of such an algorithm. Moreover,we don’t even know why we don’t know. Is it because such an algorithm is actually amathematical impossibility? Or is it because no one has yet been clever enoughto find one?
Approximate Algorithms Despite the efforts of some of the best mathematicians of our time, the answers to these questions have remained quite elusive. So far, no one has beenable to come up with an efficient and optimal algorithm for solving TSPs or, alternatively, to prove that such an algorithm does not exist. Because this question hasprofound implications in an area of computer science called complexity theory, ithas become one of the most famous unsolved problems in modern mathematics.
Approximate Algorithms In the meantime, we are faced with a quandary. In many real-world applications, it is necessary to find some sort of “solution” for TSPs involving graphs withhundreds and even thousands of vertices, and to do so in a reasonable time (usingcomputers as helpers, for sure). We will use the term approximate algorithm to describe any algorithm thatproduces solutions that are, most of the time, reasonably close to the optimal solution.
Example 6.9 A Tour of 10 Cities: Part 2 When we left Willy back in Example 6.8, we had (1) decided not totry the brute-force algorithm (way too much work for just a $200 reward) and(2) used the nearest-neighbor algorithm to find the tour A, C, E, D, B, J, G, K, F,H, A, with a total cost of $2153 (it took about 10 minutes). Is this an optimal tour?If not, how close is it to the optimal tour? To answer these questions we would have to know the cost of the optimaltour.
Example 6.9 A Tour of 10 Cities: Part 2 It turns out that this cost is $1914. (This value was found using a computerprogram in just a few seconds, but this is deceptive. Somebody had to spend a lotof time writing the program, and someone – the author – had to spend a fair amount oftime entering the city-to-city costs. Even with a computer, it’s a hassle.) We canconclude, with hindsight, that the nearest-neighbor tour is off by a relative errorof about [12153 – 1914]/1914≈ 0.1249 = 12.49%.
Key Point The key point of Example 6.9 is that choosing an approximate but efficient algorithm over an optimal but inefficient algorithm is often a good tradeoff. As theysay, “time is money.”(This is a big departure from the conventional wisdom thatmath problems have either “right” or “wrong” answers. When dealing with algorithmic problems we need to consider not only the quality of the answer but alsothe amount of effort it takes to find it.)