I am having a hard time figuring out this problem.
The problem is: We have a circular undirected graph G. We start at some node, and then take circular paths throughout the graph to arrive back at the starting node. We want to know if there is some list of k nodes inside the graph that must always be taken for every path in the graph. The problem is pretty much, do these k nodes exist?
I need to prove that this problem is in NP. However, not too sure how to do this.
To prove it's in NP, I need to be able to verify the solution. However, I'm not even sure how to start with the problem itself as I haven't seen something similar to this before. Could anyone lend some advice? Does anyone know an equivalent problem to this that could help with the verification?
For example, for starting node s, we always need to traverse b. So the set k = {b}
Input: Undirected graph G = (V, E), integer k.
Question: Is there a set S of k vertices such that every cycle in the graph includes at least one
vertex of S?
A verifier algorithm can't simply take a set S of k nodes and enumerate every cycle in the graph to check if it contains at least one vertex in S. There may be exponentially many cycles in the graph, and the verifier algorithm needs to run in polynomial time. It needs to be smarter than this.
To verify a problem is in NP (Not NPC), you need to get the input of the problem, and a polynomial size verification input - and using it, determine if the answer to the decision problem of the original input is true or false, in Polynomial time (This is equivalent definition to using Non-deterministic turing machine).
In your case, the input to the problem is G=(V,E), and some integer k.
The verifying string will be a set S with the candidate set of nodes.
Now, given these inputs - first check |S| = k, and then create G' = (V', E'), where:
V' = V\S
E' = { (u,v) | (u,v) in E and u in V' and v in V' }
Now, do a DFS form each of the nodes in V'. DFS takes polynomial time, and you need to do it polynomial number of times - so still polynomial time complexity. You are searching if there is a cycle in V' (reaching the same node you started from).
If you find such, the answer to the problem is true (there is such set of size k).
Otherwise, it's false (there isn't such set).
Related
Let us say that we have an undirected graph, where each edge has a real number value. Let us define the "sum" of a cycle as the sum of the values of each edge in that cycle.
Is there a reasonably fast way to check if there exists a cycle within the graph containing a certain edge E where the sum is greater than/smaller than 0? Right now my (extremely crude and horribly inefficient) solution is to check for every cycle the edge is in.
The algorithm does not need to find an exact cycle, it only needs to check for existence of such a cycle.
Assuming you allow only simple cycles, no, there is no efficient algorithm to do so, as it will let us solve Hamiltonian Path Problem efficiently. (In other words, this problem is NP-Hard).
Reduction:
(We will use a variant of your problem where we find if there is such simple cycle with weight greater/equals zero).
Given a graph G=(V,E), build a new graph:
G' = (V',E')
V' = V U {s,t}
E' = E U { (s,v), (v,t), (s,t) }
And add weights to the graph:
w(s,t) = -|V'| + 1
w(u,v) = 1 for u!=s and v!= t
Intuitively, we add a "source" and "target" nodes, connect them to all other nodes, and make the two nodes connected with negative weight of all paths.
The reduction is sending (G', (s,t)) to the new algorithm.
Now, if the original graph has hamiltonian path v1->v2->...->vn, then the new graph has a cycle s->v1->v2->...->vn->t->s, which sums to 0, and is a simple cycle.
If there is a simple cycle in G' that uses (s,t), and sums to any number greater than 0, then it means total weights of all other edges except (s,t) used is at least |V'|-1.
From the construction, that means there are exactly |V'| nodes in this cycle, which is the entire graph, so we know the cycle is: s->t->v1->v2->...->vn->s, and since this is simple, v1,v2,...,vn are all the nodes in the original V, which means there is a Hamiltonian Path v1->v2->...->vn.
Conclusion: We have shown a polynomial time reduction from Hamiltionian Path to your problem, and since HP is NP-Hard, this problem also is.
I'm quite surprised I couldn't find anything on this anywhere, it seems to be a problem that should be quite well known:
Consider the Euclidean shortest path problem, in two dimensions. Given a set of obstacle polygons P and two points a and b, we want to find the shortest path from a to b not intersecting the (interior of) any p in P.
To solve this, one can create the visibility graph for this problem, the graph whose nodes are the vertices of the elements of P, and where two nodes are connected if the straight line between them does not intersect any element of P. The edge weight for any such edge is simply the Euclidean distance between such two points. To solve this, one can then determine the shortest path from a to b in the graph, let's say with A*.
However, this is not a good approach. Creating the visibility graph in advance requires checking if any two vertices from any two polygons are connected, a check that has higher complexity than determining the distance between two nodes. So working with a modified version of A* that "does everything what it can before checking if two nodes are actually connected" actually speeds up the problem.
Still, A* and all other shortest path problems always start with an explicitly given graph for which adjacent vertices can be traversed cheaply. So my question is, is there a good (optimal?) algorithm for finding a shortest path between two nodes a and b in an "implicit graph" that minimizes checking if two nodes are connected?
Edit:
To clarify what I mean, this is an example of what I'm looking for:
Let V be a set, a, b elements of V. Suppose w: V x V -> D is a weighing function (to some linearly ordered set D) and c: V x V -> {true, false} returns true iff two elements of V are considered to be connected. Then the following algorithm finds the shortest path from a to b in V, i.e., returns a list [x_i | i < n] such that x_0 = a, x_{n-1} = b, and c(x_i, x_{i+1}) = true for all i < n - 1.
Let (V, E) be the complete graph with vertex set V.
do
Compute shortest path from a to b in (V, E) and put it in P = [p_0, ..., p_{n-1}]
if P = empty (there is no shortest path), return NoShortestPath
Let all_good = true
for i = 0 ... n - 2 do
if c(p_i, p_{i+1}) == false, remove edge (p_i, p_{i+1}) from E, set all_good = false and exit for loop
while all_good = false
For computing the shortest paths in the loop, one could use A* if an appropriate heuristic exists. Obviously this algorithm produces a shortest path from a to b.
Also, I suppose this algorithm is somehow optimal in calling c as rarely as possible. For its found shortest path, it must have ruled out all shorter paths that the function w would have allowed for.
But surely there is a better way?
Edit 2:
So I found a solution that works relatively well for what I'm trying to do: Using A*, when relaxing a node, instead of going through the neighbors and adding them to / updating them in the priority queue, I put all vertices into the priority queue, marked as hypothetical, together with hypothetical f and g values and the hypothetical parent. Then, when picking the next element from the priority queue, I check if the node's connection to its parent is actually given. If so, the node is progressed as normal, if not, it is discarded.
This greatly reduces the number of connectivity checks and improves performance for me a lot. But I'm sure there's still a more elegant way, in particular one where the "hypothetical new path" doesn't just extend by length one (parents are always actual, not hypothetical).
A* or Dijkstra's algorithm do not need an explicit graph to work, they actually only need:
source vertex (s)
A function next:V->2^V such that next(v)={u | there is an edge from v to u }
A function isGoal:V->{0,1} such that isGoal(v) = 1 iff v is a target node.
A weight function w:E->R such that w(u,v)= cost to move from u to v
And, of course, in addition A* is going to need a heuristic function h:V->R such that h(v) is the cost approximation.
With these functions, you can generate only the portion of the graph that is needed to find shortest path, on the fly.
In fact, A* algorithm is often used on infinite graphs (or huge graphs that do not fit in any existing storage) in artificial inteliigence problems using this approach.
The idea is, you only look on edges in A* from a given node (all (u,v) in E for some given u). You don't need the entire edges set E in order to do it, you can just use your next(u) function instead.
I was asked for my homework to write an efficient algorithm that finds all the vertices in a directed graph which have even length of path to them from the given vertex.
This is what I thought of:
(It's very similar to "Visit" algorithm of DFS)
Visit(vertex u)
color[u]<-gray
for each v E adj[u]
for each w E adj[v]
if color[w] = white then
print w
Visit(w)
I think it works but I'm having hard time calculating it's efficiency, especially when the graph is with cycles. Could you help me?
If I may suggest an alternative - I would have reduced the problem and use DFS instead of modifying DFS.
Given a graph G = (V,E), cretae a graph G' = (V,E') where E'={(u,v) | there is w in V such that (u,w) and (w,v) are in E)
In other words - we are creating a graph G', which has edge (u,v) if and only if there is a path of length 2 from u to v.
Given that graph, we can derive the following algorithm [high level pseudo-code]:
Create G' from G
run DFS on G' from the source s, and mark the same nodes DFS marked.
Correctness and time complexity analysis of the solution:
Complexity:
The complexity is obviously O(min{|V|^2,|E|^2} + |V|), because of part 1 - since there are at most min{|E|^2,|V|^2} edges in G', so DFS on step 2 runs in O(|E'| + |V|) = O(min{|V|^2,|E|^2} + |V|)
Correctness:
If the algorithm found that there is a path from v0 to vk, then from the correctness of DFS - there is a path v0->v1->...->vk on G', so there is a path v0->v0'->v1->v1'->...->vk of even length on G.
If there is a path of even length on G from v0 to vk, let it be v0->v1->...->vk. then v0->v2->...->vk is a path on G', and will be found by DFS - from the correctness of DFS.
As a side note:
Reducing problems instead of modifying algorithms is usually less vulnurable to bugs, and easier to analyze and prove correctness on, so you should usually prefer these over modifying algorithms when possible.
EDIT: regarding your solution: Well, analysing it shows they are both pretty much identical - with the exception of I was generating E' as pre-processing, and you are generating it on the fly, in each iteration.
Since your solution is generating the edges on the fly - it might to doing some work more then once. However, it is bounded to the job at most |V| times more, since each vertex is being visited at most once.
Assuming |E| = O(|V|^2) for simplicity, giving us total an upper bound for the run time of O(|V|^3) for your solution.
It is also a lower bound, look at the example of a clique, During each visit() of any node, the algorithm will do O(|V|^2) to generate all possibilities, and visit() one of the possibilities, since we visit exactly |V| nodes, we get total run time of Omega(|V|^3)
Since we found the solution is both O(|V|^3) and Omega(|V|^3), it is total of Theta(O(|V|^3))
For each undirected graph G(V,E) we should rebuilt the mentioned graph to be bipartite graph G'(V',E') when:
V' = V1 ∪ V2
E'={(u1,v2):(u,v)∈E, u1∈V1, v2∈V2}
V1={v1: v∈V}
V2={v2: v∈V}
For example the graph
becomes
On this graph (bipartite graph) we should run BFS algorithm - BFS(G',S1').
After running BFS(G',S1') we should return array d that contains length of shortest even path δ(s1,u1)
I believe that the Hamiltonian cycle problem can be summed up as the following:
Given an undirected graph G = (V, E), a
Hamiltonian circuit is a tour in G passing through
every vertex of G once and only once.
Now, what I would like to do is reduce my problem to this. My problem is:
Given a weighted undirected graph G, integer k, and vertices u, v
both in G, is there a simple path in G from u to v
with total weight of AT LEAST k?
So knowing that the Hamiltonian cycle problem is NP-complete, by reducing this problem to the Hamiltonian, this problem is also proved NP-complete. My issue is the function reducing it to Hamiltonian.
The big issue is that the Hamiltonian problem does not deal with edge weights, so I must convert my graph to one that doesn't have any weights.
On top of that, this problem has a designated start and finish (u and v), whereas the Hamiltonian finds a cycle, so any start is the same as the finish.
For (1), I am thinking along the lines of passing a graph with all simple paths of total weight LESS THAN k taken out.
For (2), I am thinking that this is not really an issue, because if there is a Hamiltonian cycle, then the simple path from u to v can be sliced out of it.
So, my real questions are:
Is my solution going to give me the right answer?
If yes, then how can I take out the edges that will produce simple paths of total weight less than k WITHOUT affecting the possibility that one of those edges may be required for the actual solution? Because if an edge e is taken out because it produces a simple path of weight < k for a subset of E, it can still be used in a simple path with a different combination of edges to produce a path of weight >= k.
Thanks!
Your reduction is in the wrong direction. To show that your problem is NP-complete, you need to reduce Hamilton Circuit to it, and that is very easy. I.e. show that every Hamilton Circuit problem can be expressed in terms of your problem variant.
More of a hint than an answer:
A unweighted graph can be interpreted as a weighted graph where each edge has weight 1. What would the cost of a Hamiltonian cycle be in a graph like that?
The part about the mismatch between cycles and paths is correct and is a problem you need to solve. Basically you need to prove that the Hamiltonian Path problem is also NP complete (a relatively straightfoward reduction to the Cycle problem)
As for the other part, you are doing things in the wrong direction. You need to show that your more complicated problem can solve the Hamiltonian Path problem (and is thus NP-hard). To do this you just basically have to use the special case of unit-cost edges.
Is there an established algorithm for finding a path from point A to point B in a directed-weighted graph which visits exactly N nodes, but not necessarily any nodes in particular?
This problem is known to be NP-hard via a reduction from Hamiltonian path. In particular, you can solve Hamiltonian path with a polynomial-time reduction to this problem as follows: for each possible pair of nodes (s, t) in a graph with n nodes, ask if there is a path from s to t that passes through exactly n nodes. This makes only polynomial calls to your solver, so any polynomial-time solution to your problem would result in a polynomial-time solution to the Hamiltonian path problem.
So in short, you shouldn't expect a polynomial-time algorithm for this problem unless P = NP.
I'm going to assume you're trying to find the shortest/longest weight with N nodes. This probably isn't optimal, but from your original graph, you could generate a state graph with 'N*(#Nodes)' nodes representing consisting of the original node and number of steps taken and run it thorough some shortest path algorithm like http://en.wikipedia.org/wiki/Dijkstra's_algorithm.
i.e.,
A->B->C
\___/
becomes
(A,0)->(B,1)->(C,2)
\>(C,1)
Your target node would then be node (B,N) - B with N steps. This approach would allow for loops in the original graph if it's not a DAG ( (X,0)->(Y,1)->(X,2) )
I am not sure if I undersand it correctly, can you do a depth first search (up to N-1 layers away from the source)?
If you can visit your destination in that layer. you can get a path down there.