I have found many algorithms and approaches that talk about finding the shortest path or the best/optimal solution to a problem. However, what I want to do is an algorithm that finds the first K-shortest paths from one point to another. The problem I'm facing is more like searching through a tree, when in each step you take there are multiple options each one with its weight. What kinds of algorithms are used to face this kind of problems?
There is the 2006 paper by Jose Santos
comparing three different K-shortest path finding algorithms.
Yen's algorithm implementation:
http://code.google.com/p/k-shortest-paths/
Easier algorithm & discussion:
Suggestions for KSPA on undirected graph
EDIT: apparently I clicked on a link, because I thought I was answering to a new question; ignore this if - as is very likely - this question isn't important to you anymore.
Given the restricted version of the problem you're dealing with, this becomes a lot simpler to implement. The most important thing to notice is that in trees, shortest paths are the only paths between two nodes. So what you do is solve all pairs shortest paths, which is O(n²) in trees by doing n BFS traversals, and then you get the k minimal values. This probably can be optimized in some way, but the naive approach to do that is sort the O(n²) distances in O(n² log n) time and take the k smallest values; with some book keeping, you can keep track of which distance corresponds to which path without time complexity overhead. This will give you better complexity than using a KSPA algorithm for O(n²) possible s-t-pairs.
If what you actually meant is fixing a source and get the k nodes with the smallest distance from that source, one BFS will do. In case you meant fixing both source and target, one BFS is enough as well.
I don't see how you can use the fact that all edges going from a node to the nodes in the level below have the same weight without knowing more about the structure of the tree.
Related
So I have the following layout:
graph representation
The objective is to collect all the yellow blocks by moving the white ball around. I'm trying to come up with an algorithm that will calculate an efficient path however I'm not too sure where to start.
Initially I thought about path finding algorithms like Djikstra and A* but they don't seem to fit with my goal. I've also thought about hamiltonian paths which is closer to what I want but still doesn't seem to solve the problem.
Any suggestions on what sort of algorithm can be used would be appreciated.
Your problem has a classic name in the litterature, it is the minimum hamiltonian walk problem. Beware not to mistake it with the minimum hamiltonian path problem, its 'cousin', because it is much more famous, and much, much harder (finding a hamiltonian walk can be done in polynomial time, finding a hamiltonian path is NP-complete). The traveling salesman problem is the other name of the minimum hamiltonian path problem (path, not walk).
There are very few ressources on this problem, but nevertheless you can have a look at an article called 'An algorithm for finding a short closed spanning walk in a graph' by Takamizawa, Nishizeki and Saito from 1980. They provide a polynomial algorithm to find such a path.
If the paper is a bit hard to read, or the algorithm too complex to implement, then I'll suggest that you go for the christofides algorithm, because it runs in polynomial time, and is somehow efficient (it is a 2-approximation if I remember well).
Another possible approach would be to go for a greedy algorithm, like a nearest unvisited neigbor algorithm (start somewhere, go to the nearest node that is not in the walk yet, repeat until everyone is in the walk).
Acutally, I think the easiest and maybe best simple solution is to go greedy.
Assume we're given a graph on a 2D-plane with n nodes and edge between each pair of nodes, having a weight equal to a euclidean distance. The initial problem is to find MST of this graph and it's quite clear how to solve that using Prim's or Kruskal's algorithm.
Now let's say we have k extra nodes, which we can place in any integer point on our 2D-plane. The problem is to find locations for these nodes so as new graph has the smallest possible MST, if it is not necessary to use all of these extra nodes.
It is obviously impossible to find the exact solution (in poly-time), but the goal is to find the best approximate one (which can be found within 1 sec). Maybe you can come up with some hints of the most efficient way of going throw possible solutions, or provide with some articles, where the similar problem is covered.
It is very interesting problem which you are working on. You have many options to attack this problem. The best known heuristics in such situation are - Genetic Algorithms, Particle Swarm Optimization, Differential Evolution and many others of this kind.
What is nice for such kind of heuristics is that you can limit their execution to a certain amount of time (let say 1 second). If it was my task to do I would try first Genetic Algorithms.
You could try with a greedy algorithm, try the longest edges in the MST, potentially these could give the largest savings.
Select the longest edge, now get the potential edge from each vertex that are closed in angle to the chosen one, from each side.
from these select the best Steiner point.
Fix the MST ...
repeat until 1 sec is gone.
The challenge is what to do if one of the vertexes is itself a Steiner point.
I have a random undirected social graph.
I want to find a Hamiltonian path if possible. Or if not possible (or not possible to know if possible in polynomial time) a series of paths. In this "series of paths" (where all N nodes are used exactly once), I want to minimize the number of paths and maximize the average length of the paths. (So no trivial solution of N paths of a single node).
I have generated an adjacency matrix for the nodes and edges already.
Any suggestions? Pointers in the right direction? I realize this will require heuristics because of the NP-complete (?) nature of the problem, and I am OK with a "good enough" answer. Also I would like to do this in Java.
Thanks!
If I'm interpreting your question correctly, what you're asking for is still NP-hard, since the best solution to the "multiple paths" problem would be a Hamiltonian path, and determining whether one exists is known to be NP-hard. Moreover, even if you're guaranteed that a Hamiltonian path doesn't exist, solving this problem could still be NP-hard, since I could give you a graph with a single disconnected node floating in space, for which the best solution is a trivial path containing that node and a Hamiltonian path in the remaining graph. As a result, unless P = NP, there isn't going to be a polynomial-time algorithm for your problem.
Hope this helps, and sorry for the negative result!
Angluin and Valiant gave a near linear-time heuristic that works almost always in a sufficiently dense Erdos-Renyi random graph. It's described by Wilf, on page 121. Probably your random graph is not Erdos-Renyi, but the heuristic might work anyway (when it "fails", it still gives you a (hopefully) long path; greedily take this path and run A-V again).
Use a genetic algorithm (without crossover), where each individual is a permutation of the nodes. This gives you "series of paths" at each generation, evolving to a minimal number of paths (1) and a maximal avg. length (N).
As you have realized there is no exact solution in polynomial time. You can try some random search methods though. My recommendation, start with genetic algorithm and try out tabu search.
Suppose I have 10 points. I know the distance between each point.
I need to find the shortest possible route passing through all points.
I have tried a couple of algorithms (Dijkstra, Floyd Warshall,...) and they all give me the shortest path between start and end, but they don't make a route with all points on it.
Permutations work fine, but they are too resource-expensive.
What algorithms can you advise me to look into for this problem? Or is there a documented way to do this with the above-mentioned algorithms?
Have a look at travelling salesman problem.
You may want to look into some of the heuristic solutions. They may not be able to give you 100% exact results, but often they can come up with good enough solutions (2 to 3 % away from optimal solutions) in a reasonable amount of time.
This is obviously Travelling Salesman problem. Specifically for N=10, you can either try the O(N!) naive algorithm, or using Dynamic Programming, you can reduce this to O(n^2 2^n), by trading space.
Beyond that, since this is an NP-hard problem, you can only hope for an approximation or heuristic, given the usual caveats.
As others have mentioned, this is an instance of the TSP. I think Concord, developed at Georgia Tech is the current state-of-the-art solver. It can handle upwards of 10,000 points within a few seconds. It also has an API that's easy to work with.
I think this is what you're looking for, actually:
Floyd Warshall
In computer science, the Floyd–Warshall algorithm (sometimes known as
the WFI Algorithm[clarification needed], Roy–Floyd algorithm or just
Floyd's algorithm) is a graph analysis algorithm for finding shortest
paths in a weighted graph (with positive or negative edge weights). A
single execution of the algorithm will find the lengths (summed
weights) of the shortest paths between all pairs of vertices though it
does not return details of the paths themselves
In the "Path reconstruction" subsection it explains the data structure you'll need to store the "paths" (actually you just store the next node to go to and then trivially reconstruct whichever path is required as needed).
I have about 70k nodes, and 250k edges, and the graph isn't necessarily connected. Obviously using an efficient algorithm is crucial. What do you recommend?
As a side note, I would appreciate advice on how to divide the task up between several machines--is that even possible with this kind of problem?
Thanks
You could use the Floyd-Warshall algorithm. It solves exactly this problem.
The complexity is O(V^3).
There is also Johnson's algorithm with a complexity of O(V^2*log V + VE). The latter is also easy to distribute because it runs Dijkstra's algorithm V times, which can be done in parallel.
MapReduce is a great distributed algorithm for this, though it might be a little too high-powered. If you're interested in that, take a look at this lecture or maybe this blog post for inspiration. (In fact, when I was taught MapReduce, this was one of the first examples.)
For 250k edges and 70k, it seems like the graph is relatively sparse, Dijkstra's algorithm runs in O( E + V log V ) for each node, for a full running time (all sources) of O( VE + V^2 log V ). This should be fast enough, but the usual caveats apply for Dijkstra's. (Negative edges.)
You can also take a look at Johnson's algorithm if your problem deals with negative weights, but not negative cycles. Specifically, it can also be distributed, as it takes the reweighted graph and runs Dijkstra's algorithm from each node.
There are two naive ways of parallelizing this problem:
1) Identify subcomponents and distribute these over different computers. The path length between two nodes from two different components is undefined.
2) Load the graph in different computers and give every computers a list of nodes to calculate all shortest paths. The results for one node are not dependent on the results of another node so you can parallelize this problem.
Upside: not too hard to implement but I would only do it like this if you have to solve this once. If this is a recurring issue then you might want to look at distributed algorithsm.
Use igraph, it's written in C, pretty fast and you can use Python as a wrapper language.
Look at papers/publications which have the following keywords: distributed graph search algorithms. Here's one that may be of help.
There's this ACM account only paper as well: Distributed computation on graphs: shortest path algorithms