I am using boost::graph and the traversal algorithms (BFS / DFS). However, I need to modify the behavior as follows: when at a particular vertex, choose the next adjacent vertex based on some properties of the vertex. I know there are visitor concepts in boost:graph. I could not find a way to use them to determine the next vertex to choose. Any help??
Thanks
It sounds to me as if you are wish to use a heuristic of some kind. Have a look at A-star search:
http://www.boost.org/doc/libs/1_53_0/libs/graph/doc/astar_search.html
http://en.wikipedia.org/wiki/A*_search_algorithm
Related
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.
For a school project, my friends and I are learning what is pathfinding and how to exploit it via a simple exercise:
For a group of ants going from A to B, they need to travel through multiple nodes, one at a time.
I've read some explanation about Dijsktra's algoritm, and I wanted to know if I could use it in a graph where every distance between every node is 1 unit. Is it optimal ? Or is A* more appropriated to my case ?
EDIT:
Since I had knowledge on the graph, BFS was prefered because distance between node was pre-computed, where Djisktra is prefered when you have absolutely nothing about the graph itself. See this post for reference
If every edge has the same cost, then Dijkstra's algorithm is the same as a breadth-first search. In this case you might as well just implement BFS. It's easier.
If you have a way to estimate how far a point is from the target, then you could use A* instead. This will find the best path faster in most cases.
I want to find connected components of a Directed Acyclic Graph using a set of nodes. What would be the most efficient way to solve this problem?
Connected Component: If one of the nodes is a predecessor or
successors of another node, they are in the same connected component.
For example, let's say I have the following graph and vector = [2,4,5,6,3]. For this vector, there are two connected component as below.
C1 = [2,4,5,6]
C2 = [3]
My solution:
Sort the nodes using their depth value
Pick a node
Check the other nodes if they are successors or not. If so, keep
looking. If not, stop and go to step 2.
What do you think?
I hope I understand your definition of connected component...If that's the case
I agree with #anonymous, you can simply make the graph undirected and find the connected components using simple DFS...
I do not quite understand your original thought, at least I think the implementation will be a bit complicated, say for edges {1-->2, 2-->4, 3-->4},
Node #1 and #3 will be sorted at the beginning of the list, and how can you know {1,2,3,4} is a single connected component?
Anyhow, the complexity is the same with the simple DFS method, at best, which is O(V)
(If anyone think this answer is correct, please give all credits to #anonymous!)
The way to find connected component is something like following :
while(anymore_root_vertex_tostartfrom){
vertex v=pick_a_vertex;
remove vertex from root_vertex_list;
initialize connected_comp_list_of_vertices;
do a breadth_first traversal from this vertex
keep adding the vertex you encounter in bfs to connected_comp_list_of_vertices
of that root
}
I would suggest reading some more about Graph processing. Finding connected component, BFS, DFS traversal have fairly standard techniques. An excellent book on this subject is Skiena's Algoritham Design Manual
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.