I would like to take this opportunity to express my deepest apology to all of you who take your own precious time to participate in this unrated round. Also, apologies to vintage_Vlad_Makeev who really helped a lot in preparing the round and MikeMirzayanov who helped to host the round, I did not do a good job in managing the round. As the main author of this round, I'm undoubtedly responsible for the mistake that not writing a brute force solution to test the correctness of the intended solution. It is my responsibility to make sure everything is right before the round starts. I am really sorry that the round must be unrated to ensure fairness to all contestants.
I hope all of you can learn something from the contest. Do not claim a greedy solution absolutely correct (like me :C) unless you have proved it. On the bright side, I'm really glad that some of you found problem D and E interesting as said in some comments in the announcement blog post. I admit that problem D may seems to be a quite standard data structure problem but we think it would be fun for less experienced contestants to think how to put the concepts learnt together.
Just a little unimportant fact: The original div2B problem was a harder data structure problem which involves a slightly complicate mathematical proof (which the current one doesn't have :C). We replaced it because it is too difficult for div2B as the coordinator suggested.
Let's use brute force the find the answer. We first set the alarm time as hh: mm and initialize the answer as 0. While the time is not lucky, set the alarm time to x minute before and add 1 to the answer.
Why does this solution run in time? As x ≤ 60, hh decrease at most 1 for every iteration. Also, after at most 60 iterations, hh must decrease at least once. All time representation that hh = 07 (07:XX) is lucky so at most 24 times decrement of hh will lead to a lucky time. Therefore, the max. number of iteration possible is 24 * 60 = 1440 which is very small for 1 sec TL.
In fact, the largest possible answer is 390 where x = 2, hh = 06 and mm = 58.
The main idea of the solution is 2x = 2·2x - 1, that means you can replace 1 x element with 2 (x - 1) elements. To start with, express n in binary — powers of two. As we can only increase the number of elements, there is no solution if there exists more than k elements.
Let's fix the y value first. Observe that we can decrease the y value only if all y can be changed to y - 1. So we scan from the largest power and try to break it down if doing so does not produce more than k elements. After y is fixed, we can greedily decrease the smallest element while the number of elements is less than k.
First, observe that only n - 1 edges is required to fulfill the requirement, so we will make the other m - n + 1 edges with a very large number so they would not contribute to the shortest path or the MST. Now, the problem is reduced to building a tree with prime weight sum and two nodes in the tree have prime distance.
Recall that a path graph is also a tree! If we join (i, i + 1) for all 1 ≤ i < n, the shortest path will lie on the whole tree. We are left with a problem finding n - 1 numbers that sums to a prime. Let's make 1 edge with weight p - n + 2 and others with weight 1. Choosing a prime slightly larger than n (e.g. 100003) will fulfill requirement for all cases.
Let's solve a version that does not consist of undo operation first. The task can be divided to two parts: finding the priority of a string and finding the rank of a priority. Both parts can be solved using trie trees. The first part is basic string trie with get and set operation so I will not describe it here in details. The second part is finding a rank of the number which can be supported by a binary trie.
To support the undo operation, observe that each operation only add at most 31 nodes to the trie trees. Therefore, we can make use the idea of persistent data structure and store all versions by reusing old versions of the data structure with pointers. Remember to flush the output after each query operation.
As pointed out by some of you, there exists alternative solutions using persistent dynamic segment trees.
longhuenchan is working hard for it!