Question
How would one going about finding a least cost path when the destination is unknown, but the number of edges traversed is a fixed value? Is there a specific name for this problem, or for an algorithm to solve it?
Note that maybe the term "walk" is more appropriate than "path", I'm not sure.
Explanation
Say you have a weighted graph, and you start at vertex V1. The goal is to find a path of length N (where N is the number of edges traversed, can cross the same edge multiple times, can revisit vertices) that has the smallest cost. This process would need to be repeated for all possible starting vertices.
As an additional heuristic, consider a turn-based game where there are rooms connected by corridors. Each corridor has a cost associated with it, and your final score is lowered by an amount equal to each cost 'paid'. It takes 1 turn to traverse a corridor, and the game lasts 10 turns. You can stay in a room (self-loop), but staying put has a cost associated with it too. If you know the cost of all corridors (and for staying put in each room; i.e., you know the weighted graph), what is the optimal (highest-scoring) path to take for a 10-turn (or N-turn) game? You can revisit rooms and corridors.
Possible Approach (likely to fail)
I was originally thinking of using Dijkstra's algorithm to find least cost path between all pairs of vertices, and then for each starting vertex subset the LCP's of length N. However, I realized that this might not give the LCP of length N for a given starting vertex. For example, Dijkstra's LCP between V1 and V2 might have length < N, and Dijkstra's might have excluded an unnecessary but low-cost edge, which, if included, would have made the path length equal N.
It's an interesting fact that if A is the adjacency matrix and you compute Ak using addition and min in place of the usual multiply and sum used in normal matrix multiplication, then Ak[i,j] is the length of the shortest path from node i to node j with exactly k edges. Now the trick is to use repeated squaring so that Ak needs only log k matrix multiply ops.
If you need the path in addition to the minimum length, you must track where the result of each min operation came from.
For your purposes, you want the location of the min of each row of the result matrix and corresponding path.
This is a good algorithm if the graph is dense. If it's sparse, then doing one bread-first search per node to depth k will be faster.
I study on Greedy Algorithm. summarize some important aspects about Dijkstra's Algorithms, that will be TRUE. i suspect about (4) and (1), anyone could help me?
I) if all edges weight be negative, the Dijkstra's algorithm, works well.
II) if in graph we have a negative cycle, Dijkstra's get into a infinite loop and never end.
III) if a graph has a one edge with negative weight, but hasn't a negative cycle, the algorithm doesn't works well.
IV) if graph hasn't a negative cycle, the algorithms work well.
Dijkstra's algorithm only works on graphs with non-negative edges. This is because it assumes that the first time a node is popped off the queue we have found the shortest path to that node and this is not necessarily true as soon as you have even one negative weight.
Therefore I is false, II is false (because the negative cycle may not necessarily be reachable), III is true, IV is false (it may still have a negative edge even without a negative cycle).
If I remember it correctly Dijkstra's algorithm (at least the classic version of it) has a built in assumption that all weights in a graph are non-negative. So we have no guarantee that it will work correctly if we have negative edges in our graph.
I) In the first case we will most likely get a longest possible chain of edges with highest absolute values of weights as the shortest path, technically this will be the correct shortest path. (I assume the graph has no negative cycles)
II) False as negative cycle may be unreachable (as Peter de Rivaz correctly said)
III-IV) I assume that the 3rd paragraph is about graph having one edge with negative weight, but hasn't a negative cycle. In this case there is a possibility of algorithm stucking in a loop, because it can find a cycle with a negative-weight edge that will seem to an algorithm as a good path prolongation beacuse at some point in algorithm we decide on the next step on the weight of one edge. The negative one will always be the first choice no doubt, so even with a non-negative cycle we getting a possibility of infinite looping.
I stumbled with famous Yen's optimization of Bellman-Ford algorithm that I got initially from Wikipedia, then I found the same improvement in several textbooks in Exercise section (for example, this is a problem 24-1 in Cormen and Web exercise N5 in Sedgewick's "Algorithms").
Here's the improvement:
Yen's second improvement first assigns some arbitrary linear order on all vertices and then partitions the set of all edges into two subsets. The first subset, Ef, contains all edges (vi, vj) such that i < j; the second, Eb, contains edges (vi, vj) such that i > j. Each vertex is visited in the order v1, v2, ..., v|V|, relaxing each outgoing edge from that vertex in Ef. Each vertex is then visited in the order v|V|, v|V|−1, ..., v1, relaxing each outgoing edge from that vertex in Eb. Each iteration of the main loop of the algorithm, after the first one, adds at least two edges to the set of edges whose relaxed distances match the correct shortest path distances: one from Ef and one from Eb. This modification reduces the worst-case number of iterations of the main loop of the algorithm from |V| − 1 to |V|/2.
Unfortunately, I didn't manage to find the proof of this bound |V|/2, and moreover, it seems that I found a counterexample. I'm sure that I'm wrong about that, but I can't see where exactly.
The counterexample is just a path graph with vertices labeled from 1 to n and initial vertex 1. (So, E={(i, i+1)} for i in range from 1 to n-1). In that case the set of forward vertices is equal E (E_f = E) and the set of backward vertices is just the empty set. Each iteration of algorithm adds only one correctly computed distance, so algorithm finishes in n-1 time, which contradicts the proposed bound n/2.
What am I doing wrong?
UPD: So the mistake was very stupid. I didn't consider the iteration through vertices, thinking about iterations as of immediate updates of path costs. I'm not deleting this topic because someone upvoted it, in case this improvement can be interesting for someone.
This is actually the best case which finishes in 2 iterations regardless of the number of vertices.
Draw the iterations on paper or write the code. The first iteration will find all the correct shortest paths. The second iteration will then not change anything and the algorithm terminates because the set of vertices whose distance was changed last iteration is empty.
The "forward" run through the vertices that relaxes the Ef set of edges will do all the work, while the "backwards" run won't do anything because Eb is an empty set.
I am trying to understand why Dijkstra's algorithm will not work with negative weights. Reading an example on Shortest Paths, I am trying to figure out the following scenario:
2
A-------B
\ /
3 \ / -2
\ /
C
From the website:
Assuming the edges are all directed from left to right, If we start
with A, Dijkstra's algorithm will choose the edge (A,x) minimizing
d(A,A)+length(edge), namely (A,B). It then sets d(A,B)=2 and chooses
another edge (y,C) minimizing d(A,y)+d(y,C); the only choice is (A,C)
and it sets d(A,C)=3. But it never finds the shortest path from A to
B, via C, with total length 1.
I can not understand why using the following implementation of Dijkstra, d[B] will not be updated to 1 (When the algorithm reaches vertex C, it will run a relax on B, see that the d[B] equals to 2, and therefore update its value to 1).
Dijkstra(G, w, s) {
Initialize-Single-Source(G, s)
S ← Ø
Q ← V[G]//priority queue by d[v]
while Q ≠ Ø do
u ← Extract-Min(Q)
S ← S U {u}
for each vertex v in Adj[u] do
Relax(u, v)
}
Initialize-Single-Source(G, s) {
for each vertex v V(G)
d[v] ← ∞
π[v] ← NIL
d[s] ← 0
}
Relax(u, v) {
//update only if we found a strictly shortest path
if d[v] > d[u] + w(u,v)
d[v] ← d[u] + w(u,v)
π[v] ← u
Update(Q, v)
}
Thanks,
Meir
The algorithm you have suggested will indeed find the shortest path in this graph, but not all graphs in general. For example, consider this graph:
Let's trace through the execution of your algorithm.
First, you set d(A) to 0 and the other distances to ∞.
You then expand out node A, setting d(B) to 1, d(C) to 0, and d(D) to 99.
Next, you expand out C, with no net changes.
You then expand out B, which has no effect.
Finally, you expand D, which changes d(B) to -201.
Notice that at the end of this, though, that d(C) is still 0, even though the shortest path to C has length -200. This means that your algorithm doesn't compute the correct distances to all the nodes. Moreover, even if you were to store back pointers saying how to get from each node to the start node A, you'd end taking the wrong path back from C to A.
The reason for this is that Dijkstra's algorithm (and your algorithm) are greedy algorithms that assume that once they've computed the distance to some node, the distance found must be the optimal distance. In other words, the algorithm doesn't allow itself to take the distance of a node it has expanded and change what that distance is. In the case of negative edges, your algorithm, and Dijkstra's algorithm, can be "surprised" by seeing a negative-cost edge that would indeed decrease the cost of the best path from the starting node to some other node.
Note, that Dijkstra works even for negative weights, if the Graph has no negative cycles, i.e. cycles whose summed up weight is less than zero.
Of course one might ask, why in the example made by templatetypedef Dijkstra fails even though there are no negative cycles, infact not even cycles. That is because he is using another stop criterion, that holds the algorithm as soon as the target node is reached (or all nodes have been settled once, he did not specify that exactly). In a graph without negative weights this works fine.
If one is using the alternative stop criterion, which stops the algorithm when the priority-queue (heap) runs empty (this stop criterion was also used in the question), then dijkstra will find the correct distance even for graphs with negative weights but without negative cycles.
However, in this case, the asymptotic time bound of dijkstra for graphs without negative cycles is lost. This is because a previously settled node can be reinserted into the heap when a better distance is found due to negative weights. This property is called label correcting.
TL;DR: The answer depends on your implementation. For the pseudo code you posted, it works with negative weights.
Variants of Dijkstra's Algorithm
The key is there are 3 kinds of implementation of Dijkstra's algorithm, but all the answers under this question ignore the differences among these variants.
Using a nested for-loop to relax vertices. This is the easiest way to implement Dijkstra's algorithm. The time complexity is O(V^2).
Priority-queue/heap based implementation + NO re-entrance allowed, where re-entrance means a relaxed vertex can be pushed into the priority-queue again to be relaxed again later.
Priority-queue/heap based implementation + re-entrance allowed.
Version 1 & 2 will fail on graphs with negative weights (if you get the correct answer in such cases, it is just a coincidence), but version 3 still works.
The pseudo code posted under the original problem is the version 3 above, so it works with negative weights.
Here is a good reference from Algorithm (4th edition), which says (and contains the java implementation of version 2 & 3 I mentioned above):
Q. Does Dijkstra's algorithm work with negative weights?
A. Yes and no. There are two shortest paths algorithms known as Dijkstra's algorithm, depending on whether a vertex can be enqueued on the priority queue more than once. When the weights are nonnegative, the two versions coincide (as no vertex will be enqueued more than once). The version implemented in DijkstraSP.java (which allows a vertex to be enqueued more than once) is correct in the presence of negative edge weights (but no negative cycles) but its running time is exponential in the worst case. (We note that DijkstraSP.java throws an exception if the edge-weighted digraph has an edge with a negative weight, so that a programmer is not surprised by this exponential behavior.) If we modify DijkstraSP.java so that a vertex cannot be enqueued more than once (e.g., using a marked[] array to mark those vertices that have been relaxed), then the algorithm is guaranteed to run in E log V time but it may yield incorrect results when there are edges with negative weights.
For more implementation details and the connection of version 3 with Bellman-Ford algorithm, please see this answer from zhihu. It is also my answer (but in Chinese). Currently I don't have time to translate it into English. I really appreciate it if someone could do this and edit this answer on stackoverflow.
you did not use S anywhere in your algorithm (besides modifying it). the idea of dijkstra is once a vertex is on S, it will not be modified ever again. in this case, once B is inside S, you will not reach it again via C.
this fact ensures the complexity of O(E+VlogV) [otherwise, you will repeat edges more then once, and vertices more then once]
in other words, the algorithm you posted, might not be in O(E+VlogV), as promised by dijkstra's algorithm.
Since Dijkstra is a Greedy approach, once a vertice is marked as visited for this loop, it would never be reevaluated again even if there's another path with less cost to reach it later on. And such issue could only happen when negative edges exist in the graph.
A greedy algorithm, as the name suggests, always makes the choice that seems to be the best at that moment. Assume that you have an objective function that needs to be optimized (either maximized or minimized) at a given point. A Greedy algorithm makes greedy choices at each step to ensure that the objective function is optimized. The Greedy algorithm has only one shot to compute the optimal solution so that it never goes back and reverses the decision.
Consider what happens if you go back and forth between B and C...voila
(relevant only if the graph is not directed)
Edited:
I believe the problem has to do with the fact that the path with AC* can only be better than AB with the existence of negative weight edges, so it doesn't matter where you go after AC, with the assumption of non-negative weight edges it is impossible to find a path better than AB once you chose to reach B after going AC.
"2) Can we use Dijksra’s algorithm for shortest paths for graphs with negative weights – one idea can be, calculate the minimum weight value, add a positive value (equal to absolute value of minimum weight value) to all weights and run the Dijksra’s algorithm for the modified graph. Will this algorithm work?"
This absolutely doesn't work unless all shortest paths have same length. For example given a shortest path of length two edges, and after adding absolute value to each edge, then the total path cost is increased by 2 * |max negative weight|. On the other hand another path of length three edges, so the path cost is increased by 3 * |max negative weight|. Hence, all distinct paths are increased by different amounts.
You can use dijkstra's algorithm with negative edges not including negative cycle, but you must allow a vertex can be visited multiple times and that version will lose it's fast time complexity.
In that case practically I've seen it's better to use SPFA algorithm which have normal queue and can handle negative edges.
I will be just combining all of the comments to give a better understanding of this problem.
There can be two ways of using Dijkstra's algorithms :
Marking the nodes that have already found the minimum distance from the source (faster algorithm since we won't be revisiting nodes whose shortest path have been found already)
Not marking the nodes that have already found the minimum distance from the source (a bit slower than the above)
Now the question arises, what if we don't mark the nodes so that we can find shortest path including those containing negative weights ?
The answer is simple. Consider a case when you only have negative weights in the graph:
)
Now, if you start from the node 0 (Source), you will have steps as (here I'm not marking the nodes):
0->0 as 0, 0->1 as inf , 0->2 as inf in the beginning
0->1 as -1
0->2 as -5
0->0 as -8 (since we are not relaxing nodes)
0->1 as -9 .. and so on
This loop will go on forever, therefore Dijkstra's algorithm fails to find the minimum distance in case of negative weights (considering all the cases).
That's why Bellman Ford Algo is used to find the shortest path in case of negative weights, as it will stop the loop in case of negative cycle.
Given a weighted graph (directed or undirected) I need to find the cycle of the graph with the maximum weight.
The weight of a cycle being the sum of the weight of the edges of the graph.
It can be any cycle, not just base cycle for which we can
find all base cycle (see Algorithms to Identify All the Cycle Bases in a UnDirected Graph )
compute the weight of each base cycle and find the maximum
I could try to enumerate all cycles of the graph and then compute the maximum but the total number of cycles can be really big (if the graph is complete then any sequence of vertices where the first and last one are identical is a cycle).
Do you have any idea to find that maximum weight cycle without enumerating all cycles ?
If you need hypothesis on the graph (positives weights for example) please indicates them.
This is NP-Hard.
Hamiltonian Cycle problem can be reduced to this.
Given a graph for which we need to check if there exists a Hamiltonian Cycle or not, assign weight 1 to each edge.
Now run your algorithm to get the maximum weight cycle. If the weight is < n, then the original graph has no Hamiltonian cycle, otherwise it does.
If you can find the minimum weighted path in your specific case, just reverse the signs of all the weights and apply your algorithm. Of course you are making some unstated assumptions because Moron's argument is correct (no pun intended). The assumptions you are making could be positive weights or no negative weight cycles. I think you should make an effort to state them instead of letting people search in the infinite space of possible assumptions. As to hardness results, this is also hard to approximate in a number of way, check out this paper. The same paper contains several positive results for important types of graphs, but it's concerned with longest unweighted paths so my guess is that most algorithms in the paper won't directly help in your case. If you search for "Heavy cycles" you will find a number of interesting papers, but they are more mathematical in character. If your weights are small integers (up to a polynomial in the size of the graph), you can try and replace every edge with an unweighted path to reduce your problem to the unweighted case. I hope this helps to some degree, but you might have an open research problem on your hands.