http://qs321.pair.com?node_id=969511


in reply to Travelling Salesman

I've developed a brute-force solution for a local transfer company which works fine BUT it uses a pure perl encoded version of the Dijkstra algorithm. This works fine, but proves to be the main consumer of CPU time (according to the superb NYTProf profiler)
You solved the travelling salesman problem by using Dijkstra's algorithm???

Seriously man, you shouldn't worry about your CPU time, you should worry about how to contact the Clay Mathematics Institute and cash your million dollar reward.

You've solved the top problem of the Millennium problems (P =?= NP) as defined by the Clay Mathematics Institute, each of them having a million dollar reward for solving them.

Replies are listed 'Best First'.
Re^2: Travelling Salesman
by Anonymous Monk on May 09, 2012 at 05:16 UTC
    Humor aside, I think his assumption is that open shortest path first(To wherever salesman wants to go) works for most salesmen. That might not be completely wrong either! This may not solve the 'Traveling salesman problem' but it does solve the problems of many traveling salesmen.
[reply]
      But, but, but Dijkstra's algorithm solves a completely different task: find the shortest route between two points. And while you can construct graphs where there is a pair of points where the shortest path between them actually visits all other points, that's situation most traveling salesmen won't find themselves in. (Except maybe in Chili)

      Either the OP is solving a different problem than the travelling salesman, or he's using something else than Dijkstra's.

[reply]

        I didn't do the analysis and I am guess but it should look something like this. On the whole graph, compute the shortest distance between two points in the graph(From the start point). Then the next shortest distance point from that and so on. Such that already visited points are removed from the graph every time a shortest distance point from the current point is computed.

        Every time you find the shortest distance between two points, and reach the destination point. The source point is removed. At each step you end up having a smaller graph. There fore lesser points to work on each step. While at the same time you compute shortest distance point available from the current point.

[reply]
Re^2: Travelling Salesman
by gangulphus (Initiate) on May 16, 2012 at 17:14 UTC

    Alas, I won't be claiming the big prize! I think you missed the preamble to the question, which makes it clear that in the solution to the practical problem I am facing I am using a BRUTE FORCE approach.

    As I'm sure you're aware it is possible to solve the problem by trying every possible permutation of locations to be visited, ONLY if the number of locations is small.

    In my case I am dealing with a maximum of 8 as the people I'm working with run 9 seater mini-buses (driver & 8 passengers).

    So the completely mathematically inelegant approach I'm taking is simply to calculate all possible permutations of the drop off/pick-up points (max 8) and then use the Dijkstzra algorithm to calculate the distance between each successive pair of drop off/pick-up locations and sum these to reach a total distance for each permutation.

    In this way I am guaranteed to find the shortest path.

    The people I'm working with run 20 mini-buses, which can theoretically do 6 trips a day. If each of them were to carry 8 passengers each being picked up/dropped off a a different location, the maximum calculation time on my aging twin core 32bit PC is about 15 minutes.

    This is much quicker than the task can be done manually and of course relies on the person doing it to have an intimate knowledge of the local area.

    In reality, this extreme case is never likely to occur, but I would like to reduce the time the script spends doing the Dijkstra calculations.

[reply]

In Section Seekers of Perl Wisdom