I'm a bit stuck with this task.
We have a matrix with distances between every city (60 cities).
We have to pass through every city at least once with an electric car.
Every city has a charging point for the car. No limits on how many times we can stop at one city.
I have to find the minimal range with one charge the car needs to have so that we could pass through every city.
How should I encounter this task?
Update:
While MST (minimum spanning tree) works for this problem, it probably1 doesn't have the optimal time complexity. The problem should be considered as MSBT (minimum bottleneck spanning tree) instead, for which algorithms with linear time complexity in term of number of edges exist, such as Camerini's_algorithm.
You are looking for the maximum edge of the MST. There are many well-known algorithms for finding MST, of which Kruskal's and Prim's (which btilly uses in his answer) are the easiest to implement.
It is easy to see, why the maximum edge of MST is enough to drive through every city: you can traverse all cities, fully charging in each city and driving only roads that belong to the tree.
The range of at least the maximum edge of MST is required, because otherwise you will not be able to visit both cities that this edge is connected. This can be seen from the way Kruskal's algorithm is constructed. If only edges less that the maximum edge of MST are taken, then Kruskal's algorithm will fail to join all vertices into a single connected component.
Let's assume that there is a minimal spanning tree with an edge that is larger than the maximal edge of some other (minimal or not) spanning tree. Then we'll try to replace it with a smaller one. To do this, firstly delete this edge. Now we are left with two sets of vertices. The second tree must connect these sets with an edge. Lets take this edge and add it to the first tree. As this edge is smaller than the deleted one, then we've got a tree that has sum of edges less than minimal spanning tree, so the tree can't be minimal spanning tree in the first place and there is contradiction. In conclusion:
the larger spanning tree can't have smaller maximal edge
all maximal edges of every minimal spanning the tree are the same
The first statement means that the MST is the tree to look for solution, and the second statement means that it doesn't matter, which algorithm to use to find the MST
The key concept that you need is a priority queue which is usually implemented with a heap. This is a data structure that allows you to put things in with some sort of weight, and then pull out the lowest weight one.
Let's also use a set of things.
The idea now is this. We start somewhere. We have a priority queue of ways of getting to another city. We always look at the shortest-range drive that gets to that city. If it gets to a new to us city, we add it to the cities we can get to, and update our range if this was a longer drive than any other that we've seen.
Once we've visited all cities, we're done.
Now here is pseudo-code.
choose a start_city
initialize set visited_cities
initialize priority queue named queue to (0, start_city)
initialize min_range = 0
while len(visited_cities) < number of cities:
(distance, city) = queue.pop()
if city not in visited_cities:
min_range = max(min_range, distance)
visited_cities.add(city)
for other_city in all cities:
if other_city not in visited_cities:
queue.add(distance from city to other_city, other_city)
min_range is the answer
Related
I am having some troubles solving a problem about Minimum Spanning Tree. So each node in a graph is a city, and is possible to have weight edges connecting two nodes, which is the cost of building a road between two cities. The problem is basically telling the minimum cost of building the roads and have all cities connected some way. I can easily solve this by using Prim or kruskal algorithm to solve this sub-problem of my biggest problem.
The tricky part comes now: Each city (node) can have an airport and each airport has a one time cost (if you decide to build it). You can travel between two cities using an airport if both cities have airports. Now I have to calculate the minimium cost of building roads AND airports in order to have all cities connected, but I am having difficulty representing the connections with the airports with the rest of the network. Can somebody help me here? Maybe I am completely wrong about using MST?
The only solution I came up is: For each city that has an aiport, I will connect that city with another cities that have airports. Also If the cost of building two airports is lower then building a road I take it in consideration. I run kruskal in order to get the cheapest edge, but If kruskal chooses an "airport" edge, I will add it to the spanning tree and then 0 the cost of both airports (if they havent been built in the past). I believe, that by doing this dynamic weight changes while runing kruskal, I am destroyng the idea of getting the minimum cost.
There are two possibilities:
1) The optimal solution does not use airports. In this case you can ignore airports and construct the minimum spanning tree as usual.
2) The optimal solution uses airports. In this case add a dummy node to the graph called "sky". The cost of building a road from any city to "sky" is the cost of building an airport. The cost of the optimal solution using airports is the cost of the minimum spanning tree in this ammended graph.
So try both options and pick the minimum cost.
Background: You have a map stored as a undirected graph. Edges present streets or highways. There are two kinds of edges - green and red- and both kind of edges have weights. The weight of an edge is the distance that edge represents. Red edges represent represent toll roads, if you cross a red edge you pay as many cents as the weight of the edge. For example the red edge (r, 20) is 20 miles long and costs you 20 cents. All the green edges are free.
Problem: Write an algorithm to find the cheapest/shortest path from city S to city D. Cost has higher priority than distance. For example a free 500-mile long path is better than a 300-mile long path that costs 70 cents!
he problem is exactly the shortest path problem if all edges are green. Also if there is a connected path from S to V with all red edges removed, then it is the shortest path problem. What if S and V are not connected with all red edges removed? Then maybe insert cheapest red edge, if S and V are connected with it then again the problem becomes the shortest path problem. So now I found three simple cases:
1. All green graph.
2. Graph with a path from S to V when all red edges are connected.
3. Graph with a path from S to V when cheapest red edge is connected.
After this point it get a little difficult, or does it???
Cost has higher priority than distance. For example a free 500-mile long path is better than a 300-mile long path that costs 70 cents!
Run Djikstra's algorithm using a min-priority queue where the routes explored are prioritised by, firstly, lowest cost then, secondly, lowest distance.
Since all-green routes will have zero-cost then these will be explored first looking for the shortest distance route; if there are no zero-cost routes then, and only then, will red routes be explored in priority order of lowest cost.
The problem is more about how you handle the data than the algorithm. Let me propose this. Say the sum of the length of all the paths is less than 1'000'000. Then I can encode the cost and length as cost * 1'000'000 + length. Now you have a simple graph where you only have one metric to optimize.
I think it's clear that the most important thing the search is going to optimize is cost (since we multiplied it by 1'000'000) and that for paths of equal cost the length is going to be the deciding factor.
To actually implement this you don't need the assumption or to conversion I just did. You can keep cost and length everywhere and simply modify your comparisons to first compare the cost and only when it's a tie to compare the lengths.
Just run a "little modified" Dijkstra on this graph with setting weight of each edge to its price. You find all low-cost solutions with it and then you choose the shortest one.
The only real problem is that you can have edges with cost 0, but it can be solved - if you are in situation where you can open multiple nodes (they would have all same price), select the one with the lowest distance.
The only difference to classic Dijkstra.
In dijkstra in each step you open the node with lowest cost. If there are multiple nodes with lowest cost, you just choose any of them (it really does not matter).
In this case, if you have multiple nodes with lowest cost, you choose the one with lowest distance. If there are multiple nodes with lowest cost and lowest distance, you can open any of them (it really does not matter).
This solves every case you mentioned.
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.
Suppose that the number of edges of a connected graph is known and the weight of each edge is distinct, would it possible to create a minimal spanning tree in linear time?
To do this we must look at each edge; and during this loop there can contain no searches otherwise it would result in at least n log n time. I'm not sure how to do this without searching in the loop. It would mean that, somehow we must only look at each edge once, and decide rather to include it or not based on some "static" previous values that does not involve a growing data structure.
So.. let's say we keep the endpoints of the node in question, then look at the next node, if the next node has the same vertices as prev, then compare the weight of prev and current node and keep the lower one. If the current node's endpoints are not equal to prev, then it is in a different component .. now I am stuck because we cannot create a hash or array to keep track of the component nodes that are already added while look through each edge in linear time.
Another approach I thought of is to find the edge with the minimal weight; since the edge weights are distinct this edge will be part of any MST. Then.. I am stuck. Since we cannot do this for n - 1 edges in linear time.
Any hints?
EDIT
What if we know the number of nodes, the number of edges and also that each edge weight is distinct? Say, for example, there are n nodes, n + 6 edges?
Then we would only have to find and remove the correct 7 edges correct?
To the best of my knowledge there is no way to compute an MST faster by knowing how many edges there are in the graph and that they are distinct. In the worst case, you would have to look at every edge in the graph before finding the minimum-cost edge (which must be in the MST), which takes Ω(m) time in the worst case. Therefore, I'll claim that any MST algorithm must take Ω(m) time in the worst case.
However, if we're already doing Ω(m) work in the worst-case, we could do the following preprocessing step on any MST algorithm:
Scan over the edges and count up how many there are.
Add an epsilon value to each edge weight to ensure the edges are unique.
This can be done in time Ω(m) as well. Consequently, if there were a way to speed up MST computation knowing the number of edges and that the edge costs are distinct, we would just do this preprocessing step on any current MST algorithm to try to get faster performance. Since to the best of my knowledge no MST algorithm actually tries to do this for performance reasons, I would suspect that there isn't a (known) way to get a faster MST algorithm based on this extra knowledge.
Hope this helps!
There's a famous randomised linear-time algorithm for minimum spanning trees whose complexity is linear in the number of edges. See "A randomized linear-time algorithm to find minimum spanning trees" by Karger, Klein, and Tarjan.
The key result in the paper is their "sampling lemma" -- that, if you independently randomly select a subset of the edges with probability p and find the minimum spanning tree of this subgraph, then there are only |V|/p edges that are better than the worst edge in the tree path connecting its ends.
As templatetypedef noted, you can't beat linear-time. That all edge weights are distinct is a common assumption that simplifies analysis; if anything, it makes MST algorithms run a little slower.
The fact that a number of edges (N) is known does not influence the complexity in any way. N is still a finite but unbounded variable, and each graph will have different N. If you place a upper bound on N, say, 1 million, then the complexity is O(1 million log 1 million) = O(1).
The fact that each edge has distinct weight does not influence the program either, because it does not say anything about the graph's structure. Therefore knowledge about current case cannot influence further processing, as we cannot predict how the graph's structure will look like in the next step.
If the number of edges is close to n, like in this case n-6 (after edit), we know that we only need to remove 7 edges as every spanning tree has only n-1 edges.
The Cycle Property shows that the most expensive edge in a cycle does not belong to any Minimum Spanning tree(assuming all edges are distinct) and thus, should be removed.
Now you can simply apply BFS or DFS to identify a cycle and remove the most expensive edge. So, overall, we need to run BFS 7 times. This takes 7*n time and gives us a time complexity of O(n). Again, this is only true if the number of edges is close to the number of nodes.
Let us have a graph. When we remove an edge, 2 'cars' are created, one from each vertice of the edge. when these 2 cars meet they stop. The problem is to create a spanning tree so that the sum of the numbers of cars that pass through each vertice is minimal.
The added difficulty is that if a vertice has n cars passing from it, then the cost is K^n and not n*K.
some thoughts. We could find the shortest chordless cycles as a start but the position of those chordless cycles, ie whether they touch each other, changes the metric and thus what the shortest cycle is.
This is not a minimum spanning tree problem. I want to solve this because each car represents a varriable and the spanning tree is the most efficient way to compute an optimization problem. When 2 cars from the same edge meet and stop, I have a reduction of one varriable from the optimization.
edit:
The process is like this. We remove a number of edges to make the graph a spanning tree. Each removed edge creates 2 cars, one at each vertice of the removed edge, that need to meet each other. We fix a path for each of those twin cars. We then check how many cars (from all the edges that we removed) pass through each vertice. If the number of the cars that pass from a vertice is n, the cost is K^n where K is a constant. We then add all the costs and that is the global cost that needs to be minimized.
please tell me if something is unclear.
https://mathoverflow.net/questions/86301/spanning-tree-that-minimizes-a-dynamic-metric
Here's one insight - cars will never pass through an articulation point, so you can break the graph up into its blocks and solve for each block separately (the minimum overall cost function is the sum of the minimum cost for each block).
To find the minimum cost for a block - you could enumerate all the spanning trees for that block and calculate the cost for each one - a brute force approach, but it should work.