1

Assume I want to minimize the distance traveled between a series of cities:

starting tour: S-1-2-3-4-5-E

optimal tour: S-5-1-2-3-4-E

The tour must start at S, must end at E, but can visit the cities in between in any order. In my use case, the number of cities in between S and E will be between 1 and 35.

The heuristic I'm currently using is a repeated two-opt (shown in pseudo-javascript):

minStopSequence = ['S', 1, 2, 3, 4, 5, 'E'];
changed = true;
while (changed === true) {
  changed = false;
  for (i = 1; i < minStopSequence.length - 2; i++) {
    for (j = i + 1; j < minStopSequence.length - 1; j++) {
      newStopSequence = reverseTheMiddleSection(minStopSequence, i, j);
      newSegmentDur = getDuration(newStopSequence);
      if (newSegmentDur < minSegmentDur) {
        minSegmentDur = newSegmentDur;
        minStopSequence = newStopSequence;
        changed = true;
      }
    }
  }
}

This often fails at finding the optimal solution (for example, it won't find the optimal tour in the example above). I tried augmenting this with a shift (for each index, for each length, move that segment to the end), but doing so causes 2 problems:

  1. I repeat some tour possibilities (inefficient)
  2. I still don't hit optimality, even with tours as small at 5 cities long

I've seen the lin-kernighan-helsgaun algorithm achieves optimality for sizes < 50, and an 'exact' variation works with asynchronous graphs (http://www.researchgate.net/profile/Daniel_Karapetyan/publication/227414913_Lin-Kernighan_heuristic_adaptations_for_the_generalized_traveling_salesman_problem/links/02e7e527676733456d000000.pdf p.11), but am unsure how to adapt it to my use case.

If it is possible to use this heuristic, could you help me figure out how to implement it? If not, what would be the most suitable heuristic that returns optimal results for the smallest problems (say n < 15) and near-optimal for the larger ones?

Matt K
  • 4,813
  • 4
  • 22
  • 35
  • Looks (on my first read through) like this is doing a simple hill-climbing (or descending in this case) heuristic. This can be prone to getting stuck in a local minimum rather than find the global minimum. You may need some other operators in the mix, and even then you probably need to allow some non-improving solutions to be accepted to get you out of the local min. But then you need more infrastructure to implement these, and end up with something like Tabu or simulated annealing. – TimChippingtonDerrick Sep 06 '15 at 11:30
  • makes sense, at least intuitively I keep thinking there's gotta be a simpler solution since the problem sizes are so small. maybe not :-/ – Matt K Sep 06 '15 at 12:49
  • 1
    That's one of the things about these sorts of problems. They look intuitively simple, but in reality they can be fiendishly difficult. Adding more complex operators on your subtour can help, but then it becomes difficult to choose between them (as there are many more possible changes in your subtour to try - first improving change, best change found in N attempts or all possible attempts, whatever) and also keep track of which ones you have used or not to avoid cycling. Lots of fun to be had here, and plenty of room to be inventive. – TimChippingtonDerrick Sep 06 '15 at 12:59

1 Answers1

2

The simplest algorithm that can solve 15-city problems optimally is the exponential-time dynamic program: https://class.coursera.org/algo2-002/lecture/181 . With that as a starting point, you can do a large-neighborhood local search by applying it to 15-city subtours.

David Eisenstat
  • 64,237
  • 7
  • 60
  • 120