Given a weighted undirected graph G and two nodes U,V to get the shortest path. How can i get the shortest path from U to V that uses a even number of edges (if possible to get it) ?
I've found some articles on the web speaking that a modification on the original graph is necessary. But i can't understand how to do it.
There is some good material to study on this problem ?
You'll need to build an intermediate graph and run Dijkstra's on that graph.
Given a graph G = (V, E), create a new graph G' = (V', E'), with V' a new set of vertices v_even and v_odd for every vertex v in V and E' the set of vertices as follows:
If (u, v) is an edge in G, then (u_odd, v_even) and (u_even, v_odd) are edges in G', with the same weight.
Obviously, the new graph has twice as many edges and vertices as the original graph.
Now, if you wanted to find the shortest path between s and t in G, simply run Dijkstra's on G' to find the shortest path between s_even and t_even.
The running time is still O(|V| log |E|).
Make a copy of your graph with the same weights and call it G'.
Connect every vertex of G to the corresponding vertex in G' and set the weight of the new edges to zero.
Delete copy of u from G' and delete v from G.
Now, the set of edges you added between G and G' constitute a matching M. Take that matching and find a minimum augmenting path for that matching.
Such a path must have u as one of its end points and copy of v as the other endpoint, because they are the only uncovered vertices. If you merge back the copies and get rid of the added edges, the path you found corresponds to an even path, because it starts at one copy and ends at another. Also, every even path corresponds to an augmenting path (by same argument), therefore the minimum of one is also the minimum of the other. This is explained in here.
What about running Dijkstra where each node has two values. One is odd (coming from even value) and other is even value.
Related
I have to solve this problem and it has been bugging me for hours and I can't seem to find a valid solution that satisfies the time complexity required.
For any edge e in any graph G, let G\e denote the graph obtained by deleting e from G.
(a)Suppose we are given an edge-weighted directed graph G in which the shortest path σ from vertex s to vertex t passes through every vertex of G. Describe an algorithm to compute the shortest-path distance from s to t in G\e, for every edge e of G, in O(VlogV) time. Your algorithm should output a set of E shortest-path distances,one for each edge of the input graph. You may assume that all edge weights are non-negative.[Hint: If we delete an edge of the original shortest path, how do the old and new shortest paths overlap?
(b) Describe an algorithm to solve the replacement paths problem for arbitrary undirected graphs in O(V log V ) time.
a) Consider the shortest path P between vertices s and t. Since P is a shortest path, there is no edge between any two vertices u and v in P in which the length of shortest path between u and v is bigger than 1 in the induced graph P. Since every vertex in G is present in P, So every edge of G is present in the induced graph of P. So we conclude that every edge in G is between two adjacent vertices in P (not the induced graph of P). The only thing you should check for each edge e which connects vertices u and v in G, is that there is another edge which connects u and v in G. If so, the shortest path doesn't change in G/e, otherwise s and t will lie on different components.
First of all I want to mention that the complexity can't only depend on V since the output should contain E values, therefore I guess it should be O(E + Vlog(V)).
I think the following idea should work for problem b) and thus for a) as well. Let σ be the shortest s-t path.
For every edge e in G/E(σ), the shortest path in G/e is still σ.
If we remove an edge e in σ, then the shortest path in the remaining graph would like this: it would start going along σ, then would continue outside (might be from the very first vertex s, then go back to σ (might be at the very last vertex t). Let's then iterate over all edges e=(u,v) that either go from G/σ to σ, or from one vertex of σ, that is closer to s, to another vertex of σ, that is closer to t, as edges of potential candidate paths for some shortest s-t path in G/e' for some e'. Suppose that w is the last vertex in the shortest s-u path U that belongs to σ. Then U+e+σ[v..t] is a potential candidate for a shortest s-t path in graphs G/e' for all e' in σ[w..v]. In order to efficiently store this candidate, we can use a Segment Tree data structure with min operation. This would give us O(E log(E)) total complexity for all updates after we consider all edges. It might be possible to make it O(Vlog(V)) if we look closer at the structure of the updates, but I am not sure at the moment, might be not. Precomputing vertices w for each shortest s-u path above can be done in a single Dijkstra run, if we already have σ.
So in the end the solution runs in O(Elog(E)) time. I am not sure how to make it O(E + Vlog(V)), it is possible to make Dijkstra to run in this time by using Fibonacci heap, but for the updates for candidates I don't really see a faster solution at the moment.
Given an algorithm A that computes the longest path from a source vertex s in a DAG G with non-negative edge weights. What is the minimum number of times required to run the algorithm A to find the longest path in a DAG G?
One way is to figure out the multiple source vertices, this can be achieved in O(|Edges|). And then run Algorithm A with each of these vertices as a source vertex. This will require running algorithm A NumberOfSourceVertices times.
Can we do better ?
Yes, we can do better. Add a new node z to G. For every identified source vertex s, add an edge (z, s, 0) (zero edge weight) to G.
Run A once on the modified G.
I'm trying to implement Dijkstra's algorithm with a priority queue.
From my understanding, "Dijkstra's algorithm" allows to to find the shortest 'paths', in that it will return a set of vertices that form the shortest path *.
From this answer here https://stackoverflow.com/a/20217659/1663462, as well as (Dijkstra's_algorithm#Algorithm) it seems I should be able implement it using just two datastructures: a graph and queue datastructure.
However, in my implementation using the two mentioned datastructures, when I finally reach the destination node, I don't have the vertices path stored? In other words I just have the shortest distance only (a single scalar value).
How is this meant to be kept track of? The only way I can think of is to use an additional datastructure - an array or hash map where the key would be the vertex and the value would be it's parent.
The actual question:
Is the additional datastructure necessary to achieve ("set of vertices that form the shortest path *")? If not, how do I determine the vertices?
You don't have to keep track of the whole path for each vertex as you've suggested. To produce the s-v paths themselves, the only thing you have to record for each vertex v is the edge that "discovered" it.
In other words, as a vertex v is being discovered by the algorithm, you record the edge (u,v) on which it achieved the value that minimized the distance from s.
Now, assuming you have the "discovering" edge for each vertex v in the graph, the path from s to v can be computed as follows: if (u,v) is the ("discovering") edge stored for v, then the shortest path from s to v is the path from s to u (which can be computed recursively), followed by the single edge (u,v).
So, to construct the shortest path from s to v, you start at vertex v, then you follow the edge stored for v in the reverse direction, and continue until you reach s.
Yes the additional data structure is necessary, I did not find a way to do without it.
One get the shortest 'distance' without it between two vertices, but it will not include the list of vertices between the source and destination vertex.
Although it is possible to store additional information on the nodes while running Dijkstra's algorithm, it is not strictly necessary.
Indeed, it is possible to trace back a shortest path after running Dijkstra's algorithm, even if no additional information was stored on the nodes. The only information needed on each node is its distance from the source.
I will use the following notations:
s is the source vertex;
t is the destination vertex;
w(u,v) is the length of edge (u,v) between two vertices u and v (given with the graph);
d(v) is the length of the shortest path from source s to a vertex v (computed by Dijkstra).
If Dijkstra's algorithm was run correctly, then the following proposition must be true for all vertices v except the source:
Vertex v has at least one neighbour u such that d(v) = d(u) + w(u,v).
For every vertex v, call pred(v) that neighbour.
Then a shortest path can be constructed in reverse, starting from destination t, by following the pred vertices.
I have a graph with about 6500 vertices, some of which have the label 'c'. I need to devise an algorithm that finds the shortest path between any two of the vertices that includes AT LEAST ONE of these 'c' vertices. This is simple enough, but the problem is that the required complexity is O(ElogV) where E is the number of edges, and V is the number of vertices. I have already implemented Dijkstra's Algorithm using a min-heap, so I can find the general shortest path in O(ElogV), but I am having trouble extending the problem. Any suggestions?
Note that calling Dijkstra's from source to c + c to destination iteratively does not fall within the complexity restraints, as it ends up being O(CElogV)
Let G be your graph, with vertices v1...vn.
Make a new graph that consists of two copies of your original vertices: v1..vn, v1'..vn'. In this new graph, let there be an edge between vi and vj or vi' and vj' if there's an edge between vi and vj in your original graph. Also let there be an edge between vi and vj' if there's an edge between vi and vj in your original graph, and vj' is labelled c.
Then, given two vertices vi, vj, the shortest path between vi and vj' in the new graph is the shortest path between vi and vj in the original graph that passes through at least one vertex labelled c.
Because the number of vertices in the new graph is doubled, and the number of edges at most tripled, the complexity doesn't change from O(VlogE) (where V and E are the number of vertices/edges in the original graph).
If you have an undirected graph:
Say you're searching for a shortest path between S and T.
find all the shortest paths from S to any node using Dijkstra's algorithm
find all the shortest paths from T to any node (same algorithm)
iterate over all marked nodes c and find the shortest path S to c combined with c to T using previously calculated shortest paths.
Can someone please explain how given an undirected graph G = (V; E); edge lengths le > 0; and edge edges in E.
We can generate the length of the shortest cycle containing edge e.
I understand how to do this in directed graphs, but im not sure how to approach the problem with an undirected graph.
Without modifying the graph: Let e be an edge (u, v). Choose one of the two nodes—I'll choose u—and run an ordinary Dijkstra/BFS starting from u with one minor modification: When making the first hop, you must not add v to the queue. Now search for v.