I was wondering for dijkstra's and prim's algorithm, what happens when they are choosing between more than one vertex to go to ,and there are more than one vertex with the same weight.
For example
Example Image http://img688.imageshack.us/img688/7613/exampleu.jpg
It doesn't matter. Usually the tie will be broken in some arbitrary way like which node was added to the priority queue first.
The goal of Dijkstra is to find a shortest path. If you wanted to find all shortest paths, you would then have to worry about ties.
There could be multiple MSTs, and whichever arbitrary tiebreaking rules you use might give you a different one, but it'll still be a MST.
For example, you can imagine a triangle A-B-C where all the edge weights are one. There are three MST in this case, and they are all minimum.
The same goes for Dijkstra and the shortest path spanning tree -- there could be multiple shortest path spanning trees.
Correct me if I'm wrong, but your graph doesn't have any alternate paths for Dijkstra's algorithm to apply.
Dijkstra algorithms expands (or "relaxes") all the edges from a touches but not expanded node (or "gray" node) with the smallest cost.
If two nodes have the same cost, well... it's just random :)
Related
I'm currently studying shortest path problems in graphs with non-negative edge weight.
I know that Dijkstra algorithm can give me the solution to the single-source shortest path problem ie one can find the shortest path from one node to all other nodes but I haven't found algorithm that can give me the solution to a a priori simpler problem : find the shortest path between two nodes.
Intuitively, I think that one can find examples that show that the "simpler" problem isn't simpler than the single-source shortest path problem but I'm looking for references that show this contradiction (a priori) on simple (ie with a few number of nodes) graphs.
Some (but not all) single-source shortest paths algorithms can be easily modified to return the shortest path between two nodes by stopping the algorithm early. A simple example of this is breadth-first search in unweighted graphs. For example, to find the shortest path from a node u to a node v, start a BFS from u. As soon as v is found, the path from u to v discovered that way is the shortest path. Dijkstra’s algorithm can also do this: if you run a Dijkstra’s algorithm starting at node u, you can stop the algorithm as soon as you dequeue v from the priority queue to get the shortest path there.
These approaches are usually faster than running the whole algorithm to completion. But if you’re interested specifically in finding a path from one node to another, you might want to look at the A* search algorithm. This is a modification of Dijkstra’s algorithm that’s specifically optimized for the problem of getting from one node to another. It uses a heuristic to guide the search toward the target, deprioritizing searching for other nodes, and thus is much faster than Dijkstra’s algorithm in general.
As a note, not all shortest paths algorithms can be cut off early this way. For example, when there are negative edge weights but no negative cycles, Bellman-Ford can still compute shortest paths. However, it may continually revise node distances as it runs, up to the last round of the algorithm. Cutting the search off early can give back the wrong answer.
Does it make sense to use A* search algorithm on unweighted directed graphs for finding shortest path?
From reading http://www.cs.cmu.edu/~cga/ai-course/astar.pdf seems like A* could be expensive in terms of memory, also for unweighted graphs, how would it even determine heuristic?
This post here seems to conclude A* should not be used for unweighted graphs.
What would be the best/lease expensive algorithm to use for finding shortest path on unweighted directed graphs? Just a simple BFS?
There is no point to the full A* unless you have a useful heuristic to use it with. That said, if your heuristic is that every node is guessed to be the same possible distance from the target, then A* search will give you the same result as BFS because you will look at every node reached by a shorter path before looking at a node reached by a longer one.
As for the best, the best algorithm that I am aware of is a BFS starting at both ends, using a hash to detect the first intersection. That is, you mark the source and the target. Then extend the source out to a depth of 1, then the target to a depth of 1, then the source out to a depth of 2, then the target to a depth of 2, and so on. When you intersect, you have the shortest path out to the intersection from both directions. So traverse the one from the source out to the intersection point, then the intersection back to the target.
This is, for example, the kind of algorithm that gets used to find who is close to you in a large social network like LinkedIn.
If you have a heuristic, use A*. If you don't, don't.
Often unweighted graphs have additional structure that can be exploited, eg. if your graph is actually a 2D grid, Jump Point Search is much faster than normal A*. We'll need to know more about your problem domain to recommend anything further.
Would like to find the shortest weighted path from the node a to any node. The destination node is not given. One can visit any vertex many time.
if the path weight's should be less than Integer.MAX
what is the algorithm to proceed ..?? cant detect the algorithm itself.
i did try for travelling salesman problem but it doesn't match ; neither it match for Dijkstra ...
how to keep in memory all the paths is the major challenge here ..
Edit: Graph is not directed one and there are no negative wieghts.
references: http://en.wikipedia.org/wiki/Cycle_detection#Tortoise_and_hare
http://en.wikipedia.org/wiki/Travelling_salesman_problem
For an undirected graph with no negative weights, it's possible to use Floyd-Warshall algorithm to find all-pairs shortest path with time complexity of O(V^3), where V is a number of vertices. The algorithm also allows an easy way to reconstruct the all computed shortest paths. It uses O(V^2) memory to store distances and additional information for reconstructing the path.
There are also some other algorithms for solving this problem with better time complexity, but Floyd-Warshall is really easy to code and start with.
Would like to find the shortest weighted path from the node a to any
node.
I immediately think Dijkstra's algorithm, because that's exactly what it does.
how to keep in memory all the paths is the major challenge here ..
For each node in the graph, keep track of it's previous node that would result in the shortest path. Take a look at the pseudocode, line 20.
To build the path, simply go backwards from the destination node until you reach the source node.
My graph contains no such edges which connect a vertex to itself. There is only one edge between two vertices. From Wikipedia i got to know about some algorithm which are used for calculating shortest path based on the given conditions. One of the most famous algorithm is Dijkstra's algorithm, which finds a shortest paths from source vertex to all other vertices in the graph.
But by using Dijkstra's algorithm, i am unnecessary exploring all the vertices, however my goal is just to find shortest path from single source to single destination. Which strategy should i use here? So that i need not to explore all other vertices.
One of my approach is to use bidirectional bfs. By bidirectional bfs i mean to apply two bfs one from source node, another one from destination node. As soon as for the first time when i find any same child in both tree,i can stop both bfs .Now the path from source to that child union path from child to destination would be my shortest path from source to destination.
But out of all the approaches described by Wikipedia and bidirectional bfs, which one suits best for my graph?
It depends if there's any apparent heuristic function that you could use or if you don't have any further usable information about your graph.
Your options are:
BFS: in general case or if you don't care about computation time that much.
Dijkstra (Dijkstra "is" BFS with priority queue): if your edges have weights/prices (non negative) and you care about CPU time.
A* (A* "is" Dijkstra with heuristic function - e.g. distance on a city map): if you want it to be really fast in average case, but you have to provide good heuristic function.
For some graph problems it may be possible to use Dynamic programming or other algorithmic tools. It depends on a situation. Further information can be found in tutorials from http://community.topcoder.com/tc?module=Static&d1=tutorials&d2=alg_index ...
From Introduction to Algorithms (CLRS) second edition, page 581 :
Find a shortest path from u to v for a given vertices u and v. If we solve the single-source problem with source vertex u, we solve this problem also. Moreover, no algorithms for this problem are known that run asymptotically faster than the best single-source algorithms in the worst case.
So, stick to Dijkstra's algorithm :)
The Wikipedia article spells out the answer for you:
If we are only interested in a shortest path between vertices source and target, we can terminate the search at line 13 if u = target.
You could use Dijkstra's algorithm and optimize it in the way that you stop exploring paths that are already longer than the shortest you found so far. Because those are not going to be shorter (provided that you don't have negative weighs on your edges).
I have a list of interconnected edges (E), how can I find the shortest path connecting from one vertex to another?
I am thinking about using lowest common ancestors, but the edges don't have a clearly defined root, so I don't think the solution works.
Shortest path is defined by the minimum number of vertexes traversed.
Note: There could be a multi-path connecting two vertices, so obviously breadth first search won't work
Dijkstra's algorithm will do this for you.
I'm not sure if you need a path between every pair of nodes or between two particular nodes. Since someone has already given an answer addressing the former, I will address the latter.
If you don't have any prior knowledge about the graph (if you do, you can use a heuristic-based search such as A*) then you should use a breadth-first search.
The Floyd-Warshall algorithm would be a possible solution to your problem, but there are also other solutions to solve the all-pairs shortest path problem.
Shortest path is defined by the minimum number of vertexes treversed
it is same as minimum number of edges plus one.
you can use standard breadth first search and it will work fine. If you have more than one path connecting two vertices just save one of them it will not affect anything, because weight of every edge is 1.
Additional 2 cents. Take a look at networkx. There are interesting algos already implemented for what you need, and you can choose the best suited.