Are there any algorithms to convert single line traces to graphs?
Example.
I have traces of events as they occur.
T1: A -> B -> C-> D
T2: A'-> X -> B' -> D'
T3: A"-> C" -> F" -> D"
I want to take these and create a graph structure. I have some way of establishing equivalence between A, A', A" and so on.
Is there a standardized algorithm to convert from the traces above to a graph?
I can think of an intuitive one which creates nodes for all events and add edges that are present in the traces but want to know if there is something better or my algorithm has a name.
Thanks
You just have to design the implementation of your graph, if it is static (ie you do get all the traces at the same time) or dynamic (you get the traces incrementally, in an online fashion, so that you need to update your graph at each time).
There is no particular algorithm as far as I remember; you just have, in first case, to collect all the nodes looping through all the traces and then add all the edges. In the second case you can add nodes incrementally to your structure (checking whether or not you've already seen the same node twice) as you add edges to them (it doesn't show from your examples but even edges can be repeated I guess).
Related
I know that one can detect cycles in direct graphs using DFS and BFS. I want to know whether we can detect cycles in directed graphs using Union-Find or not?
If yes, then how? and
If we can't, then why?
No, we cannot use union-find to detect cycles in a directed graph. This is because a directed graph cannot be represented using the disjoint-set(the data structure on which union-find is performed).
When we say 'a union b' we cannot make out the direction of edge
is a going to b? (or)
is b going to a?
But, incase of unordered graphs, each connected component is equivalent to a set. So union-find can be used to detect a cycle. Whenever you try to perform union on two vertices belonging to the same connected component, we can say that cycle exists.
No.
Let me give you an example:
Q1. Take an undirected graph:
Is there a cycle in above undirected graph? Yes. And we can find the cycle using Union-Find algo.
Q2. Now look at the similar directed graph:
Is there a cycle in above directed graph? No!
BUT if you use Union-Find algo to detect cycle in above directed graph, it will say YES! Since union-find algo looks at the above diagram as below:
OR
Is there a cycle in above diagram? Yes! But the original(Q2) question was tampered and this is not what was asked. So Union-find algo will give wrong results for directed graphs.
No, we cannot use union-find to detect cycles in a directed graph.
This is because a directed graph cannot be represented using the
disjoint-set(the data structure on which union-find is performed).
When we say 'a union b' we cannot make out the direction of edge
is a going to b? (or) is b going to a? But, incase of unordered
graphs, each connected component is equivalent to a set. So union-find
can be used to detect a cycle. Whenever you try to perform union on
two vertices belonging to the same connected component, we can say
that cycle exists.
Just wanted to add to #Cherubim's answer, I just thought of this question that why can't we make out the direction of 'a union b' like we can consider it as a is connected to b right ('a union b' only nodes which are a->b)?
Well that will also fail, consider two nodes x and y, they are connected x -> y and they already have parents in the disjoint set, x_root and y_root.
So what happens when we say 'x union y' (x is connected to y), we make y_root the parent of x_root. well this tells us that:
x_root -> y_root (could be opposite too)
x_root and y_root are connected. (they could be disconnected)
So the main problem beside ambiguous direction, is also that not every node in a directed graph is connected to each other.
I am currently working on Julia with the MetaGraphs.jl package.
I have created the Graph with a dataset, the characteristic of the graph is that there's one start vertex and one end vertex. However the graph is created by creating all possible options so some edges which "take too much time" don't reach the final vertex. In order to have a decent graph for my next step/ an optimization problem.
I am cleaning the graph by simply going through all edges and those who don't reach the end vertex are deleted. But this method is costly in time and I know a wiser way to do it.
The method is simple:
1.reversing the graph (end vertex becomes start vertex)
2.Calculating the distance of all vertices from the start vertex
3.erase the vertices which don't have a defined distance with the start vertex
I have created an example of a small digraph that would be the same type as mine:
module EssaiModule
using LightGraphs, MetaGraphs
g = DiGraph(8)
mg = MetaDiGraph(g, 1.0)
add_vertex!(mg)
add_edge!(mg,1,2)
add_edge!(mg,1,3)
add_edge!(mg,1,4)
add_edge!(mg,2,4)
add_edge!(mg,2,5)
add_edge!(mg,3,5)
add_edge!(mg,5,6)
add_edge!(mg,4,6)
add_edge!(mg,3,7)
add_edge!(mg,4,8)
rg=reverse(mg)
end
the end vertex is number 6 so normally I would like to erase edges 3->7 and 4->8
But I can't even start my function because I simply cannot reverse this graph.
I get the error message "LoadError: type MetaDiGraph has no field badjlist"
I know it's because the graph is a metaGraph and not a lightGraph but shouldn't we be able to reverse a metagraph? it seems like a basic function that could be useful on many occasions while working with graphs.
Thanks for your help!
Heyo!
So I've got this directed and/or undirected graph with a bunch of vertices and edges. In this graph there is a start vertex and an end vertex. There's also a subset of vertices which are coloured red (this subset can include the start and end vertices). Also, no pair of vertices can have more than one edge between them.
What I have to do is to find:
A) The shortest path that passes no red vertices
B) If there is a path that passes at least one red vertex
C) The path with the greatest amount of red vertices
D) The path with the fewest amount of red vertices
For A I use a breadth first search ignoring red branches. For B I simply brute force it with a depth first search of the graph. And for C and D I use dynamic programming, memoizing the number of red vertices I find in all paths, using the same DFS as in B.
I am moderately happy with all the solutions and I would very much appreciate any suggestions! Thanks!!
For A I use a breadth first search ignoring red branches
A) is a Typical pathfinding problem happening in the sub-graph that contains no red edges. So your solution is good (could be improved with heuristics if you can come up with one, then use A*)
For B I simply brute force it with a depth first search of the graph
Well here's the thing. Every optimal path A->C can be split at an arbitrary intermediate point B. A Nice property of optimal paths, is that every sub-path is optimal. So A->B and B->C are optimal.
This means if you know you must travel from some start to some end through an intermediary red vertex, you can do the following:
Perform a BFS from the start vertex
Perform a BFS from the endvertex backwards (If your edges are directed - as I think - you'll have to take them in reverse, here)
Alternate expanding both BFS so that both their 'edge' (or open lists, as they are called) have the same distance to their respective start.
Stop when:
One BFS hits a red vertex encountered by (or in the 'closed' list of) the other one. In this case, Each BFS can construct the optimal path to that commen vertex. Stitch both semi-paths, and you have your optimal path with at least a red vertex.
One BFS is stuck ('open' list is empty). In this case, there is no solution.
C) The path with the greatest amount of red vertices
This is a combinatorial problem. the first thing I would do is make a matrix of reachability of [start node + red nodes + end nodes] where:
reachability[i, j] = 1 iff there is a path from node i to node j
To compute this matrix, simply perform one BFS search starting at the start node and at every red node. If the BFS reaches a red node, put a 1 in the corresponding line/column.
This will abstract away the underlying complexity of the graph, and make an order of magnitude speedup on the combinatorial search.
The problem is now a longest path problem through that connectivity matrix. dynamic programming would be the way to go indeed.
D) The path with the fewest amount of red vertices
Simply perform a Dijkstra search, but use the following metric when sorting the nodes in the 'open' list:
dist(start, a) < dist(start, b) if:
numRedNodesInPath(start -> a) < numRedNodesInPath(start -> b)
OR (
numRedNodesInPath(start -> a) == numRedNodesInPath(start -> b)
AND
numNodesInPath(start -> a) < numNodesInPath(start -> a)
)
For this, when discovering new vertices, you'll have to store the path leading up to them (well, just the nb of nodes in the path, as well as the nb of red nodes, separately) in a dedicated map to be fetched. I mention this because usually, the length of the path is stored implicitly as the position of the verrtex in the array. You'll have to enforce it explicitely in your case.
Note on length optimality:
Even though you stated you did not care about length optimality outside of problem A), the algorithm I provided will produce shortest-length solutions. In many cases (like in D) it helps Dijkstra converge better I believe.
I know a graph is considered cylic if it has at least one cycle. However, I can't seem to find an answer to the question if its only cylic in one direction. This graph is cylic from
(A -> C -> B -> E)
However this doesn't work in the opposite direction
(E -> B -> C -/> A)
So is this graph still considered cylic? I believe it would be, but I just can't find confirmation of this.
Yes, a directed graph is cyclic if and only if it contains at least one directed cycle. A (simple) directed cycle is a list of arcs such that (1) each vertex is the head of at most one arc in the list (2) the head of each arc in the list is the tail of the next arc in the list, wrapping around to the beginning if it's at the end. You can chase references from Wikipedia if you won't take it on my authority as a CS PhD specialized in graph algorithms: https://en.wikipedia.org/wiki/Cycle_(graph_theory).
I have a question regarding the maximum flow in a network. I was trying to find a cut set in a graph that could disconnect the source and the destination. I explored all the edge independent paths in the graph from a source to the destination. Next I picked an edge from each of these paths and grouped them together. So basically I enumerated all the possible combinations of taking one edge from each path.
So I have a set of such groups. Does this mean that I have eventually found the cut sets of the network for that particular source and destination? Is this an efficient method?
This sounds like it has exponential complexity. I can't say exactly, because I don't know what "all the edge independent paths" means. For example:
A
|
B
/ \
C D
\ /
E
There are two paths from A to E, but they're not edge independent.
A maximum flow on a graph is dual to a minimum cut, and there are plenty of standard algorithms that can find one in (small) polynomial time. If you're satisfied with any cut at all, just remove all the edges -- this runs in time O(E).
What are your constraints?