Editorial for CCC '18 S5 - Maximum Strategic Savings
Submitting an official solution before solving the problem yourself is a bannable offence.
We assume that the reader has familiarity with minimum spanning trees and knows some algorithm to efficiently compute a minimum spanning tree, like Kruskal's.
In the problem statement, we have a grid of vertices. Every edge in this
graph either goes between two vertices in the same column, or between
two vertices in the same row. Furthermore, if an edge exists in row
The problem asks us to maximize the sum of the weights of edges that we can delete from the graph such that it will still be connected. We claim that this is equivalent to computing the minimum spanning tree. If we compute a set of edges to remove such that the remaining edges leave a connected graph, this is equivalent to computing a set of edges to keep such that the chosen set comprises a connected graph and the remaining edges are to be removed. If we wish to maximize the sum of the weights of the edges that we want to remove, that is equivalent to minimizing the sum of the weights of the edges that we wish to keep, which is equivalent to computing the minimum spanning tree.
If we know how to compute the minimum spanning tree, we can compute the desired answer by computing the sum of the weights of all the edges, and subtract the weight of the minimum spanning tree.
In the first subtask, we are told that every edge in the graph has weight 1.
It is well-known that a tree with
In the second subtask, we are told that there are at most 200 pairs of columns which are connected and at most 200 pairs of rows which are connected.
We claim that this upper-bounds the number of vertices in the grid to
Since the graph has at most
In the third subtask, we are explicitly told that the number of rows and columns
is at most 200. However, the number of pairs of columns or pairs of rows that
are explicitly connected goes up to
With the larger bounds, running a minimum spanning tree algorithm verbatim
should be too slow, as the number of edges can scale to around 40 million.
However, as previously stated, rows and columns are independent. Imagine a
hypothetical grid of just one row and
To solve the problem in the general case, we need to extend the above observation. In particular, if we consider how Kruskal's works, since we're adding in edges in nondecreasing weight order, when we add in all edges of a given weight, we've effectively shrunk the grid by some number of rows and some number of columns. Therefore, we can do the following:
Keep track of how many rows and columns still need to be merged.
While there are at least two rows that need to be merged or two columns that need to be merged:
Grab the next smallest edge in the graph.
If this edge connects two columns which have not yet been merged:
Multiply the edge weight by the number of unmerged rows and merge the columns
Else, if this edge connects two rows which have not yet been merged:
Multiply the edge weight by the number of unmerged columns and merge the rows
Return the sum of the multiplied edge weights
This only requires sorting the edges, which can be done in
Comments
Another way to think about the solution to this problem is as if you're still preforming Naive Kruskal's like in the 1st subtask, but instead you're merging all edges of weight
at once (for every 
in the input), as each line of input denotes another batch of edges to connect (and then you think of a more efficient way to represent the graph after each merge operation). You still end up with the same code involving 2 DSUs though.
i dont understand the general case solution
edit: nvm i think i understand. for those who didnt understand like me:
In this problem, an edge is duplicated along all columns/rows. that means when kruskals is taking an edge, we can speed it up by making it take all the duplicated edges (since they have the same lowest weight). to prevent cycles, we merge rows and columns
Is this doable in python?
Yes.
Basically just USACO fencedin. :(
Although some aspects are similar here, the grid may not be perfect here. Consider if, in this case, there were flights from 1-3, 2-3, and 1-2. This would not be a perfect grid at all! Furthermore, considering the much larger numbers in fencedin, I would imagine that the problems have very different solutions indeed.