A maximum spanning tree can be found by running kruskal's algorithm(just changing the edges function and considering the max weight edges first). I am interested in finding the max weight euclidean spanning tree. Does there exist a better algorithm(better worst case running time) than kruskal's to find such a spanning tree?
Monma et al. solve this in O(n log h) time and O(n) space, where n is the number of points and h is the size of the convex hull.
The algorithm (p.10 of the paper) is fairly simple so it should be accessible even without understanding the full proof.
Related
Assume that we have an undirected graph G=(V,E) and we have two nodes S and X.
Can we come up with an algorithm such that the largest weight of the edge on the path from S to X is minimized? Note that it is not the shortest path algorithm since we are not interested in minimizing their sum.
What is the complexity of this algorithm?
Is the minimum spanning tree algorithm (such as Prim) is a solution for the problem?
I don't know if minimum spanning tree will solve it or not, but it's certainly solvable by making some modifications to Dijkstra's algorithm.
Define the "length" of a path as the maximum edge in that path. Now find the shortest path from S to X using Dijkstra's algorithm. This is the path you are looking for.
Complexity is O((N+M)log N) if you use a binary heap and O(N * log N + M) with a Fibonacci heap.
Note that for this new definition of path length, if the length of a path is l, then adding an edge to the end of the path will not decrease it's length, since the maximum edge in that path can only increase. This property is necessary for Dijkstra's algorithm to work correctly.
For instance, if you were looking for the path with the shortest edge, then Dijkstra's algorithm will fail just like it fails when there are negative edges in the graph.
You can use minimum spanning tree (Prim's algorithm) to solve this problem. You will start with vertex S, then continue to build the tree using Prim's algorithm until you find X. Complexity will be O((V+E)*logV).
It will work because in the prim's algorithm you always choose the edge with minimum weight first.
I am trying to find shortest path between 2 vertices in undirected weighted graph. It is also known that weights are integers less than log(log|V|), where |V| is amount of vertices. It is easy to solve using Bellman-Ford or Dijkstra algorithms, but is there any algorithm which can do it faster?
So far, I have been thinking of using BFS and dividing edges with weight greater than 1 into couple of them with weight 1, but it is not really good idea if |V| is large number. No, it is not my homework, I am just wondering.
One way to think of this question is to improve the running time of using Dijkstra's algorithm to find the shortest path between two vertices in the undirected weighted graph. So in this case, you can use a binary heap as the data structure. A heap is a complete binary tree with the heap property that every parent node is smaller (greater) than its children nodes in the tree in a min heap (a max heap). Here you can use the min heap to store the cost to each node from the starting node.
More information about heap can be found here: https://courses.csail.mit.edu/6.006/fall10/handouts/recitation10-8.pdf
With a heap, the running time of Dijkstra's algorithm can be reduced from O(V^2) to O(E log E), because selecting the minimum distance from the heap takes O(log V) (removing the minimum distance is O(1) and fixing the heap takes O(log V)) and updating distances to vertices takes O(E log V) in total (fixing heap takes O(log V) and it takes E times to examine neighbors and change costs).
Hope this help.
Here's the problem.
A weighted undirected connected graph G is given. The weights are constant. The task is to come up with an algorithm that would find the total weight of a spanning tree for G that fulfills these two conditions (ordered by priority):
The spanning tree has to have maximum number of edges with the same weight (the actual repeated weight value is irrelevant);
The total spanning tree weight should be minimized. That means, for example, that the spanning tree T1 with weight 120 that has at most 4 edges with the same weight (and the weight of each of those four is 15) should be preferred over the spanning tree T2 with weight 140 that has at most 4 edges with the same weight (and the weight of each of those four is 8).
I've been stuck on that for quite a while now. I've already implemented Boruvka's MST search algorithm for the graph, and now I'm not sure whether I should perform any operations after MST is found, or it's better to modify MST-search algorithm itself.
Any suggestions welcome!
This can be done naively in O(m^2), and without much effort in O(mn). It seems like it is possible to do it even faster, maybe something like O(m log^2(n)) or even O(m log(n)) with a little work.
The basic idea is this. For any weight k, let MST(k) be a spanning tree which contains the maximum possible number of edges of weight k, and has minimum overall weight otherwise. There may be multiple such trees, but they will all have the same total weight, so it doesn't matter which one you pick. MST(k) can be found by using any MST algorithm and treating all edges of weight k as having weight -Infinity.
The solution to this problem will be MST(k) for some k. So the naive solution is to generate all the MST(k) and picking the one with the max number of identical edge weights and then minimum overall weight. Using Kruskal's algorithm, you can do this in O(m^2) since you only have to sort the edges once.
This can be improved to O(mn) by first finding the MST using the original weights, and then for each k, modifying the tree to MST(k) by reducing the weight of each edge of weight k to -Infinity. Updating an MST for a reduced edge weight is an O(n) operation, since you just need to find the maximum weight edge in the corresponding fundamental cycle.
To do better than O(mn) using this approach, you would have to preprocess the original MST in such a way that these edge weight reductions can be performed more quickly. It seems that something like a heavy path decomposition should work here, but there are some details to work out.
I am working on a problem in which I am given an undirected graph G on n vertices and with m edges, such that each edge e has a weight w(e) β {1, 2, 3}. The task is to design an algorithm which finds a minimum spanning tree of G in linear time (O(n + m)).
These are my thoughts so far:
In the Algorithmic Graph Theory course which I am currently studying, we have covered Kruskal's and Prim's MST Algorithms. Perhaps I can modify these in some way, in order to gain linear time.
Sorting of edges generally takes log-linear (O(mlog(m))) time; however, since all edge weights are either 1, 2 or 3, Bucket Sort can be used to sort the edges in time linear in the number of edges (O(m)).
I am using the following version of Kruskal's algorithm:
Kruskal(G)
for each vertex π£ β π do MAKEβSET(π£)
sort all edges in non-decreasing order
for edge π’, π£ β πΈ (in the non-decreasing order) do
if FIND π’ β FIND(π£) then
colour (π’, π£) blue
UNION(π’, π£)
od
return the tree formed by blue edges
Also, MAKE-SET(x), UNION(x, y) and FIND(x) are defined as follows:
MAKE-SET(π)
Create a new tree rooted at π₯
PARENT(π₯)=x
UNION(π, π)
PARENT FIND(π₯) β πΉπΌππ·(π¦)
FIND(π)
π¦ β π₯
while π¦ β PARENT(π¦) do
π¦ β PARENT(π¦)
return y
The issue I have at the moment is that, although I can implement the first two lines of Kruskal's in linear time, I have not managed to do the same for the next four lines of the algorithm (from 'for edge u, ...' until 'UNION (u, v)').
I would appreciate hints as to how to implement the rest of the algorithm in linear time, or how to find a modification of Kruskal's (or some other minimum spanning tree algorithm) in linear time.
Thank you.
If you use the Disjoint Sets data structure with both path compression and union by rank, you get a data structure whose each operation's complexity grows extremely slowly - it is something like the inverse of the Ackermann function, and is not that large for sizes such as the estimated number of atoms in the universe. Effectively, then, each operation is considered constant time, and so the rest of the algorithm is considered linear time as well.
From the same wikipedia article
Since Ξ±(n) is the inverse of this function, Ξ±(n) is less than 5 for all remotely practical values of n. Thus, the amortized running time per operation is effectively a small constant.
I have to solve a question that is something like this:
I am given a number N which represents the number of points I have. Each point has two coordinates: X and Y.
I can find the distance between two points with the following formula:
abs(x2-x1)+abs(y2-y1),
(x1,y1) being the coordinates of the first point, (x2,y2) the coordinates of the second point and abs() being the absolute value.
I have to find the minimum spanning tree, meaning I must have all my points connected with the sum of the edges being minimal. Prim's algorithm is good, but it is too slow. I read that I can make it faster using a heap but I didn't find any article that explains how to do that.
Can anyone explain me how Prim's algorithm works with a heap(some sample code would be good but not neccesarily), please?
It is possible to solve this problem efficiently(in O(n log n) time), but it is not that easy. Just using the Prim's algorithm with a heap does not help(it actually makes it even slower), because its time complexity is O(E log V), which is O(n^2 * log n) in this case.
However, you can use the Delaunay triangulation to reduce the number of edges in the graph. The Delaunay triangulation graph is planar, so it has linear number of edges. That's why running the Prim's algorithm with a heap on it gives O(n log n) time complexity(there are O(n) edges and n vertices). You can read more about it here(covering this algorithm in details and proving its correctness would make my answer way too long): http://en.wikipedia.org/wiki/Euclidean_minimum_spanning_tree. Note that even though the article is about the Euclidian mst, the approach for your case is essentially the same(it is possible to build the Delaunay triangulation for manhattan distance efficiently, too).
A description of the Prim's algorithm with a heap itself is already present in two other answers to your question.
From the Wikipedia article on Prim's algorithm:
[S]toring vertices instead of edges can improve it still further. The heap should order the vertices by the smallest edge-weight that connects them to any vertex in the partially constructed minimum spanning tree (MST) (or infinity if no such edge exists). Every time a vertex v is chosen and added to the MST, a decrease-key operation is performed on all vertices w outside the partial MST such that v is connected to w, setting the key to the minimum of its previous value and the edge cost of (v,w).
While it was pointed out that Prim's with a heap is O(E log V), which is O(n^2 log n) in the worst case, I can provide what makes the heap faster in cases other than that worst case, since that has still not been answered.
What makes Prim's so costly at O(V^2) is the necessary updating each iteration in the algorithm. In general, Prim's works by keeping a table of your vertices with the lowest length to other vertices and picking the cheapest vertex to add to your growing tree until all are added. Every time you add a vertex, you must then go back to your table and update any vertices that can now be accessed with less weight. You then must walk back all the way through your table to decide which vertex is cheapest to add. This setup - having to pick the next vertex (O(V)) V times - gives the O(V^2).
The heap is able to help this running time is all cases besides the worst case because it fixes this bottleneck. By working with a minimum heap, you can access the minimum weight in consideration in O(1). Additionally, it costs O(log V) to fix a heap after adding a number to it to maintain its properties, which is done E times for O(E log V) to maintain the heap for Prim's. This becomes the new bottleneck, which is what gives rise to the final running time of O(E log V).
So, depending on how much you know about your data, Prim's with a heap can certainly be more efficient than without!