2

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!

Indie_Cube
  • 47
  • 7

1 Answers1

1

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.

mrip
  • 14,913
  • 4
  • 40
  • 58
  • For each weight k, you can use Kruskal's algorithm or DFS to find the number of non-redundant edges of weight k. This is the number of vertices involved minus the number of connected components using only k-weight edges. Since the sets of edges for different weights are disjoint, it takes O(N) time to do this for all weights once the edges are sorted. Then you can use Kruskal's to calculate the MST(k) for the best k, also in O(N)ish time. The total time is dominated by sorting the edges in O(N log N). – Matt Timmermans Oct 18 '17 at 03:20
  • True that you can find the number of non-redundant edges of weight k for all k in O(m). But in the worst case, this number will be the same for every k, which means having to find every MST(k). And if the number of non-redundant edges is O(1), this would imply having to find Omega(m) different spanning trees. Unless there is some sort of graph-theoretic thing that can rule out certain values of k, which I don't see immediately. – mrip Oct 18 '17 at 20:10
  • If there's a tie for max number of non-redundant edges, either the highest or lowest tying weight will be the best. Which one it is depends on how you read the question (if the tying weight counts in the total, then the lowest one is best) – Matt Timmermans Oct 18 '17 at 21:34
  • I don't see why this is true. It would be true if for weights j – mrip Oct 19 '17 at 20:22
  • oops, that's true – Matt Timmermans Oct 20 '17 at 02:49
  • @mrip I've implemented your solution, but the algorithm is not fast enough. Here is the new question with the code: https://stackoverflow.com/questions/46866819/optimizing-performance-implementing-custom-algorithm-on-graphs I'd be really grateful if you could take a look. – Indie_Cube Oct 21 '17 at 18:52