I want to compute all the paths in directed acyclic graph from multiple inputs (x1, .., xn) to one output. The graph has the same depth which d and the inputs come to the graph at the same time (the shape is like Artificial Neural Networks with many inputs and one output). Could you please tell me if there are some algorithms that can compute such paths?
Regards,
1) Run a depth first search, starting at the output and traversing each edge in the reverse direction, to find all nodes from which you can get to the output.
2) Delete all nodes from which you cannot get to the output.
3) Run a recursive search on the modified graph, starting at each input node in turn, to find all paths to the output.
Because you have removed all the dead ends, this should produce all the paths as fast as you can output them, but you should be warned that there may be a very large number of different paths, even from small graphs - a graph the shape of a ladder and length n may have about 2^n paths - at each rung you have a choice as to whether to go up the left or the right hand side of the ladders, so there are 2^(number of rungs) different paths.
Related
Let G be a directed weighted graph with nodes colored black or white, and all weights non-negative. No other information is specified--no start or terminal vertex.
I need to find a path (not necessarily simple) of minimal weight which alternates colors at least n times. My first thought is to run Kosaraju's algorithm to get the component graph, then find a minimal path between the components. Then you could select nodes with in-degree equal to zero since those will have at least as many color alternations as paths which start at components with in-degree positive. However, that also means that you may have an unnecessarily long path.
I've thought about maybe trying to modify the graph somehow, by perhaps making copies of the graph that black-to-white edges or white-to-black edges point into, or copying or deleting edges, but nothing that I'm brain-storming seems to work.
The comments mention using Dijkstra's algorithm, and in fact there is a way to make this work. If we create an new "root" vertex in the graph, and connect every other vertex to it with a directed edge, we can run a modified Dijkstra's algorithm from the root outwards, terminating when a given path's inversions exceeds n. It is important to note that we must allow revisiting each vertex in the implementation, so the key of each vertex in our priority queue will not be merely node_id, but a tuple (node_id, inversion_count), representing that vertex on its ith visit. In doing so, we implicitly make n copies of each vertex, one per potential visit. Visually, we are effectively making n copies of our graph, and translating the edges between each (black_vertex, white_vertex) pair to connect between the i and i+1th inversion graphs. We run the algorithm until we reach a path with n inversions. Alternatively, we can connect each vertex on the nth inversion graph to a "sink" vertex, and run any conventional path finding algorithm on this graph, unmodified. This will run in O(n(E + Vlog(nV))) time. You could optimize this quite heavily, and also consider using A* instead, with the smallest_inversion_weight * (n - inversion_count) as a heuristic.
Furthermore, another idea hit me regarding using knowledge of the inversion requirement to speedup the search, but I was unable to find a way to implement it without exceeding O(V^2) time. The idea is that you can use an addition-chain (like binary exponentiation) to decompose the shortest n-inversion path into two smaller paths, and rinse and repeat in a divide and conquer fashion. The issue is you would need to construct tables for the shortest i-inversion path from any two vertices, which would be O(V^2) entries per i, and O(V^2logn) overall. To construct each table, for every entry in the preceding table you'd need to append V other paths, so it'd be O(V^3logn) time overall. Maybe someone else will see a way to merge these two ideas into a O((logn)(E + Vlog(Vlogn))) time algorithm or something.
What is the fastest way (algorithm) to calculate the number of Hamilton paths in an extremely dense undirected simple graph (approximately 99.99% edges are connected)?
I was thinking of the following way :
First, calculate the number of Hamilton paths in the complete graph.
Remove one edge at a time, but I am not able to figure out how many paths would be reduced on removing an edge. Also how to prevent double counting while removing the edges ?
I came across a similar question on Math.SE but that was about Hamilton cycles and not paths, I hope that changes the question significantly. Also the answers were not quite clear, hence this post.
I don't think you can calculate the number of Hamilton paths without
actually generating the paths or considering each path individually
when counting. For special graphs -- like the complete graph -- this
is certainly possible but not in general.
You could generate all Hamilton paths in the complete graph and check
for each one if it uses a subset of the edges in your graph. Of course
you can speed things up by already pruning certain branches while
generating the Hamilton paths in the complete graph.
Since your graph is very large, this approach is certainly not
feasible. However, you can calculate the number of all paths in the
complete graph that contain one of the missing edges and then subtract
this number.
I don't think this is trivial. Some thoughts on it: Let's consider the
simplest case that only one edge is missing. We can describe a path
with a sequence of edges or nodes. Let's say your graph has n
nodes. There are n-1 possible positions of the missing edge in a
hamilton path through the complete graph. The edge may be traversed in
two directions and the nodes not adjacent to the edge can be traversed
in (n-2)! different orders. Hence we can subtract
2 * (n-1) * (n-2)! = 2 * (n-1)!
from the total number of hamilton paths through the complete graph to
obtain the desired result.
If exactly two edges are missing we cannot just subtract twice the
number because we are counting several paths twice, namely the paths
containing both edges. So we have to calculate this number and add it
again. But now it becomes complicated: It is important how the edges
are related. If they are adjacent, the number is smaller than it would
be otherwise. So in general you cannot just calculate the number of
hamilton paths containing k of of the missing edges but it is
important which edges you are considering and whether they are
adjacent or not.
But let's say you can calculate the number of paths through a certain
selection of edges (all permutations, directions of traversal and
positions in the paths). Let's further assume that k edges are
missing. You can calculate the number of paths including at least one
of the edges like this:
Calculate the number of paths through any of the k edges individually
and sum them up.
For each pair of edges you have counted the paths traversing the pair
twice, so subtract these paths again (consider each pair
individually).
Now consider the paths containing three of the edges. They have been
counted six times and subtracted three times (3 different pairs), so
you have to subtract them twice.
The paths containing four edges have to be subtracted 3 times (because
they are represented 4 times in the paths containing 3 edges). And so
on.
But again: You have to consider each combination of edges
individually. It is even possible that a certain set of edges is
incompatible because a certain node occurs three times. Also take into
account the directions in which the edges are traversed.
So there is no simple formula but if the number of missing edges is
really small, you can count the paths.
Is there a Tool or known algorithmic method, which could compute the shortest sequence to transmit an information between the knots of a graph - e.g. graph threeC ?
Example: threeC
Time 0: A=a; B=b; C=c; D=d
Time 1: A=abcd; B=b; C=c; D=d
Time 2: A=abcd; B=bacd; C=cabd; D=dabc
I've looked into petri-nets, it would have to be a coloured net with directed and multiple edges - I guess. However I am quite uncertain, if I am on the right track.
It would have to work for connected unlabelled Graphs up to 5 knots (there are 21 of those). I would like to know - better proof - the shortest way of distributing abcd amongst all 5 knots (for all of those 21 graphs).
So, is there an algorithm or field of research that fits to this problem?
Thank you for your help.
If I understand correctly the question is actually to find the shortest path to the vertex that is father from starting vertex. That would be exactly what Dijkstra would do very well. You basically only assign a start node for Dijkstra and let it run until it has visited all nodes.
Dijkstra would leave behind information required for output.
If output is single value telling the maximum shortest path you can simple keep track of distance and print the highest distance when algorithm terminates. If requirement is to output also paths then Dijkstra would need to store information which edges it used to travel from a vertices that resulted to the shortest path in other end of vertex (there could be multiple equal entrances to a vertex requiring all sources to have their edges marked as used for route if all paths are required for output.)
http://en.wikipedia.org/wiki/Dijkstra's_algorithm
Given a list of points, I'd like to find all "clusters" of N points. My definition of cluster is loose and can be adjusted to whatever allows an easiest solution: it could be N points within a certain size circle or N points that are all within a distance of each other or something else that makes sense. Heuristics are acceptable.
Where N=2, and we're just looking for all point pairs that are close together, it's pretty easy to do ~efficiently with a k-d tree (e.g. recursively break the space into octants or something, where each area is a different branch on the tree and then for each point, compare it to other points with the same parent (if near the edge of an area, check up the appropriate number of levels as well)). I recognize that inductively with a solution for N=N', I can find solution for N=N'+1 by taking the intersections between different N' solutions, but that's super inefficient.
Anyone know a decent way to go about this?
You start by calculating the Euclidean minimum spanning tree, e.g CGAL can do this. From there the precise algorithm depends on your specific requirements, but it goes roughly like this: You sort the edges in that graph by length. Then delete edges, starting with the longest one. It's a singly connected graph, so with each deleted edge you split the graph into two sub-graphs. Check each created sub-graph if it forms a cluster according to your conditions. If not, continue deleting edges.
I have an graph with the following attributes:
Undirected
Not weighted
Each vertex has a minimum of 2 and maximum of 6 edges connected to it.
Vertex count will be < 100
Graph is static and no vertices/edges can be added/removed or edited.
I'm looking for paths between a random subset of the vertices (at least 2). The paths should simple paths that only go through any vertex once.
My end goal is to have a set of routes so that you can start at one of the subset vertices and reach any of the other subset vertices. Its not necessary to pass through all the subset nodes when following a route.
All of the algorithms I've found (Dijkstra,Depth first search etc.) seem to be dealing with paths between two vertices and shortest paths.
Is there a known algorithm that will give me all the paths (I suppose these are subgraphs) that connect these subset of vertices?
edit:
I've created a (warning! programmer art) animated gif to illustrate what i'm trying to achieve: http://imgur.com/mGVlX.gif
There are two stages pre-process and runtime.
pre-process
I have a graph and a subset of the vertices (blue nodes)
I generate all the possible routes that connect all the blue nodes
runtime
I can start at any blue node select any of the generated routes and travel along it to reach my destination blue node.
So my task is more about creating all of the subgraphs (routes) that connect all blue nodes, rather than creating a path from A->B.
There are so many ways to approach this and in order not confuse things, here's a separate answer that's addressing the description of your core problem:
Finding ALL possible subgraphs that connect your blue vertices is probably overkill if you're only going to use one at a time anyway. I would rather use an algorithm that finds a single one, but randomly (so not any shortest path algorithm or such, since it will always be the same).
If you want to save one of these subgraphs, you simply have to save the seed you used for the random number generator and you'll be able to produce the same subgraph again.
Also, if you really want to find a bunch of subgraphs, a randomized algorithm is still a good choice since you can run it several times with different seeds.
The only real downside is that you will never know if you've found every single one of the possible subgraphs, but it doesn't really sound like that's a requirement for your application.
So, on to the algorithm: Depending on the properties of your graph(s), the optimal algorithm might vary, but you could always start of with a simple random walk, starting from one blue node, walking to another blue one (while making sure you're not walking in your own old footsteps). Then choose a random node on that path and start walking to the next blue from there, and so on.
For certain graphs, this has very bad worst-case complexity but might suffice for your case. There are of course more intelligent ways to find random paths, but I'd start out easy and see if it's good enough. As they say, premature optimization is evil ;)
A simple breadth-first search will give you the shortest paths from one source vertex to all other vertices. So you can perform a BFS starting from each vertex in the subset you're interested in, to get the distances to all other vertices.
Note that in some places, BFS will be described as giving the path between a pair of vertices, but this is not necessary: You can keep running it until it has visited all nodes in the graph.
This algorithm is similar to Johnson's algorithm, but greatly simplified thanks to the fact that your graph is unweighted.
Time complexity: Since there is a constant number of edges per vertex, each BFS will take O(n), and the total will take O(kn), where n is the number of vertices and k is the size of the subset. As a comparison, the Floyd-Warshall algorithm will take O(n^3).
What you're searching for is (if I understand it correctly) not really all paths, but rather all spanning trees. Read the wikipedia article about spanning trees here to determine if those are what you're looking for. If it is, there is a paper you would probably want to read:
Gabow, Harold N.; Myers, Eugene W. (1978). "Finding All Spanning Trees of Directed and Undirected Graphs". SIAM J. Comput. 7 (280).