0

I would like to find a heuristic or algorithm to solve a Travelling Sales Person-like problem with some key differences:

-The graph is unweighted. (so the cost of walking from any one vertex to a connected vertex is 1)

-I want to go through each vertex at least once, rather than exactly once.

-There are dead ends in the graph which we will have to backtrack from.

The graph would look something like this:

enter image description here

Currently, I am going along a random route, saving my history in a stack until I reach a vertex not connected to any un-travelled vertex - then I backtrack to the most recent unexplored branch and explore that. I repeat this until there are no vertices left to explore - I can walk the graph using this method in 2n steps, where n is the number of vertices. I feel there must be a better way - I would appreciate any help or pointers to materials I should research!

Lrrr
  • 4,755
  • 5
  • 41
  • 63
user3635299
  • 5
  • 1

2 Answers2

1

Your problem is actually general definition of a TSP. Your current approach can be very bigger than 2n you can go through a long path and then come back to some unvisited vertex which is connected to the first vertex of a path, which causes an arbitrary big gap between an optimum and your approach.

If you looking for a good heuristic then nearest neighbor is a good approach. First of all find shortest path between each two vertex and create a new graph G' such that weight of each edge uv is the length of a shortest path between this two vertices in G. Afterward run nearest neighbor algorithm in newly created graph.

Another approach is using Christofides algorithm. Finding a spanning tree of your graph and then create an eulerian tour based on this spanning tree. This one is always at most 3/2 x optimum, so you can use combination of this and nearest neighbor algorithm to get a good result.

By the way almost all well known TSP heuristics are applicable for your problem, best known that I know and I think you can find an implementation of that in the web is tour merging algorithm due to Cook and Seymour which is incredibly accurate but not very fast or easy to implement. (If you didn't find the implementation you can ask authors of the paper to bring an implementation).

Saeed Amiri
  • 22,252
  • 5
  • 45
  • 83
  • I may not understand the nearest neighbour or Christofides algorithm very well, but they both seem to require that some cities be closer to other cities, and that you can get to any city directly from any other city. In my case I think neither of these things can be accomplished - many nodes on my graph are only connected to other nodes by way of intermediary nodes, and each node that *is* connected to another node directly is exactly 1 unit away. In other words, I don't think I can make decisions based on weight or distance, and those algorithms require both. – user3635299 May 28 '14 at 17:53
  • @user3635299, I already mentioned how to make a graph G' from a graph G. G' is a complete graph and satisfies all conditions needed in both cases. – Saeed Amiri May 28 '14 at 18:22
  • Oh yes, I see that now! And when going back from G' to G, you think that would be able to walk the graph in n – user3635299 May 28 '14 at 20:53
  • @user3635299, No it doesn't all approximations that I said are relative to G' not G, but those are better than your approach with high probability. BTW your graph has solid grid like structure, you can add extra edges and vertices to make it solid grid graph (except that long edges which are crossing others), then checking for a Hamiltonian cycle in solid grid graph can be done in polynomial time. Solid grids are subgraph of infinite grid without hole. – Saeed Amiri May 28 '14 at 21:11
  • 1
    I created G' and applied the nearest neighbour algorithm to it so far, and am very pleased with the result! My original code walked a graph of 475 nodes in 946 steps, and now it is doing it in 811! I will try some more algorithms on it, but just wanted to say: Thank you very much! – user3635299 Jun 01 '14 at 02:49
  • You can speed it up. Before you create G' your graph can be reduced ( – miguel-svq Jun 02 '14 at 01:22
0

Since the best cost in your graph would be more than n, because it's clear that from the end nodes you have to go back, i would not say a much better way exists, however, i think a little optimization that you can do is when you backtrack, you should search for alternative router to go back to the node that you wish to backtrack from, since it's not a tree, you can find shorter routes when returning. Probably there are more of these little tricks, good luck

George Nechifor
  • 439
  • 3
  • 12