I'd be happy to help you figure out your Yandex account issues through personal messages

Also when I submit too early (less than 5 minutes after the last submit), the site tells me, that I have already submitted that code, although the submission was refused.

Ответа до конца контеста так и нет... А между тем, 2 часа "увлекательного" переписывания сабмита на C++ (с кучей memory leakов в результате) == ~+150 баллов... При ровно том же самом коде.

Скажите хотя бы, починится ли Java к обычным раундам? Или лучше сразу на плюсах писать?

Оно будет завтра. Спокойной ночи :)

Спасибо за отзыв, для нас это была первая проба пера, и мы с большим вниманием относимся к подобным замечаниям.

В генераторе должен быть код проверки существования решения. Это было бы огромным хинтом, имхо.

It is not necessary to participate in all rounds, your final result is calculated only using the rounds you have participated in.

Refer to the Rules section of the competition.

I did almost the same, but I generated matching by min-cost-flow with random edge weights. Also I didn't change color of multiple cells at once (was lazy about it :D), but did a lot of iterations. Got about ~7550 points on public testset.

Here is the gist of my method (gets around 7700+, the remaining  ≤ 100 points obtained by relatively small hacks)

Generate pairs by min-cost-max-flow with all edge costs of 1. Then fill remaining pixels greedily by adding a pixel each time such that the total score is as high as possible after that step.

Refine this solution by trying to "grow corners" — loop through all possibilities in random order (selecting random pixel, direction, and number of layers  ≤ 10 = MAGIC to grow) and apply an update as long as it improves score or there is time left. Example of "corner growth" at the bottom. Growing corners is useful because it allows to get from a square of size N × N to the one bigger, and square is the shape with the optimal "convexity", I think.

Hack that brings biggest improvement: when the test case is from the third group, in MCMF instead of making the cost of every edge 1, make cost of using pixels (i, j) such that i or j is divisible by MAGIC=5, equal to 0. In this way, the obtained set of paths is likely to be more disperse, rather than crammed all together around the line joining the squares from which the sources are generated.

.........           .........
.........           .xxxxxxx.
..xxxxxxy           .xxxxxxxy
..x                 .xx
..x            ->   .xx
..x                 .xx
..z                 ..z

Around 7700 on public tests if implemented in C++ (and 7550 — if in Java).

First, run min-cost-max-flow to match sources and targets. Add these paths to the solution, and grow them greedily, adding one cell or continuous horizontal or vertical sequence at a time (score := delta_target_function / (5 + number of cells)). Once the field is full, do a similar process of improving solution: move one cell or continuous horizontal or vertical sequence from one group to another if it increases the score (this is tricky implementation-wise, since we have to check we don't disconnect areas; I just ran full connectivity check, but maybe one can do smth smarter and faster).

Finally, there are many places where one can add randomness here: order of edges in min-cost flow, random fluctuations in greedy & final hill-climbing scores. Add all this randomness, and repeat the procedure for 2 seconds, choosing the best answer. Locally this was giving +200 points (evaluating on 1000 testcases), but on public tests Java version didn't improve much (likely because it didn't have time to do more than O(1) iterations). I didn't have time to evaluate C++ version though.

7668.32

Generate paths by min-cost-max-flow. Expand them by bfs. Then while possible to increase score do mutations of two types: 1) Take side (edge?) of some region and paint several lines near it in the same color. 2) Take side of some region and fill it with neighbour colors.
Some hacks like "we can take just part of side" or "let's check improvement after each painting" significantly increased the execution time but also helped to get up from ~7500 to 7670.
BTW, on my local tests I get ~8150.

Можете отправлять решения.

Да