if edge weights uniformly distributed between 0 and 1 prims or kruskals

Question

Suppose that edge weights in a graph G are uniformly distributed over [0,1).Which algorithm prims or Kruskals will be faster? I think it will be kruskals as we can take advantage of particular sorting algorithm as sorting is the bottleneck step in kruskals algorithm.

Answer 1

This is something you have to benchmark. You can use fancy data structures (van Emde Boas trees) and sorting algorithms (some counting sort variant) to drop the theoretical expected complexity of both algorithms to something closer to linear. However, it's unclear that any such trick can improve the practical performance of either algorithm. Shenanigans for improving memory locality will probably make a bigger difference.

Answer 2

The distribution of edge weights does not matter.

The main difference between Prims and Kruskals is that Prim's algorithm runs in time proportional to the square of the number of vertices, while Kruskal's algorithm runs proportionately to the product of the edge count and logarithm of the edge count. Therefore, Prim's is faster on dense graphs and Kruskal's is faster on sparse graphs.

For example, if you have 1000 vertices 3000 edges (sparse), then Prim will be K1 * 1,000,000 and Kruskal will be K2 * 24,000. But if you have 1000 vertices and 250,000 edges (dense) then Kruskal will be K2 * 3,100,000.

Answer 3

Update 2 As @David Eisenstat points out in a comment below, a much simpler way to sort in O(E) time is to do bucket sort with |E| buckets. The interval [0, 1) can be divided into |E| buckets of length 1/|E| each, numbered 0, 1, 2 ... |E|-1, and any weight w in the interval belongs in bucket number k = floor(|E| w). The expected number of weights in each bucket is O(1), hence sorting can be done with |E| insertion sorts of size O(1) each, so this gives an O(E alpha(V)) expected time Kruskal algorithm.

Note: as @G. Bach points out, the above assumes that comparison of weights and the floor(|E| w) floating-point multiplication can be performed in O(1) time, which may require a certain suspension of disbelief. For very large values of |E|, both of these operations may still have an O(lg E) contribution.

Update As G. Bach pointed out below, the bin size after the first round of radix sort with O(1) digits will always be Omega(E), so the below answer technically is not guaranteed to sort in O(E) time. However, it may be possible to choose the number of digits to be something smaller than O(lg E), perhaps O(lg lg E) or O(sqrt lg E)? So that sorting takes less than O(E lg E) expected time.

original answer

This is exercise 23.2-6 in CLRS. I'm pretty sure that Kruskal would be faster (and thus the other answers here are wrong). The distribution of weights does matter; it is the density / sparsity of the graph that does not matter.

The ordinary version is dominated by the O(E lg E) time from sorting the edge weights. When the edge weights are drawn from uniform distribution, we can perform a radix sort on the some constant number of digits, then fix collisions in contiguous subarrays with further rounds of radix sort. That's O(E) time.

Then, the rest is just ordinary Kruskal: use disjoint sets with union rank and path compression (as in chapter 23 of CLRS) the remaining work is O(E alpha(V)), where alpha(V) is the inverse Ackermann function and is <= 4 for any sane value of V (think numbers unimaginably larger than atoms in the universe).

Hence, with radix sort, Kruskal is linear O(E) with probability arbitrarily close to 1.

Note on radix sort:

The expected number of collisions (i.e. edge weights whose first 15 digits are the same) can be made arbitrarily small by using more digits, but will be O(1) provided that the number of digits is O(lg E). Of course, this would imply O(E lg E) radix sort, which would defeat the purpose. However, we don't actually need to avoid collisions entirely, only limit their size so they can be fixed in linear time.

Hence we may consider sorting some constant number of digits (like 15) in one "round" of radix sorting, which separates the array of weights into contiguous subarrays (a.k.a. "bins") all with the same 15 digits, then in the next round, sort digits 16-30 of each subarray using a second "round" of radix sorting.

A formal proof would involve similar calculations as the Birthday paradox, but since the probability of collisions decreases exponentially with the number of additional digits used, it should be possible to completely sort the above using O(1) "rounds", which would result in O(E) total sorting time.