1

While obviously not optimal, I've usually found that such an "algorithm" is pretty close to the true shortest possible path, and is obviously runnable in polynomial time, with an O equal to your sorting algorithm

Arctic
  • 11
  • 1
    See https://math.stackexchange.com/questions/4404052/why-is-the-traveling-salesperson-problem-difficult for an example where this strategy fails to find the best path. As for an approximation ratio for the algorithm you describe (called the Nearest Neighbor algorithm) see https://math.stackexchange.com/questions/3034099/how-to-show-that-the-nearest-neighbour-algorithm-given-an-instance-of-the-metric and the linked paper https://disco.ethz.ch/courses/fs16/podc/readingAssignment/1.pdf – jet457 Oct 17 '23 at 15:10
  • 1
    See also here, and these Wikipedia pages: https://en.wikipedia.org/wiki/Nearest_neighbour_algorithm and https://en.wikipedia.org/wiki/Travelling_salesman_problem. There are many approximation algorithms which always give a solution that's no more than $50%$ more than the actual optimum, for example! PS: it's actually faster not to sort all the $O(V^2)$ edges (taking $O(V^2 \log V)$ time) but rather, just finding the closest vertex by brute force at each stage takes $O(V^2)$ time overall. – Izaak van Dongen Oct 17 '23 at 15:27

0 Answers0