Am wanting to write an app that helps say a travelling salesman / musician plan their tour.
So this is about making an efficient itinerary.
So they would put in their start and end points and the places they want to visit and the program would output a suggested route to encompass those points on a map.
The suggested route would obviously minimise the time, distance and financial costs assuming the edge info is given for nodes on the network.
Could someone post in some pseudo code or pointers to sites that describe the necessary algorithm(s) required to solve this problem.
I've looked at A* but that seems to be for just a start and end points.
Any ideas welcome
thanks
Alex
As the other authors wrote, it is a traveling saleman problem. For your musician tour planer you require both, (i) an algorithm that calculates the least cost path from one location to another [via a physical network] AND (ii) an algorithm that calculates the best sequence of locations given your start and end location and additional constraints such as time windows.
(i) can be solved with for example Dijkstra, A*, Contraction Hierarchies
(ii) can be solved with Held-Karp, Branch and Bound/Cut [exactly] and Lin-Kernighan, or any other (meta)heuristic that are also applied to solve vehicle routing problems (VRP) [heuristically]
However, implementing these algorithms efficiently is not matter of days. Thus I would recommend you to use existing software. For (i) GraphHopper will be a perfect choice and for (ii) you can try jsprit. Both are written in Java and are Open Source.
TSP (Travelling Salesman Problem) is what you want, you just will have to adjust the cost function so that it's not purely based on distance. Most likely you'll want to translate distance to an actual dollar value that accounts for the travel cost as well as the travel time.
It might be good to have a slider to bias the calculation towards either travel time or travel cost (time is money and all). Although, it's not clear how helpful it would be given how computationally intensive it tends to be to optimize a TSP instance.
As mentioned, this is a case of the traveling salesman problem (TSP). Note that the TSP can be solved with a brute-force algorithm when n, the number of cities, is not too large. A musician may only want to visit 15 cities or less, so you can still find the best path with a brute-force search. You just need to calculate the weighting between the different cities (distance and other factors) and then check all possibilities to find the best possible routes. If there are more than 20 cities, you can still find the optimal solution, but you'll want a better algorithm than a direct brute-force search.
Related
I have a simple web-app that is modeling the transportation company information system. I would like to implement the feature of automatic computation of the shortest route for the given order.
new order form
Order is represented by a set of cargos, each of them has departure/arrival points. I store cities and distances between each pair of them in the database. The problem is to find the shortest route which would allow to transport all these cargos. Start and finish cities are not important, the only interesting aspect is the shortest path which will include loading/unloading of every shipping.
Is there any graph algorithm suitable for solving such problems?
If the number of items is relatively small (like your comment suggests), you can reduce the problem to Traveling Salesman Problem.
First, if you don't have the shortest distance between each pair of cities - you can find it using Floyd-Warshall algorithm. If you already have distance between each pair of cities, you can skip this step.
Now, you have yourself a proper TSP problem, that can be solved easily for low number of cities using brute force, or more complex dynamic programming solutions.
If I were you, I'd start with the naive solution, and if it's not enough - implement more complicated one.
If later on number of cities expend to large sizes, you will need more sophisticated TSP algorithms, and might even have to sattle for non optimal solution due to the nature of the problem. That said, while you are in the realm of only few cities - the existing solutions should do the trick.
I have this layout of a maze that I am having trouble thinking of how to implement a solution for:
I know there are many resources for maze solving algorithms e.g. http://www.astrolog.org/labyrnth/algrithm.htm but I am not sure which algorithm is best suited for the given maze.
There are three areas labelled “*” which are the locations that MazeSolver needs to go to before being able to exit the maze from the entrance at the top of the map.
I would appreciate pseudo code of solving the maze islands part. I would be looking for a simple solution and optimal time is not really an issue. The thing is even though an overview of the maze is provided beforehand to the solver, it may not be completely accurate at when the maze solver actually does the maze so its a little more complicated than coding it before hand or using an algorithm that uses omniscient view of the maze and needs to "half" human/doable if you get what I mean...
While the robot/robot programmer will be supplied with a map of the mine for each rescue, the map may be out of date due to new mining or due to damage from the event.
For this application the robot is required to first of all locate all the rescue areas and determine if they are occupied. The robot will have to be totally autonomous. When these have been investigated the robot should then do a check of all the passageways for humans.
The robot should also be self-navigating. While a GPS system is a natural choice, in this case it cannot be used due to the thickness of the rock ceiling preventing any GPS signals, therefore you are also required to design a navigation system for the robot. For this end, small hardware alterations, such as additional sensors or deployable radio beacons, may be added to the robot. Please note that at least one of the shelters is located in an “Island”.
Assuming you are not looking for a shortest path to get out of the maze - just any path, create some order for your Islands: island1,island2,...,islandk.
Now, assuming you know how to solve a "regular" maze, you need to find paths from:
start->island1, island1->island2, ...., islandk->end
Some comments:
Solving "regular" maze can be done using BFS, or DFS (the later is not optimal though).
If you are looking for a more efficient solution, you can use
all-to-all shortest path rather than multiple "regular" maze solving.
If you are looking for a shortest path, this is a variation of Traveling Salesman Problem. Possible solution is discussed here.
If you want to also pass through all passages, you can do it using a DFS that continues until all nodes are discovered. Again, this won't be the shortest such path, but finding the shortest path is going to be NP-Hard.
This problem is related to the Travelling salesman problem problem, which is NP-Hard, so I wouldn't expect any quick solutions for larger number of islands.
For small number of islands, you can do this: for each 2 islands (including your starting position), compute the shortest path between them. Since you are interested in distances between relatively low fraction of vertices, I recommend using the Dijkstra's algorithm, since it is relatively easy and can be done by hand (for reasonably large graf).
Now you have the shortest distances between all points of interest and it is when you need to find the Hamiltonian optimal path between them. Fortunately, the distances satisfy a metric, so you can have 2-approximation (easy, even by hand) or even 3/2-approximation (not so easy) algorithms, but no polynomial algorithms are known.
For perfect solution with 3 islands you have to check only 6 ways how to visit them (easy), but for 6 islands you can visit them in 720 ways, and for n in n! so good luck with that.
I have a graph that represents a city. I know the location of places of interest (nodes, which have a Importance value), the location of the hotel I'm staying in, how the nodes are connected, the traversal time between them and have acess to latitude and longitude. There are no issues converting from time to distance and vice-versa.
The objective is to tour the city, maximizing the importance per day but limiting one day of travel to 10 hours. A day begins and ends at the hotel. I have a working A* algorithm that chooses the lowest value but with no heuristic yet, which I guess makes it a BB for now. With that in mind:
Since I have access to Lat/Long, my first stab at an heuristic, while
only dealing with times, would be the distance as the crow flies
between a node and the hotel. Would this be an admissible heuristic?
It gives me the shortest possible distance and time, so it wouldn't
overestimate.
Now let's say the Importance of a node is between 1-4. In order to factor it in, one idea could be g(neighbor) = g(current) + (edge_cost / Importance^2). Assuming this would be valid (if not, why?):
But now the heuristic values would be in a different unit. Could a solution to this simply be give the Hotel Importance = 1? If the value is the same, will it still be admissible? EDIT: I think this will end up giving me problems because of the difference in scale.
I still have to restrict the total amount of time. Should each node keep track of the total time spent, in order to compare to the limit, plus the g() and h() values, because of the different units?
And finally:
Since I have to start and end in the same node, what comes to mind is to explore a node and should I find the hotel see if I still have time to explore the neighbors instead of going back. However, if I still have time to expand to one more node, but time runs out and I can't get to the hotel from there, I'm assuming I'll have to backtrack to the parent.
I can't help but see similarities to the knapsack problem. Even though I have to use A*, is there any lesson I can take from it?
Must my heuristic be consistent in this case? If so, why?
By the way, the purpose here is pathfinding first, optimizations second.
This actually looks like a combination of the travelling salesman problem (TSP) and knapsack problem (KP). It's KP in this respect: the knapsack capacity is 10 (for total hours available in a day) and the locations are the items. The item value equals the location value. The item weight is equal to the time it takes to travel to the location (plus the location's portion of the trip back to the hotel). The challenge arises from the fact that an item's weight is unknown until you solve the optimal tour through the selected locations--enter the TSP and Pathfinding.
One approach might be to use a pathfinding algorithm (e.g. A*, Bellman–Ford, or Dijkstra's algorithm) primarily to compute a distance matrix between each node. The distance matrix can then be leveraged while solving the TSP portion of the problem: finding a tour through the locations and using the total time as the weight.
The next step is up to you. If you are looking for an approximate solution, many heuristics exist for both TSP and KP: See Christofides TSP Heuristic, or the Minimum TSP and Maximum Knapsack entries at the Compendium of NP Optimization problems.
If on the other hand you seek an optimal solution, you may be out of luck. Still I recommend you find a copy of Graph Theory. An Algorithmic Approach by Nicos Christofides (ISBN-13: 978-0121743505). It provides heuristics for early backtracking in a Depth-First-Search that expedite the search for optimal solutions to several NP-Complete problems.
Say, we have a circular list representing a solution of the traveling salesman problem. This list is initially empty.
If the user is allowed to enter a city and it's coordinate one by one, what heuristics could be used to insert those coordinates into the already existing tour?
An example uses the nearest neighbor heuristic : it inserts the new coordinate after the nearest coordinate already in the tour.
What are some other options (pseudo-code if possible).
There are plenty of construction heuristics you can use, such as First Fit, First Fit Decreasing, Best Fit, Best Fit Decreasing and Cheapest Insertion.
Those constructions heuristics are applied on bin packing normally, but they can be converted to TSP too. Documentation about those heuristics is here.
Since you're only inserting 1 unassigned entity at at time, all of these basically revert to what you call nearest neighbor heuristic (with a slight variation on ties), but note that that is not what they usually call Nearest Neighbor. Nearest Neighbor always adds to the end of the line, the nearest neighbor of all unassigned entities.
Now, what you really want, is a decent solution, without having to restart your entire construction heuristics. That's harder: welcome to repeated planning and real-time planning (and this documentation). I am working on a open source example for TSP and vehicle routing that does real-time planning.
You can of course generalize the idea you have mentioned:
Define k'th_path(v) = minimum weight of a path including max{k,not_visited cities} cities
Note that calculating the k'th path is O(|V|^k) [this bound is not tight]
Special cases:
For k=1 you get the nearest neighbor, as you suggested.
for k=|V| you get an optimal solution [note it will be very expansive to calculate].
There are not other heuristic because TSP is always about to find the nearest coordinate. At least I don't know an algorithm that can insert a coordinate and knows the nearest coordinate but there are plenty algorithm to find a good tour. A good heuristic is for example the Christofides algorithm, it works only in euklidian space but it give you a guarantee of the solution to be within 3/2 of the optimum. It's not very easy to code. Especially the edmond blossom v algorithm is for an expert skill. The importance of a guarantee isn't high enough because how would you explain that your method can deliver non-sense in some rare situation?
I want to solve the following problem:
I have a DAG which contains cities and jobs between them that needs to be done. The jobs are for trucks which can load a definied limit. The more the truck is loaded the better is the tour. Some jobs are for loading something in and some are for loading defined things out. You can always drive from city a to b even if there is no job to be done between them.
The last restriction is that I always need to start in city a and return to a because there is the home of the trucks :)
I first thought of Dijkstra's shortest path algorithm. I could easly turn that into longest path calculation. My problem in mind is now that all these algorithms are for calculating a shortest or longest path from vertex a to b, but I need it from a returning to a - in a circle.
Has some one some kicks for my mind?
Thanks for your feedback!
Marco
This crazy combination of knapsack and travelling salesman is surely NP-hard.
Virtually everywhere, when you want to load your agent with optimal job schedule, or when you want to build a route through all vertexes in the graph, or when you feel that you need to look for a "longest path*", you most likely run into an NP-complete or an NP-hard problem.
That means, that there is no known fast and exact solution to the problem, i.e. the one that runs in a polynomial time.
So you have to create approximations and implement non-optimal algorithms based on your particular conditions. What time loss is acceptable? Are there additional patterns the trucks can drive? Do you know more about the graph (e.g. is the area divided into distant dense regions)? Answer these questions and you'll find a non-strict heuristics that satisfies your customers.
*yes, searching for longest paths is not as easy as you think. Longest path problem is NP-complete, given that your graph is not acyclic.
You're trying to find the smallest possible way to get everything done? This reminds me of a max-flow/min-cut problem. You might be able to approximate the best answer by:
Connect all terminal nodes to a final end node.
Run one of the various maximum flow algorithms to find the max flow between a and end.
Return to city a. Update the graph to reflect what you just did. Repeat until all jobs are done.
The idea is that you get the most bang for every trip. Each trip after the 1st will be less efficient and less efficient, but that's to be expected.
Note: This only works because you have a DAG. Travelling salesman wouldn't be NP-Complete on a DAG, either, and it will likely be impossible to even hit all nodes on the graph. Re-reading your problem, it seems like you don't have a DAG, since you can return to city a - is that true?
You can adjust the traveling sales man problem dynamic programming algorithm to do what you want.
The classic approach says that you want to maximize the optimum function from all cities but you can take in consideration, at each step also the possibility of returning home.
And like Pavel mentioned, this problem is definitively NP-hard. Do you have some upper bounds for the number of cities or maximum number of objects that can be loaded in a truck?
PS: Do you want the BEST solution (maximum profit - might not be realistic in terms of processing time) or you accept some approximation?
Isn't this a Transportation problem?
Depending on the trucks number and starting points, you could add a fake transporations or add costs in order to satisfy your restrictions.
I'd also ask about truck restrictions:
are they all based in the same city?
do you have a fixed number of them?
and what you win if you use less then
you have?
is there a cycle time restriction?