2

I want to try my hand at finding heuristics/approximations for solving the Traveling Salesman Problem, and in order to do that, I'm looking for some "hard" TSP instances (along with their best known solutions) so that I can try solving them and see how well I can do.

Ideally, they would be simply a text-based list of adjacency matrices or adjacency lists (I don't want to deal with parsing, just the algorithm).
By "hard", I mean that they should be practically impossible to solve or approximate using brute-force.
(This is so that I can be reasonably confident that if I find an answer close to the best known answer, then I'm actually doing something right, and not just getting lucky.)

Are there any lists that would work for this purpose? I searched around a bit but didn't find anything.

user541686
  • 205,094
  • 128
  • 528
  • 886

3 Answers3

3

Here is another question on SE partially answering your problem (it lists problems, but most of these seems not to have a solution provided, but you better check the links anyway - things may have changed).

If you can't find them, what about randomly generating a set of nodes along with a path connecting them, saving the path length as "minimal" (making sure that the longest connection between two nodes is never > X) and then adding a bunch of other paths making sure these are all > X?

This way (unless I am missing something) you have a set of connected nodes "as complex as you want" and know the actual shortest connecting path from the start...

Addendum - if you really want to see how you compare to existing tools, then you have to run these on your generated problems. One that is free and accessible (but I don't know how "efficient" it may be) is the TSP Library for R.

Wikipedia has a list of other free sw packages for this.

Maybe you could create a different SE question asking for how to get other TSP tools.

Community
  • 1
  • 1
p.marino
  • 6,244
  • 3
  • 25
  • 36
  • Well, the problem isn't just with generating them -- the problem is, how would I know how well I'm doing compared to today's good TSP solvers? All this would tell me is how I'm doing compared to the optimal solution -- which I have no hope of reaching, given a sufficiently complicated graph -- and not how well I'm doing compared to existing tools. – user541686 Mar 09 '13 at 08:39
  • Regarding your edit: I'm hoping to avoid having to deal with overhead (downloading and installing entire toolsets just to solve a couple TSP problems, etc.)... so I'd really rather look for existing problems/solutions rather than spend a lot of time generating them on my own and then finding solutions for them. – user541686 Mar 09 '13 at 08:50
  • +1 the GATech link looks interesting, I'll take a look; thanks. – user541686 Mar 09 '13 at 08:55
1

The TSP gatech site seems to be the canonical site for TSP information.

Here's a list of the available datasets: http://www.tsp.gatech.edu/data/index.html

The optimal solution is available for some datasets with over 10 000 cities. And there are datasets available of over 1 000 000 cities.

Geoffrey De Smet
  • 26,223
  • 11
  • 73
  • 120
0

There is a well-known algorithm for finding the optimum TSP solution - it is called brute force.

So the only real way you can compare two algorithms has to be on the quality of the solution as well as some other criteria - usually running time.

Even here you run into a problem. Many algorithms are effectively search algorithms, and the longer you search the more possible solutions are evaluated. The algorithms already trade off quality and running time. They may or may not result in the correct (best) answer for some or all graphs.

The only real way you are going to be able to compare your algorithm to others is by implementing the other algorithms then throwing yours and them the same hard problems (and as others have identified, it is easy to make at least some types of hard problems). Implementing these existing algorithms may suggest ways of improving yours. http://en.wikipedia.org/wiki/Travelling_salesman_problem has plenty of algorithms, and at least a couple look very easy to code. Why not implement them as the first benchmark for your algorithm?

Peter Webb
  • 671
  • 4
  • 14