I need to split an undirected graph into minimum number of subpaths (vertices can be repeated, but not edges).
Is there any algorithm? How can it be implemented?
For example, for the given graph below, it could be:
BACI, CDEGFC
or BACDEGFC, CI
Let's say your graph is connected and has k vertices of odd degree. Then the answer is the max of k/2 and 1. If your graph isn't connected then the same applies to each connected component.
Let's first take the case where there are no vertices of odd degree. Start at any vertex, and keep proceeding to an arbitrary neighbor (along an unused edge) until you get back to the starting vertex. You know you can leave any vertex you can reach because they all have even degree.
If this uses up all edges then you're done. If not, pick a vertex adjacent to an unused edge and repeat. Keep doing this. When done you'll have a number of cycles, say r, and each one will share at least one vertex with another cycle. Next, merge adjacent cycles in the natural way. E.g. in a very simple case we have two triangles that share a vertex: abc and cde, and we finish our procedure with these two small cycles: abca and cdec. We merge these where the meet: abcdeca
a---b
\ /
c
/ \
d---e
Now, the issue with vertices of odd degree is that any trail will use up 2 edges adjacent to each vertex in it except the start and end (if different) where it only uses 1. That means that if there are odd vertices, there will be a separate trail for each pair of the same. You can apply the same procedure as before, but always start at an odd-degree vertex. You'll be forced to end at an odd-degree vertex. Merge where you can, but you'll always end up with one trail per pair of odd vertices.
Related
Consider the following directed graph. For a given n, the vertices of the graph correspond to the
integers 1 through n. There is a directed edge from vertex i to vertex j if i divides j.
Draw the graph for n = 12. Perform a DFS of the above graph with n = 12. Record the discovery
and finish times of each vertex according to your DFS and classify all the edges of the graph into tree, back, forward, and cross edges. You can pick any start vertex (vertices) and any order of visiting the vertices.
I do not see how it is possible to traverse this graph because of the included stipulations. It is not possible to get a back edge because a dividing a smaller number by a larger number does not produce an integer and will never be valid.
Say we go by this logic and create a directed graph with the given instructions. Vertex 1 is able to travel to vertex 2, because 2 / 1 is a whole number. However, it is impossible to get to vertex 3 as vertex 2 can only travel to vertex 4, 6, 8, or 10. Since you cannot divide by a bigger number it will never be possible to visit a lower vertex once taking one of these paths and therefore not possible to reach vertex 3.
Your assumption about the back tracks is correct. You cannot have back tracks because you don't have any circles. Consider the following example:
When we start at 2 we will find the edges 2->4, 4->8, 4->12, 2->6 and 2->10. The edges 2->8 and 2->12 are forward edges, they are like shortcuts to get forward much faster. The edge 6->12 is a cross edge because you are switching from one branch to another branch. And since we have no circles to somehow get back to a previous node, we don't have any backward edges.
I've received a task to find an algorithm which divides a graph G(V,E) into pairs of neighboring edges (colors the graph, such that every pair of neighboring edges has the same color).
I've tried to tackle this problem by drawing out some random graphs and came to a few conclusions:
If a vertex is connected to 2(4,6,8...) vertices of degree 1, these make a pair of edges.
If a vertex of degree 1 is directly connected to a cycle, it doesn't matter which edge of the cycle is paired with the lone edge.
However, I couldn't come up with any other conclusions, so I tried a different approach. I thought about using DFS, finding articulation points and dividing graph into subgraphs with an even number of edges, because those should be dividable by this rule as well, and so on until I end up with only subgraphs of |E(G')| = 2.
Another thing I've come up with is to create a graph G', where E(G) = V(G') and V(G) = E(G'). That way I could get a graph, where I could remove pairs of vertices (former edges) either via DFS or always starting with leaf vertices along with their adjacent vertices.
The last technique is most appealing to me, but it seems to be the slowest one. Any feedback or tips on which of these methods would be the best is much appreciated.
EDIT: In other words, imagine the graph as a layout of a town. Vertices being crossroads, edges being the roads. We want to decorate (sweep, color) each road exactly once, but we can only decorate two connected roads at the same time. I hope this helps for clarification.
For example, having graph G with E={ab,bd,cd,ac,ae,be,bf,fd}, one of possible pair combinations is P={{ab,bf},{ac,cd},{ae,eb},{bd,df}}.
One approach is to construct a new graph G where:
A vertex in G corresponds to an edge in the original graph
An edge in G connects vertices a and b in G where a and b represent edges in the original graph that meet at a vertex in the original graph
Then, if I have understood the original problem correctly, the objective for G is to find the maximum matching, which can be done, for example, with the Blossom algorithm.
I would like to list all the cycles in an undirected multigraph.
Tarjan's strongly connected components algorithm was written for a directed graph. Will it work for multigraphs? If not, is there an cycle listing algorithm for undirected multigraphs?
There are a few ways to reduce your problem to Tarjan, depending on how you want to count cycles.
First, apply two transformations to your graph:
Convert to a directed graph by replacing each undirected edge with a pair of opposing directed edges.
For each pair of nodes, collapse edges pointing the same direction into a single edge.
You'll be left with a directed graph. Apply Tarjan's algorithm.
Now, depending on what you consider a cycle, you may or may not be done. If a cycle is set of nodes (that happen to posses the required edges), then you can read the cycles directly off the transformed graph.
If a cycle is a set of edges (sharing the required nodes), then you need to "uncollapse" the edges introduced in step 2 above. For each collapsed edge, enumerate along the set of real edges it replaced. Doing so for each edge in each collapsed cycle will yield all actual cycles in a combinatorial explosion. Note that this will generate spurious two-cycles which you'll need to prune.
To illustrate, suppose the original graph has three nodes A, B and C, with two edges between A and B, one between B and C and one between A and C. The collapsed graph will be a triangle, with one cycle.
Having found a cycle between the three nodes, walk each combination of edges to recover the full set of cycles. Here, there are two cycles: both include the A to C and B to C edges. They differ in which A to B edge they choose.
If the original graph also had two edges between B and C, then there would be four expanded graphs. The total number of expanded cycles is the product of the edge counts: 4 == 2 * 2 * 1.
We are given N pairs. Each pair contains two numbers. We have to find maximum number K such that if we take any combination of J (1<=J<=K) pairs from the given N pairs, we have at least J different numbers in all those selected J pairs. We can have more than one pair same.
For example, consider the pairs
(1,2)
(1,2)
(1,2)
(7,8)
(9,10)
For this case K = 2, because for K > 2, if we select three pairs of (1,2), we have only two different numbers i.e 1 and 2.
Checking for each possible combination starting from one will take a very large amount of time. What would be an efficient algorithm for solving the problem?
Create a graph with one vertex for each number and one edge for each pair.
If this graph is a chain or a tree, we have the number of "numbers", equal to number of "pairs" plus one, After removing any number of edges from this graph, we never get less vertexes than edges.
Now add a single cycle to this chain/tree. There is equal number of vertexes and edges. After removing any number of edges from this graph, again we never get less vertexes than edges.
Now add any number of disconnected components, each should not contain more than one cycle. Once again, we never get less vertexes than edges after removing any number of edges.
Now add a second cycle to any of disconnected components. After removing all other components. at last we have more edges than vertexes (more pairs than numbers).
All this leads to the conclusion that K+1 is exactly the number of edges in the smallest possible subgraph, consisting of two cycles and, possibly, a chain, connecting these cycles.
Algorithm:
For each connected component, find the shortest cycle going through every node with Floyd-Warshall algorithm.
Then for each non-overlapping pair of cycles (in single component), use Dijkstra’s algorithm, starting from any node with at least 3 edges in one cycle, to find shortest path to other cycle; and compute a sum of lengths of both cycles and a shortest path, connecting them. For each overlapping pair of cycles, just compute the number of their edges.
Now find the minimum length of all these subgraphs. And subtract 1.
The above algorithm computes K if there is at least one double-cycle component in the graph. If there are no such components, K = N.
Seems related to MinCut/MaxFlow. Here is a try to reduce it to MinCut/MaxFlow:
- Produce one vertex for each number
- Produce one vertex for each pair
- Produce an edge from number i to a pair if the number is present in the pair, weight 1
- Produce a source node and connect it to all numbers, weight 1 for each connection
- Produce a sink node and connect it to all numbers, weight 1 for each connection
Running MaxFlow on this should give you the number K, since any set of three pairs which only contains two numbers in total, will be "blocked" by the constrains on the outgoing edges from the number.
I am not sure whether this is the fastest solution. There might also be a matroid hidden in there somewhere, I think. In that case there is a greedy approach. But I cannot find a proof for the matroid properties of the sets you are constructing.
I made some progress on it, but not yet an efficient solution. However it may point the way.
Make a graph whose points are pairs, and connect any pair of points if they share a number. Then for any subgraph, the number of numbers in it is the number of vertices minus the number of edges. Therefore your problem is the same as locating the smallest subgraph (if any) that has more edges than vertices.
A minimal subgraph that has the same number of edges and vertices is a cycle. Therefore the graphs we're looking for are either 2 cycles that share one or more vertices, or else 2 cycles which are connected by a path. There are no other minimal types possible.
You can locate and enumerate cycles fairly easily with a breadth-first search. There may be a lot of them, but this is doable. Armed with that you can look for subgraphs of these subtypes. (Enumerate minimal cycles, look for either pairs that share points, or which are connected.) But that isn't guaranteed to be polynomial. I suspect it will be something where on average it is pretty good, but the worst case is very bad. However that may be more efficient than what you're doing now.
I keep on thinking that some kind of breadth-first search can find these in polynomial time, but I keep failing to see exactly how to do it.
This is equivalent to finding the chord that chords the smallest cycle in the graph. A very naive algorithm would be:
Check if removal of an edge results in a cycle containing the vertices corresponding to the edge. If yes, then note down the length of the smallest cycle.
I have an undirected graph with all vertices of even degree. In this graph there is a set of edges that must be covered exactly once, and a set of edges that should not be covered at all unless absolutely necessary. I need to find a set of one or more paths through the graph such that all of the required edges are covered exactly once, and the number of undesired edges traversed is minimized. No required edge can be traversed by more than one path, but the undesired edges can be traversed by any number of paths. It is not quite a Eulerian path because there are optional edges.
Each individual path's length is limited by a maximum number of required edges it can cover, although a path can cover any number of undesired edges.
The starting points and ending points need not be the same, but there is a set of possible starting points.
Some of the undesired edges are coincident with the required edges -- that is, a pair of vertices might have both a required edge and an undesired edge between them (although there will never be more than one edge of each type between a given pair of vertices).
What's a good algorithm to start with? Fundamentally, I am looking for an algorithm that can find a path that traverses required edges exactly once and avoids undesired edges when possible (but can traverse them more than once if necessary). I can build on that to do the rest.
You are looking for a subgraph within the original graph, such that it contains all the required edges, with a minimum of undesired edges such that it contains an Eulerian path.
It is known that a graph contains an Eulerian path if and only if it is CONNECTED and has all vertices ( except 2 ) of EVEN DEGREE. This can be ensured by doing the following :
Start by directly including all the desired edges in the final subgraph. You now have a graph with one or more connected components.
CASE 1 :
If the number of components in this subgraph is one, (i.e, all the edges are connected to each other ), we only have to ensure that all vertices ( except 2 ) have even degree. Since your original graph does have all vertices of even degree, it is possible to do this, but we also want to take care that the number of edges we add to achieve this is minimum ( since only undesired edges are left to add ).
One good heuristic way to do this, start from each of the odd degree vertices, and do a BFS ( breadth first search ) till you reach another vertex with odd degree. Do this for all the odd degree vertices, choose the 2 vertices which take the maximum undesired path between them to achieve this, and delete this path. Now the graph will have an Eulerian Path
( One thing to note is that such a pairing of odd vertices is always possible, since no graph can have an odd number of vertices of odd degree )
CASE 2 :
The subgraph consisting of only desired edges has more than one component. To ensure connectivity, do the following - Take the component with the minimum number of vertices. Do a BFS from each of the vertices, and choose the minimum length path that connects this component to ANY OTHER component.
Repeat this procedure till all components merge to form a single component. Now for even-ness follow the procedure outlined before for CASE 1.
I think this can be reduced into the Travelling Salesman problem. Create a transformed graph where the nodes represent compulsory edges and the edge weights represent the number of optional edges that must be traversed to get from one compulsory edge to the other.
Now the problem is to find the shortest path in this transformed graph which goes through all the nodes (aka compulsory edges). This is the TSP, which is NP-hard.
There will be some complications because the paths you can take after a compulsory edge depend on the direction in which you took it. You could solve this by turning each compulsory edge into two nodes, one for each direction. The TSP would then have to visit exactly one node from every pair.
e.g.
A===C
| /
| / (edges A<->B and B<->C are compulsory, A<=>C is optional)
|/
B
Transformed graph:
Nodes = { AB, BA, BC, CB }
Edges = { AB -> BC (cost 0), BA -> CB (cost 1), CB -> BA (cost 0), BC -> AB (cost 1) }
This is NP-hard: an instance of the Hamiltonian path problem can be transformed to an instance of your problem. Therefore, if you know how to solve your problem, you know how to solve the Hamiltonian path problem.
To transform, take a directed graph and double each vertex, say, into a red and a blue vertex. For each former vertex, make all inbound edges go to the red vertex, and all outbound edges go out of the blue vertex. Make a single new edge from the red to the blue vertex. Obviously if you can solve the Hamiltonian cycle problem for this graph, you can do so for the original graph.
Now label all new edges compulsory, all the old edges as optional. Mark a single red vertex as a possible entry point. If there's a solution to your problem, then it consists of a single path, which a Hamiltonian path for the original graph.