How can you write the condition that $$$\frac{a_u + a_v}{2}$$$ is an integer in a more useful way? Think of the parities.

You can think of the partition as associating to each $$$M$$$ character a $$$T$$$ to its left and a $$$T$$$ to its right. What's the best way to perform this assignment?

Do yourself a favor and listen to Towa-sama's singing! Here are some links to cool songs.

What is the discrepancy of the last stage? How can we make it smaller in previous stages?

Use dynamic programming.

This problem was originally going to appear in Codeforces Round 668 (Div. 2), but it was removed one day before the contest for balance reasons :P

Consider two of the strings. We can obviously achieve our goal using at most $$$4n$$$ characters. How can we save some of them?

Find a long common subsequence that has a simple structure. You'll need to involve the third string as well.

Either $$$00\dots 0$$$ or $$$11\dots 1$$$ is a subsequence of each string.

This problem was originally suggested as a 2B. It turned out to be too hard and was switched to 2C, before being further switched to 1A because it was still too hard. Some testers still believed this problem to be even harder, but we ended up deciding to have it as 1A with a larger score than usual.

Apologies to the testers who had to solve this as if it was the second easiest problem in the contest :^)

What is the general structure of an almost sorted permutation?

How many almost sorted permutations of length $$$n$$$ exist? In other words, how many ways are there to reverse subarrays?

Two options — either solve recursively in a greedy fashion or find a smart bijection.

This problem's creation has a funny story. Back when we were coming up with problems for Round 668, I (Ari) came up the following relatively simple and standard problem and shared it.



The next day, Kuroni saw the problem, but misread it and ended up solving the version that made it into this contest, which we think is a lot cooler!

One more fun fact for your consideration: This problem's name in Polygon is "sorrow".

How can we solve this problem without the restriction that the xor of all edge weights is $$$0$$$?

When does the solution to the unrestricted problem fail for the real problem?

Leave the xor sum of the weights of the unassigned edges in the spanning tree fixed. How do we minimize their sum?

Exactly one unassigned edge ends up with a non-zero weight. If we don't use all unassigned edges, which others can we use?

If the unassigned edges in the graph don't form a forest, then the answer is simply the weight of the MST where all the unassigned edges have weight $$$0$$$. Thus the interesting tests in this problem require these edges to form a forest, which means $$$m \ge \frac{n(n - 1)}{2} - (n - 1)$$$. This automatically limits the maximum value of $$$n$$$ to approximately $$$2\sqrt{m}$$$. Concretely, $$$n \le 633$$$ for all interesting tests in this problem. You can also use this to obtain a solution that runs in $$$O(m \sqrt{m})$$$, which a tester found, and which passes if implemented reasonably.

It is always possible to find the sequence.

There's a simple algorithm that fixes a point and repeatedly moves its current label to the correct position. When does it work?

Any permutation can be split into one or more cycles. What can we do to these cycles?

We would like to merge all cycles of the permutation by swapping elements in different cycles and then repeatedly move each label from a certain point to its correct location. How can we do this without intersections?

This problem was originally proposed with the points always being the vertices of a convex polygon. This allows us to do a slightly different solution where we first merge the cycles and choose the pivot afterwards by choosing a point unaffected by the previous swaps.

The reason for having $$$n = 2000$$$ in this problem rather than a larger $$$n$$$ like $$$10^5$$$ is because of the validator: it is essential to not have three collinear points in this problem, and I don't know how to check this for large $$$n$$$. The small $$$n$$$ also makes the checker much easier to write, though it's possible (albeit tricky) to write a checker that works in $$$O(n \log n)$$$.

Regarding the number of operations used: The solution described in the editorial uses approximately $$$\frac{3}{2}n$$$ operations in the worst case when the permutation consists of cycles of size $$$2$$$. The minimum number of operations is lower bounded by $$$n - 1$$$ by combinatorics reasons when the permutation is a single cycle. Moreover, by Euler's formula, we have an upper bound of $$$3n - 6$$$ operations for any valid sequence, which goes down to $$$2n - 3$$$ when the points are the vertices of a convex polygon. I don't know of a solution that uses $$$cn$$$ operations for some $$$c < 3/2$$$, nor do I know of a general test case where it can be proven that at least $$$cn$$$ operations are needed for some $$$c > 1$$$, so I'd be really interested in seeing either.

During the process, we will repeatedly push the same label down until we no longer can. What happens at this point?

Look at the children of a particular vertex. What can we say about the ones that are fully pushed down in relation to the ones that aren't?

For each node, the order of the labels of its children stays fixed.

How can we use the previous observations to identify the state of the process?

This problem was inspired by a wrong solution to 1477D - Nezzar и тайные перестановки, but it seems that knowing that problem beforehand doesn't help at all to solve this one.

Start by solving the problem for $$$q$$$-encodings only.

We can get an encoding by including every possible edge. Which of them can we exclude?

What does the previous observation look like from the perspective of a single vertex?

We need to solve the full version now. For a vertex $$$u$$$, how do the endpoints of its outgoing edges change when we add a new interval?

How can we use the previous observation to characterize edges becoming redundant more concretely?

Use Mo's algorithm on the input intervals to find the relevant edges.

Huge shoutouts to tfg who came up with one of the key steps of the solution! Including this problem probably would have not been possible without him. ❤️