There are two functions that I wish to minimize:
a. the number of "obstacles" on the path (assume each obstacle increases the cost); and
b. total number of edges between the source and the destination.
If I had to minimize just (a), I would have used Dijkstra's algorithm; if I had to minimize just (b), I would have used BFS.
But given that I have to minimize both, can I use Dijkstra's algorithm only? In other words, if I find the path with the least cost from the obstacles, does Dijkstra's algorithm also guarantee that the path length thus obtained (between source and destination) would be the shortest?
When discussing paths on weighted graphs, the term "shortest path" means the path with the lowest total cost. Think of the weights as distances. This is the path that Dijkstra's algorithm will find.
You can use any cost function you like, as long as the cost to get from one vertex to another is always positive or zero. As mentioned in comments, however, you can only minimize one function at a time. This is a general fact that has nothing to do with Dijkstra's algorithm.
The cost function that you seem to suggesting is perfectly fine -- the cost to move to a normal vertex is 1, while the cost to move to an "obstacle" vertex is higher. Dijkstra's algorithm is the appropriate way to find a path with lowest total cost.
Related
I have a weighted graph G and a pair of nodes s and t. I want to find, of all the paths from s to t with the fewest number of edges, the one that has the lowest total cost. I'm not sure how to do this. Here are my thoughts:
I am thinking of finding the shortest path and if there are more than one path then i should compare the number of steps of these paths.
I think I can find the number of steps by setting the weights of all edges to 1 and calculate the distance.
A reasonable first guess for a place to start here is Dijkstra's algorithm, which can solve each individual piece of this problem (minimize number of edges, or minimize total length). The challenge is getting it to do both at the same time.
Normally, when talking about shortest paths, we think of paths as having a single cost. However, you could imagine assigning paths two different costs: one cost based purely on the number of edges, and one cost based purely on the weights of those edges. You could then represent the cost of a path as a pair (length, weight), where length is the number of edges in the path and weight is the total weight of all of those edges.
Imagine running Dijkstra's algorithm on a graph with the following modifications. First, instead of tracking a candidate distance to each node in the graph, you track a pair of candidate distances to each node: a candidate length and a candidate weight. Second, whenever you need to fetch the lowest-code node, pick the node that has the shortest length (not weight). If there's a tie between multiple nodes with the same length, break the tie by choosing the one with the lowest weight. (If you've heard about lexicographical orderings, you could consider this as taking the node whose (length, weight) is lexicographically first). Finally, whenever you update a distance by extending a path by one edge, update both the candidate length and the candidate weight to that node. You can show that this process will compute the best path to each node, where "best" means "of all the paths with the minimum number of edges, the one with the lowest cost."
You could alternatively implement the above technique by modifying all the costs of the edges in the graph. Suppose that the maximum-cost edge in the graph has cost U. Then do the following: Add U+1 to all the costs in the graph, then run Dijkstra's algorithm on the result. The net effect of this is that the shortest path in this new graph will be the one that minimizes the number of edges used. Why? Well, every edge adds U+1 to the cost of the path, and U+1 is greater than the cost of any edge in the graph, so if one path is cheaper than another, it either uses at least one fewer edge, or it uses the same number of edges but has cheaper weights. In fact, you can prove that this approach is essentially identical to the one above using pairs of weights - it's a good exercise!
Overall, both of these approaches will run in the same time as a normal Dijkstra's algorithm (O(m + n log n) with a Fibonacci heap, O(m log n) with another type of heap), which is pretty cool!
One node to another would be a shortest-path-algorithm (e.g. Dijkstra).
It depends on your input whether you use a heuristic function to determine the total distance to the goal-node.
If you consider heuristics, you might want to choose A*-search instead. Here you just have to accumulate the weights to each node and add the heuristic value according to it.
If you want to get all paths from any node to any other node, you might consider Kruskal’s or Prim’s algorithm.
Both to basically the same, incl. pruning.
I have a directed graph that has all non-negative edges except the edge(s) that leave the source (S). There are no edges from any other vertices to the source. To find the shortest distance from source (S) to a vertex (T) in the graph, can I use Dijkstra's shortest path algorithm even though the edges leaving the source is negative?
Assuming only source-adjecent edges can have negative weights and there is no path back to the source from any of the source-adjecent nodes (as mentioned in the comment), you can just add a constant C onto all edges leaving the source to make them all non-negative. Then subtract C from the final result.
On a more general note, Dijkstra can be used to solve shortest-path in any graph with negative edge weights (but no negative cycles) after applying Johnson's reweighting algorithm (which is essentially Bellman-Ford, but needs to be performed only once).
Yes, you can use Dijkstra on that type of directed graph.
If you use already finished alghoritm for Dijsktra and it cannot use negative values, it can be good practise to find the lowest negative edge and add that number to all starting edges, therefore there is no-negative number at all. You substract that number after finishing.
If you code it yourself (which is acutally pretty easy and I recommend it to you), you almost does not change anything, just start with lowest value (as usual for Dijkstra) and allow it, that lowest value can be negative. It will work in your case.
The reason you generally can't use Dijkstra's algorithm for (directed) graphs with negative links is that Dijkstra's algorithm is greedy. It assumes that once you pick a vertex with minimum distance, there is no way it can later be reached by a smaller paths.
In your particular graph, after the very first step, you traverse all possible negative edges and Dijkstra's assumption actually holds from now on. Regardless of the fact that those vertices directly connected to start now have negative values, once you identify which has the minimum distance, it can never be reached again with a smaller distance (since all edges you would traverse from this point on would have a positive distance).
If you think about the conditions that dijkstra's algorithm puts upon the edges for the algorithm to work it is only that they are never decreasing after initialisation.
Thus, it actually doesn't matter if the first step is negative as from those several points onwards the function is constantly increasing and thus the correct output will be found (provided there is no way to get back to the start square.).
What algorithms are there, for weighted directed graphs, to find the maximum cost and path for going from a vertex A to a vertex K ?
I was thinking of modfied Dijkstra, but while watching and learning this algorithm, I found out it can't be used with negative weights and can't be used to find the maximum cost.
I suggest the following: choose any algorithm for minimum cost(distance) and also works with negative edges(thus Dijkstra can not be used for this). Then run this algorithm using the negation of the cost for each edge. You can use Bellman–Ford algorithm for instance.
You could use a modified version of the A* (A-star) algorithm. I say modified but it wouldn't actually be modified. You just need an appropriate heuristic. It is a path finding algorithm, you would just need to set your heuristic to chooses the costliest path.
A* works by starting at some vertex V, and adding all of that vertex's adjacent neighbors to an open list. Then it moves, in your case, to the node with the highest cost. The previously visited node is moved to a closed list. Then all the adjacent nodes to the current node are added to the open list. And so on and so forth.
It will find your K, and if your heuristic is to always choose the costliest path, you will have the maximum cost route.
Here is A* being applied to Infinite Mario.
I know Bellman Ford algorithm works well with negative weighted Graph, But I've developed a code of Dijkstra Algorithm that works very well. But it fails when I insert negative weighted edges. Any Solution?
I think we can't do that, as Dijkstra algorithm will not find a final way to reach at destination vertex because it may get stuck in loops, it is not made for negative weighted graphs, you should go for bellman ford algorithm
Actually, it is possible in a special case. Dijkstra algorithm will fail, if there is an edge of a negative length. However, if all edges are of negative length, then you may inverse the lengths of all edges and use the algorithm to find the longest path between two vertices of the graph (the path will represent the shortest path in the original graph).
But in a general case, as you have stated, it is not possible to use Dijkstra. If there is no cycle of negative length, than you shall use Bellman-Ford algorithm. If you cannot guarantee that there no cycle of negative length, than the problem is NP-complete and there is no known polynomial algorithm.
As you stated, Bellman Ford is the algorithm of choice for finding the shortest path in a graph with negative weights. The issue with using Dijkstra's Algorithm in this scenario is that Dijkstra's assumes that all possible subpaths from s to t in a graph must be smaller than the goal subpath, which is not necessarily true when negative edge weights are added.
If all edge weights are positive, this guarantees that adding more edges to a path makes it longer. Knowing this, Dijkstra's algorithm will discard any paths that are longer than the shortest one it has found to some vertex since there is no chance of the long path becoming shorter than the short path.
However, this assumption is not true if there are negative edge weights since we could have an extremely long path P that we discarded, but somewhere down the road, P can pass through a very negative edge and become shorter than the shortest path you currently have. Therefore, we can't guarantee that a path we've found is the shortest at any stage in Dijkstra's algorithm, which the algorithm relies on.
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.