I have a state diagram where each state has a list of other states it can visit. My goal is to generate as many paths as necessary from state Open to state Closed such that every state transition is used.
I'm currently thinking of converting my state table into a graph, then using a graph traversal algorithm to generate my paths.
Problem is, I don't know if an algorithm exists to fit my exact scenario. I was looking at Eulerian paths, which hit every edge only once if possible. This is not ideal because there are multiple nodes that only have a way in and no way out.
Then, I was thinking of using Bellman Ford to generate paths to these closed nodes, and removing edges used in these paths and running it again.
Hopefully I described the problem well enough, let me know if there's something I can do. Thanks.
Related
I am implementing a bidirectional Dijkstra's algorithm and having issues understanding how the various implementations of the stopping condition work out.
Take this graph for example, where we're starting from node A, targetting node J. Below the graph I have listed the cluster (processed) and relaxed (fringes) nodes at the time the algorithm stops:
The accepted answer to “Bidirectional Dijkstra” by NetworkX explains that the algorithm stops when the same node has been processed in both directions. In my graph that will be Node F. If that were the case, the algorithm stops after finding the shortest path of length 9 going from A-B-C...H-I-J. But this wouldn't be the shortest path because A-J have a direct edge of length 8 which is never taken because the weight 8 is never popped from the priority queue.
Even in this Java implementation on github of Dijksta's bi-directional algorithm, the stopping condition is:
double mtmp = DISTANCEA.get(OPENA.min()) +
DISTANCEB.get(OPENB.min());
if (mtmp >= bestPathLength) return PATH;
This algorithm stops when the top node weights -- from each front and backward queue -- add up to at least the best path length so far. But this wouldn't return the correct shortest path either. Because in that case it will be node G(6) and E(5) totalling to 11, which is greater than the best path so far of length 9.
I don't understand that seemingly both of these stopping conditions yield an incorrect shortest path. I am not sure what I am misunderstanding.
What is a good stopping condition for Dijkstra's bidirectional algorithm? Also, what would be a stopping condition for bidirectional A*?
Conceptually the stopping condition for Dijkstra's algorithm, whether bidirectional or not, is that you stop when the best path you've found is as good as any path you might find if you continue. Only closed paths (the ones in your "cluster" sets above) count as found.
For bidirectional Dijkstra's, a path is "found" whenever the same vertex exists in both the forward and reverse closed sets. That part is easy, but how good is the best path you might find in the future?
To make sure the answer you get is correct, you evaluation of the best path you might find needs to be accurate, or an underestimate. Lets consider the possibilities:
A path might be made with a vertex that is open in both directions.
A vertex that is open in one direction might make a path with one that is already closed in the other direction.
The problem is case (2). The sets and priority queues we use for Dijkstra's algorithm do not allow us to make a very useful underestimate of the best path in this case. The smallest distance in a closed set is always 0, and if we add this to the minimum open from the other direction, then we come up with:
double mtmp = min ( DISTANCEA.get(OPENA.min()) , DISTANCEB.get(OPENB.min()) );
This works, and will produce the correct answer, but it will make the algorithm run until the best complete path is found in at least one direction. Unidirectional Dijkstra's would be faster in many cases.
I think this "bidirectonal Dijkstra's" idea needs significant rework in order to be really good.
Let's say we have a directed cyclic graph where every node has an edge going to exactly two other nodes - except for a 'final node', which just has multiple things going into it and nothing coming out.
Given a source, I want to find the longest possible path to that final node that doesn't hit a node more than once. There are algorithms out there to do this, but the only problem is that my graph has many different cycles, some of which are inside each other, and most naive algorithms get stuck in infinite loops when evaluated.
I tried collapsing all strongly connected components (of which there is only one), however if the source I want is inside that component, the algorithm doesn't work. And it doesn't work in the general case either, because within that strongly connected component, to hit every node you may have to hit some nodes multiple times, which I don't want.
What's an efficient algorithm I can use for calculating the longest path back to the final vertex in an unweighted directed, cyclic graph such that no node is hit multiple times?
You can see this question, it's also a problem about finding the longest path in a directed cyclic graph, and the standard code is also available.
Question:http://poj.org/problem?id=3592
Answer: https://blog.csdn.net/u013514182/article/details/42364173
I need an algorithm to find ANY path from point A to point B in a graph.
The problem is that finding out wich nodes can follow a specific one needs a quite lengthy matlab simulation, so i want to access as few nodes as possible.
I know some heuristics about the graph, I.E. every node has some coordinates and follow-up nodes are always "near" the previous one, but there is not always a connection between two close nodes.
I am not searching for an optimal path, or even a short one. I just need any connection.
My first try was some simple greedy algorithm that always picks a follow up node closest to the final node, but this ended in dead ends very often. This wouldn't be a problem, but i have no idea how to efficiently move out of a deadend, currently i simply move through all nodes inside the dead end until i find a better way.
Here is a drawing of an example where i already know the solution:
There are many nodes, so calculating the edges for every node in this small dead end on the top takes about 1h20min. (You can assume every pixel in the picture is a node.)
To put it in short words: how do i find a good way around the obstacle without looking at every node inside a whole area.
Sorry if this a silly question but i'm an engineer and never had a formal education in programming aside from making a LED blink.
Thanks in advance!
this is a problem I've got from my class (I assure you it's not homework). I'm still pondering about it until now. You will receive a graph with at most 25 nodes and 25 edges. Additionally, each node will have degree of at most 3. The task is to find the longest path in this graph. However, you won't only receive 1 graph, but 15,000 graphs, and you'll need to find the longest path in all of them in 1 second. Could anyone please give me a solution (or better yet, just a hint) to this problem? Thank you very much!
Info:- Nodes can be revisited, the only constraints are the edges.- The graphs are given by the edges. So the first line states how many nodes and edges there are, and the lines after that represent the edges, each edge by a pair of integers.- The edges are unweighted.- The only answer required is the length of the path, not the path itself.- This might be important: the graph isn't necessarily connected.
After I saw that "nodes can be revisited", I realised that this is in some ways a trick question. To satisfy those seemingly unbelievable time constraints, what you actually need here is not an algorithm for constructing such a path (usually called a trail, BTW, if vertices can be reused), but rather, for each connected component of the graph, a way of quickly detecting whether all or nearly all edges in that component can be included in a single trail.
So here is my hint: Did you know that there are seven bridges in Königsberg? ;-)
That might seem cryptic, but I think some quick searching around will point you in the right direction, and you will soon find a way to quickly detect whether all edges in a component can form part of the same trail. (You'll need to do some more thinking to figure out how many edges can be included when the answer to the above question is "no".)
How can I find all vertices in a directed graph such that every another vertex is reachable from this one? Now I can "invent" only O(|V|^3) algo -- a DFS/BFS from every vertex, but I'm sure, there exists a faster way to solve this.
Thank you!
Run a strongly connected components algorithm to collapse the graph into a directed acyclic graph of its strongly connected components. There must be at least one strongly connected component with no incoming edges. If there is exactly one, the nodes in that component are the ones you're looking for. If there are multiple strongly connected components with no incoming edges, there is no node from which all other nodes are reachable.
EDIT: See comments below!
Sometimes it's all about the terminology. Here the magic word is reachability (see Wikipedia). Unfortunately, I don't think you'll like the results.
If not all the answers are needed, running BFS/DFS is actually recommended.
Otherwise, use the Floyd-Warshall algorithm. Still runs in O(|V|3).
Certain optimized algorithms exist for special cases - see Wikipedia for more detail.
So that's probably not what you wanted to hear.