I have a very, very large graph, and I want to find the shortest path from one vertex to another. The graph is directed and unweighted.
I have considered using some modification of Dijkstra's algorithm, but I usually use that for weighted undirected graphs.
So then my other thought was to use a DFS, since I can treat all the weights as one.
Any suggestions? a
EDIT: Ok, I meant to say BFS, I'm sorry.
Try a BFS instead.
(Note that Dijkstra's algorithm works perfectly fine for unweighted directed graphs — it just happens that in the unweighted case, doing it smartly is essentially equivalent to a breadth-first search.)
Have you tried using A*?
Related
I need to solve a longest path problem for graphs that are both directed and non-directed (unweighted in both cases).
For directed graph, it is pretty easy to find dynamic programming algorithms that are able to solve the problem in pseudopolynomial time, starting at some node, and calculating the longest path for subproblems until every problem has been looked at.
Can I do a similar thing for at non-directed graph? I cant seem to find any litterature about it?
Every directed graph algorithm works on undirected graphs. Simply treat each edge as two directed edges with the same weight.
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.
During a course in University concerning graph theory, we were talking about finding shortest paths thus Dijkstra's algorithm came up, at that point I should mention that the edges of the graph were weighted, with weights>0. Then the professor asked how we could find the shortest path if the edges weren't weighted, I thought the same algorithm would do, since the edges had the "same" non-negative weight. But he suggested BFS. Is this true? wouldn't Dijkstra work correct? I'm not questing BFS finding the path but since it is exhaustive I thought maybe it would be better to avoid it.
Dijsktra worked fine for me even with non-wighted graphs. Every connection just has weight 1.
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 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 :)