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.

#### 916A - Jamie and Alarm Snooze

idea: STommydx, preparation: southball

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.

#### 916B - Jamie and Binary Sequence (changed after round)

idea: southball, preparation: STommydx

Work in progress!

#### 916C - Jamie and Interesting Graph

idea: STommydx, preparation: STommydx

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.

#### 916D - Jamie and To-do List

idea: STommydx, preparation: STommydx

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.

#### 916E - Jamie and Tree

idea: longhuenchan, preparation: longhuenchan