I am trying to develop an algorithm which will be able to find minimum spanning tree from a graph.I know there are already many existing algorithms for it.However I am trying to eliminate the sorting of edges required in Kruskal's Algorithm.The algorithm I have developed so far has a part where counting of disjoint sets is needed and I need a efficient method for it.After a lot of study I came to know that the only possible way is using BFS or DFS which has a complexity of O(V+E) whereas Kruskal's algorithms has a complexity of O(ElogE).Now my question is which one is better,O(V+E) or O(ElogE)?
In general, E = O(V^2), but that bound may not be tight for all graphs. In particular, in a sparse graph, E = O(V), but for an algorithm complexity is usually stated as a worst-case value.
O(V + E) is a way of indicating that the complexity depends on how many edges there are. In a sparse graph, O(V + E) = O(V + V) = O(V), while in a dense graph O(V + E) = O(V + V^2) = O(V^2).
Another way of looking at it is to see that in big-O notation, O(X + Y) means the same thing as O(max(X, Y)).
Note that this is only useful when V and E might have the same magnitude. For Kruskal's algorithm, the dominating factor is that you need to sort the list of edges. Whether you have a sparse graph or a dense graph, that step dominates anything that might be O(V), so one simply writes O(E lg E) instead of O(V + E lg E).
Related
Can someone explain the time complexity of BFS algorithm O(V+E), if there is a for loop inside the while loop? I am solving the time complexity of BFS algorithm and I still didn't get it.
The reason the time complexity is O(V+E) is because as BFS goes through the graph, it marks the nodes as visited so it knows not to revisit them. Because each edge only has two endpoints, and each endpoint can only be visited once, the edge can only be observed at most twice. So, BFS never visits any "thing" more than twice (nodes, of which there are V many, it only can look at once, and edges, of which there are E many, can only be looked at twice). This means that T(V, E) < 2(V + E) which makes T(V, E) = O(V + E).
Here is a snippet of my pseudo code to find the MST of each Strong Connect Component (SCC) given a graph, G:
Number of SCC, K <- apply Kosaraju's algorithm on Graph G O(V + E)
Loop through K components:
each K components <- apply Kruskal's algorithm
According to what I have learnt, Kruskal's algorithm run in O(E log V) time.
However, I am unsure of the worst case time complexity of the loop. My thought is that the worst case would occur when K = 1. Hence, the big O time complexity would simply just be O(E log V).
I do not know if my thoughts are correct or if they are, what's the justification for it are.
Yes, intuitively you’re saving the cost of comparing edges in one
component with edges in another. Formally, f(V, E) ↦ E log V is a convex
function, so f(V1, E1) + f(V2,
E2) ≤ f(V1 + V2, E1 +
E2), which implies that the cost of handling multiple
components separately is never more than handling them together. Of
course, as you observe, there may be only one component, in which case
there are no savings to be had.
I was reading about worst case time complexity for the Dijkstra algorithm using binary heap (the graph being represented as adjacency list).
According to wikipedia (https://en.wikipedia.org/wiki/Dijkstra%27s_algorithm#Running_time) and various stackoverflow questions, this is O((V + E) logV) where E - number of edges, V - number of vertices. However I found no explanation as to why it can't be done in O(V + E logV).
With a self-balancing binary search tree or binary heap, the algorithm requires Θ((E+V) logV) time in the worst case
In case E >= V, the complexity reduces to O(E logV) anyway. Otherwise, we have O(E) vertices in the same connected component as the start vertex (and the algorithm ends once we get to them). On each iteration we obtain one of these vertices, taking O(logV) time to remove it from the heap.
Each update of the distance to a connected vertex takes O(logV) and the number of these updates is bound by the number of edges E so in total we do O(E) such updates. Adding O(V) time for initializing distances, we get final complexity O(V + E logV).
Where am I wrong?
For the prim algorithm for STL priority queue optimization and the algorithm using c ++ sort kruskal, what types of graphs are suitable for these two algorithms?
As you might already know,
Prim is good for dense graphs, and Kruskal is good for sparse ones.
With Kruskal, the algorithm complexity is dominated by sorting the edges.
So it's big O is O(E log E) in general cases with normal efficient sorts.
With Prim, the complexity is similar with Dijkstra's algorithm. (You can modify Dijkstra code into Prim with ease)
So it's like O((V+E) log(V)) with priority queue(heap).
So when the Graph is sparse(E < V), Kruskal is O(E log E) and Prim is O(V log V), so Kruslak wins.
And when the Graph is dense(E is close to V^2-1), Prim is O(V^2 log V^2) and Prim is O(V^2 log V), so Prim wins.
But in most cases, you can use both algorithm without noticeable differences.
If Kruskal's algorithm was implemented using BFS to check whether adding an edge with create a cycle, what would the overall Big-O run time of the algorithm be?
It would be O(V * E + E * log E). Each BFS takes O(V) time because there are V - 1 edges in a tree(or less if the tree is not completely build yet) and it is run for each edge(V is the number of vertices, E is the number of edges). So it is O(V * E) in total. E * log E term comes from sorting the edges.