Traveling Salesman Problem for a large number of vertices

Question

I need to solve TSP for a large number of vertices(30-100) with good accuracy and adequate time(like 1-2 days). My graph can contain asymmetrical edges(g[i][j] not equal g[j][i]).

I tried greedy, little(maybe my bad, but that shows worse results than greedy), simple genetic algo(barely better than greedy) , dynamic for O(2^n*n) (fast out of memory).

I believe you need to ask your question here: https://cs.stackexchange.com/questions/tagged/algorithms and here in StackOverflow I recommend to mention your implementation language. — Maziar Aboualizadehbehbahani, Jul 16 '19 at 18:03
Welcome to StackOverflow. Please follow the posting guidelines in the help documentation, as suggested when you created this account. [On topic](https://stackoverflow.com/help/on-topic), [how to ask](https://stackoverflow.com/help/how-to-ask), and ... [the perfect question](https://codeblog.jonskeet.uk/2010/08/29/writing-the-perfect-question/) apply here. Since there are myriad references to TSP on line, I'm not at all clear on what you're asking. — Prune, Jul 16 '19 at 18:10

score 0 · Answer 1 · answered Jul 16 '19 at 18:09

0

Well, 30-100 is not really large number of vertices. Did you miss some zeroes? Or you are facing some special hard to solve cases like p43 from TSPLIB?

In any case, if you are looking for a good heuristic I used to use Ant Colony Optimization for Asymmetric TSP. It is easy to implement and providers quite good performance.

You might take a look at my old implementation: https://github.com/aligusnet/optimer/tree/master/src/heuristics/aco

answered Jul 16 '19 at 18:09

Aligus

1,585
1
9
11

What do you mean by "miss some zeroes"? Thanks, i will try your implementation tomorrow and tell about results. – Sergei Voloboev Jul 16 '19 at 18:35
I mean that the size might be 3000 or so? Because the problems of size 30-100 in most cases solvable in seconds. – Aligus Jul 16 '19 at 18:51
Nope, i am new in this field and have problems with 30-100 vertices) – Sergei Voloboev Jul 16 '19 at 18:53

score 0 · Answer 2 · answered Jul 17 '19 at 05:26

If you can accept not an optimal, but "close to optimal" solution, I can suggest you to use "random traveling" algorithm. Idea of this algorithm - do not BFS/DFS search through entire combination tree, but search just random DFS-subtrees.

For example, you have vertices [A-Z], and you start point within [A]. Try 10000 attempts for each path (total 32 prefix), started from [A-B-...], [A-C-...] and so on, where [...] is randomly selected full-depth path through your graph, according your rules. Keep cost of appropriate paths within array, where cost is sum of costs from each prefix. Because of you use equal attempts to all "start prefixes", sum of minimal prefix will show you best step from [A]. Of course, this is not guarantee for optimal, but this is high probability to be so. For example, sum of 10,000 attempts withing path [A-K] is lowest. Next step - accept first step [A-K], and again repeat algorithm, until you found the solution.

score 0 · Answer 3 · answered Jul 19 '19 at 07:56

Here's the TSP source code of the OptaPlanner implementation, fwiw. It deals with datasets up to 10k visits pretty good when NearbySelection is activated (or up to 500 visits or so if it's not activated) - to go above 10k you'll need to activate Partitioned Search which comes at a trade-off.

It has asymmetric datasets (using OpenStreetMap data) in the import/belgium/road-time directory. It can't prove if it reaches the optimal solution or not. Usually termination is set on either a few minutes or on a few unimproved minutes.

Benchmarks showed that Late Acceptance has slightly better results than Simulated Annealing and Tabu Search, given a specific set of MoveSelectors configured, but your mileage may vary...

Traveling Salesman Problem for a large number of vertices

3 Answers3