Sunday, November 18, 2018

A fjzzq2002 week

TopCoder SRM 737 started the competitive Sep 17 - Sep 23 week (problems, results, top 5 on the left, analysis). There was quite a bit of challenge phase action at the top, but the final results mostly reflect the coding phase order. Congratulations to fjzzq2002 on the win!

Codeforces Round 511 followed (problems, results, top 5 on the left, analysis). eds467 was quite a bit slower than the rest of the top scorers on the first three problems, but managed to squeeze in problem E in 982 ms out of 1 second time limit and won. Well done!

Open Cup 2018-19 Grand Prix of SPb opened a busy Sunday (results, top 5 on the left). Team Past Glory has managed to solve Artur Riazanov's trademark "formal logic" problem B with a few minutes to go, cementing the first place they earned by solving other problems fast. Well done!

Finally, Codeforces Round 512 started even before the Open Cup ended (problems, results, top 5 on the left, analysis). This time fateice was actually able to solve the hardest problem E, but the five incorrect attempts they needed to pass pretests meant that they ended up below the competitors who solved problem D instead. Nevertheless, congratulations to fateice on solving E and to fjzzq2002 on the second victory of the week!

In my previous summary, I have mentioned an AtCoder problem: construct any 500 by 500 matrix of distinct positive integers up to 1015, such that if we take any two vertically or horizontally adjacent numbers a, b in the matrix and compute max(a,b) mod min(a,b) we always get the same non-zero result.

After playing with the problem a bit, one can notice that it's helpful to separate the numbers into big and small numbers (in any given pair of adjacent numbers, we call the dividend max(a,b) the big number, and the divisor min(a,b) the small number). If we put the big numbers into the black cells of a chessboard pattern, and the small numbers into the white cells of the same pattern, then in any pair of adjacent numbers one will be big and one will be small, just as we need.

Suppose we have chosen the small numbers. Then we can pick each big number as least common multiple of the adjacent small numbers plus one, and max(a,b) mod min(a,b) will always be equal to one. However, that's not yet a solution, as we need to balance two conflicting needs:
  • The small numbers need to be big enough to be distinct and for the resulting least common multiples to also be distinct.
  • The least common multiples, however, need to be small enough to fit under 1015
Naively picking the small numbers randomly, as they need to be distinct, would result in numbers on the order of 105, so the products of four numbers would end up being on the order of 1020, and the least common multiple of random numbers is not too unlikely to be equal to their product.

That means we need to find a way for the least common multiple of four numbers to be significantly smaller than their product, which means that they must have large common divisors. One way to achieve that is to pick a number ai for each row, a number bj for each column, and put ai*bj as the small numbers. Then the four small numbers surrounding a big number at position (i,j) are ai-1*bjai+1*bjai*bj-1, and ai*bj+1. They have quite a few common divisors, and their least common multiple is at most ai-1*ai*ai+1*bj-1*bj*bj+1. If each ai and bj are on the order of 103 (we have 500 rows + 500 columns), the product of six such numbers is on the order of 1018, two orders of magnitude better than the naive approach but still not good enough.

We can notice that among the above four numbers only ai and bj were repeated, thus contributing to the reduction of the least common multiple, while ai-1ai+1bj-1, and bj+1 only appeared once; this suggests a way to improve the solution: instead of assigning numbers to rows and columns, we need to assign them to diagonals containing small numbers. Each small number is at intersection of two diagonals, and we still have just 1000 diagonals in total. Since each big number is surrounded by only four diagonals, its least common multiple will be equal to a product of only four diagonal numbers, and thus be only on the order of 1012.

Since we need all products and least common multiples to be distinct, we can't actually assign numbers from 1 to 1000 to the diagonals, but we can take the first 1000 prime numbers, first 500 to diagonals of one kind, and next 500 for the other kind. The 1000-th prime number is 7919, the 500-th prime number is 3571, so our least common multiples will not exceed 7919*7919*3571*3571 which is less than 1015, and the diagonal numbers being distinct primes guarantees that all numbers in the matrix will be distinct, so we're done!

I have also mentioned an Open Cup problem in the previous summary: the judging program has a hidden string of 1000 digits, each either 0 or 1. In one query, you ask about a segment [l,r], and the judging program returns one of the two things, each with probability 50%:
  • the number u of 1s in the given segment
  • a uniformly chosen random integer between 0 and r-l+1 that is not equal to u.
In other words, with probability 50% the judging program gives an incorrect answer to your query. Your goal is to reconstruct the hidden string using at most 18000 queries, with one more important restriction: you are also not allowed to ask the same query twice.

This problem has been discussed quite extensively in the post-match discussion (this is problem E), including my own solution sketch, so I will refer interested readers there :)

Thanks for reading, and check back for more!

Thursday, November 15, 2018

An interactive week

AtCoder has returned with its Grand Contest 027 during the Sep 10 - Sep 16 week (problems, results, top 5 on the left, my screencast, analysis). There was a pretty tense fight for the second place with cospleermusora getting problem B accepted with less than a minute remaining; but tourist's victory was not really in doubt as he finished all problems with 25 minutes to spare. Congratulations to both!

I've really enjoyed solving problem D (the choice of constructive problems for this blog is becoming quite a pattern, isn't it?): you need to construct any 500 by 500 matrix of distinct positive integers up to 1015, such that if we take any two vertically or horizontally adjacent numbers a, b in the matrix and compute max(a,b) mod min(a,b) we always get the same non-zero result.

The second Open Cup stage, the Grand Prix of Udmurtia, followed on Sunday (results, top 5 on the left). Team Havka-papstvo had dug themselves into a hole thanks to having a lot of incorrect attempts, then marvelously escaped with just 8 minutes remaining by solving the most difficult problem. Congratulations on the victory!

The Grand Prix of Udmurtia was a pioneer of interactive problems in the past, and this incarnation had four of those, too. Problem E went like this: the judging program has a hidden string of 1000 digits, each either 0 or 1. In one query, you ask about a segment [l,r], and the judging program returns one of the two things, each with probability 50%:
  • the number u of 1s in the given segment
  • a uniformly chosen random integer between 0 and r-l+1 that is not equal to u.
In other words, with probability 50% the judging program gives an incorrect answer to your query. Your goal is to reconstruct the hidden string using at most 18000 queries, with one more important restriction: you are also not allowed to ask the same query twice.

In my previous summary, I have mentioned another problem with segment queries: there's a hidden integer between 1 and 1018. You can make queries, and in one query you give a segment [l,r] and the judging program tells you whether the hidden number lies in that segment. In case it does, and your segment has length 1 (l=r), you win. After each query, the hidden number can change a bit — more precisely, by at most k=10. These changes do not depend on your queries — in each testcase the sequence of changes is always the same. You have at most 4500 queries to win.

If the hidden number did not change, we would do a binary search: by querying the segment [1,m] we can compare the hidden number with m, so if we knew that our number was within some segment [a,b] before our query, we would narrow it down to either [a,m] or [m+1,b] after this query, and determine our number after at most ceil(log(1018))=60 queries.

When the hidden number changes under the hood, we need to adapt this approach: now we go from [a,b] to either [a-k,m+k] or [m+1-k,b+k]. When the segment [a,b] is big, this still divides it roughly in half, so we can proceed as before. However, when it becomes small, it will actually stop decreasing, and will never converge to a segment of length 1.

So we will do the following: when the length b-a+1 of the current segment is bigger than some boundary b, we will divide it in two using the above approach. And when it's b or less, we will just pick a random number c within the segment, and send [c,c] query. With probability of at least 1/b, we will win in this case. In case we don't, our candidate segment grows from [a,b] to [a-k,b+k], and we continue as before.

It's important to pick the right value of b: if it's too big, the probability of winning in each attempt of the second kind would be too low, and we won't always finish under 4500 queries. And if it's too small, it will take too many queries of the first kind between two queries of the second kind to reduce the segment size, and we would have too few queries of the second kind and also won't finish under 4500 queries. It's probably possible to find mathematically optimal value of b, or we can take a guess (I've used b=99 during the contest) and verify that it leads to good enough probability to finish under 4500 queries.

Thanks for reading, and check back for more!

Wednesday, November 14, 2018

A too difficult week

The Sep 3 - Sep 9 week started with Codeforces Round 507 on Wednesday (problems, results, top 5 on the left, my screencast, analysis). Once again the hardest problem was not solved during the round, and thus it all came down to the speed on the first four problems. Um_nik was considerably faster than the competition, finishing the four problems under an hour, and thus got a well-deserved first place. Congratulations!

Problem B in this round added a nice twist to a standard setting. This is an interactive problem in which you need to find a hidden integer between 1 and 1018. You can make queries, and in one query you give a segment [l, r] and the judging program tells you whether the hidden number lies in that segment. In case it does, and your segment has length 1 (l=r), you win. So far this is a classical binary search problem.

Here comes the twist: after each query, the hidden number can change a bit — more precisely, by at most 10. These changes do not depend on your queries — in each testcase the sequence of changes is always the same.

Can you see how to adapt the binary search for this setup? You have at most 4500 queries to win.

On Sunday, the new season of the Open Cup kicked off with the Grand Prix of Zhejiang (results, top 5 on the left). This will most likely be the most brutal contest of the year :) As I understand, this was the first "big" contest set by Yuhao Du, and the scoreboard reminds me of my own first Petrozavodsk contest, or my second TopCoder SRM. Team japan02 chose the solvable problems well and earned the victory with quite some margin. Well done!

Thanks for reading, and check back for more!

A plus four week

Codeforces hosted two rounds during the Aug 27 - Sep 2 week. AIM Tech Round 5 took place on Monday (problems, results, top 5 on the left, analysis). All problems were solvable this time for LHiC and OO0OOO00O0OOO0O00OOO0OO, but Mikhail was considerably faster of the two. Congratulations on the win!

Manthan, Codefest 18 was the second Codeforces round of the week (problems, results, top 5 on the left, analysis). The contest really came down to the wire, with the top three participants all completing the problem set with just a few minutes to go. Tourist was just a tiny bit faster with the easier problems, and thus earned the victory. Well done!

This week also marked the end of the summer Petrozavodsk training camp (results, top 5 on the left), the 9-contest event for top Russian and some other ICPC teams to practice before the new season. Given that the second-placed team in those standings is not actually going to participate in official ICPC contests this year, the gap between the first team (current ICPC World Champions) and the rest of the field is daunting, even though it's only August yet :)

In my previous summary, I have mentioned a TopCoder problem: you are given a 10x10 grid and can place at most 150 unit cubes onto it. A cube can be placed onto a cell of the grid, or on top of another cube. Given a number s between 1 and 500, you need to place the cubes in such a way that the surface area of the resulting figure (the total number of sides of the cubes that do not touch the grid or other cubes) is equal to s, or report that it's impossible.

The approach I will describe is a very typical one for such "constructive" problems. Suppose we have found the solution for some value of s. Let's take one extra cube and put it on top of an existing one. This will increase the surface by four (five new sides appear, and one old one is covered), so we'd get a solution for s+4. We can now apply the same trick to get a solution for s+8, s+12 and so on.

Since we spend one cube to increase the surface by 4, and 150*4 is significantly bigger than 500, we won't run out of cubes.

Now the only task that remains is to find out the smallest possible figure for each remainder of s modulo 4. This can be done by analyzing a few cases by hand: it turns out the minimum solvable s for each remainder are 8, 5, 10 and 11.

During the round I've initially discovered another induction idea: just placing a new cube on the grid in such a way that it's disconnected from the rest adds 5 to the surface, so I've tried to build a similar solution modulo 5. However, in that case we do run out of space as we can have at most 50 independent cubes on the 10x10 grid, and 50*5 is less than 500.

Thanks for reading, and check back for more!

Tuesday, November 13, 2018

A 250+ week

The Aug 20 - Aug 26 week was very calm compared to the previous ones, with just the TopCoder Open 2018 Online Wildcard Round on Saturday (problems, results, top 5 on the left, parallel round results, analysis). ACRush, Egor and Stonefeang were the only participants to solve all three problems, but ACRush and Egor were almost twice as fast in solving the hardest one, thus qualifying to the TCO onsite with a 250+ point margin. Well done!

The easy problem in this round was cute. You are given a 10x10 grid and can place at most 150 unit cubes onto it. A cube can be placed onto a cell of the grid, or on top of another cube. Given a number s between 1 and 500, you need to place the cubes in such a way that the surface area of the resulting figure (the total number of sides of the cubes that do not touch the grid or other cubes) is equal to s, or report that it's impossible.

Thanks for reading, and check back for more!

A birdie week

TopCoder SRM 736 started the Aug 13 - Aug 19 week (problems, results, top 5 on the left, my screencast, analysis). This was the first round under the new system in which one can qualify for the last online round and even to the onsite round of TopCoder Open 2019 by placing well in all SRMs in a quarter. rng_58 has claimed the early lead in that leaderboard by winning the SRM by less than one full point!

Codeforces then held two rounds based on VK Cup Finals problems, starting with Round 504 on Friday (problems, results, top 5 on the left, analysis). Just as in the official round, the hardest problem remained unsolved, but this time the winner was determined on challenges. ko_osaga found 9 opportunities and got a clear first place as the result. Well done!

Facebook Hacker Cup Round 3 on Saturday selected the 25 lucky finalists going to Menlo Park (problems, results, top 5 on the left, analysis). Xiao was quite a bit faster than the rest of the pack, qualifying to the onsite finals in style. Congratulations to Xiao and to all finalists!

Finally, another VK Cup-based Codeforces Round 505 wrapped up the week (problems, results, top 5 on the left, analysis). Once again the hardest problem remained unsolved, and once again it took solving all remaining problems plus finding a few challenges to earn a victory — and Swistakk did just that.

Thanks for reading, and check back for more!

A Toronto week

The Aug 6 - Aug 12 week was the Google Code Jam final week, onsite in Toronto. Distributed Code Jam 2018 Finals has opened the event on Thursday (problems, results, top 5 on the left, analysis). The contestants pursued wildly varying sets of problems, but in the end only Radewoosh, kevinsogo, tczajka and fagu could solve more than one full problem. Congratulations to all four, and especially to Radewoosh on the win!

The more traditional Code Jam 2018 Finals followed a day later (problems, results, top 5 on the left, analysis). Once again the sets of problems of the top contestants were very different, but this time only one participant managed to get three full problems: Gennady.Korotkevich. Congratulations on the victory!

Codeforces Round 503 took place on Saturday (problems, results, top 5 on the left, analysis). This time it was top four participants on four problems, with Marcin_smu barely claiming the first plce thanks to having only one pretests failure compared to Radewoosh's five. Well done!

Finally, VK Cup 2018 Final onsite in St Petersburg wrapped up the week on Sunday (problems, results, top 5 on the left). The heavy pre-round favorite "Нижний Магазин SU: BZ" was a lot faster than everybody else to solve the first five problems, but the system test failure meant that they had to settle for third. Team "120 Minutes Adventure" was more careful and thus claimed the victory. Congratulations!

Thanks for reading, and check back for more!

Friday, November 2, 2018

A unit week

The Jul 30 - Aug 5 competitive week started early with Codeforces Round 500 on Monday (problems, results, top 5 on the left, analysis). There were a few strategy options on the table, as the last two problems had the same point value and some people went for E and some for F: E turned out to be the right choice. Congratulations to Um_nik on the win!

Facebook Hacker Cup 2018 Round 2 followed on Saturday (problems, results, top 5 on the left, analysis, my screencast). Getting into the top 200 was the main goal, but there was some competition for the top spots as well, where Alex was a bit faster than everybody else. Well done!

In my previous summary, you are given a program for a drawing robot consisting of at most 250000 commands. Each command is either F "move forward by 1 unit, drawing a line", L "turn left by 90 degrees", or R "turn right by 90 degrees". The drawn polyline splits the plane into multiple regions, some finite, some infinite. Your goal is to return the list of the areas of all finite regions.

There's a somewhat well-known approach to the general problem of finding faces of a planar graph which is described in the official analysis. However, I've used the specifics of the problem and went with a different approach that I found less bug-prone.

Let's imagine the plane as a grid, split the polyline into unit segments, and look at the vertical unit segments for now. Every row of the plane will be split into two infinite blocks plus some finite k times 1 blocks by the vertical unit segments. The overall number of finite blocks is at most 250000.

Now let's put those blocks into a disjoint-set data structure, and merge the blocks that are adjacent vertically. In order to find the latter, we need to iterate over pairs of adjacent rows with two pointers, and not forget to take the horizontal polyline unit segments between those rows into account.

While the general planar graph algorithm is not harder than this one, I found that this approach allows to sidestep all corner cases, for example: what if there is a vertex of degree 1? What if there's more than one connected component of the polyline (not possible in this problem)?

Thanks for reading, and check back for more!

Wednesday, October 31, 2018

A week of 14

The Jul 23 - Jul 29 week warmed up with Codeforces Round 499 on Thursday (problems, results, top 5 on the left, my screencast, analysis). Without taking the challenges into account the top of the scoreboard would be quite packed, but the challenges are of course taken into account, skyrocketing Kostroma and cki86201 to clear first two places. Well done!

The main event of the week took place on Saturday, with TopCoder Open 2018 Round 4 selecting 14 finalists that would go to Texas (problems, results, top 14 on the left, parallel round results, my screencast, analysis). Both harder problems were approachable, but nobody was able to get all three, resulting in a fairly diverse scoreboard. Kankuro was still considerably faster than everybody else,
and has also cemented his lead with a successful challenge. Congratulations to Vladislav and to everybody who qualified for the onsite round!

I found the medium problem in this round quite educational, if a bit standard. You are given a program for a drawing robot consisting of at most 250000 commands. Each command is either F  "move forward by 1 unit, drawing a line", L "turn left by 90 degrees", or R "turn right by 90 degrees". The drawn polyline splits the plane into multiple regions, some finite, some infinite. Your goal is to return the list of the areas of all finite regions.

Thanks for reading, and check back soon for the solution!

Monday, October 29, 2018

A decision tree week

The Jul 16 - Jul 22 week provided the second and last chance to progress to the round of 100 in the TopCoder Open 2018, with 50 more advancers chosen in Round 3B (problems, results, top 5 on the left, parallel round resultsanalysis). qwerty787788 was the only one to solve all three problems correctly, and thus won the first place with quite a margin — congratulations to Borys and to everybody who advanced!

Facebook Hacker Cup 2018 Round 1 took place over the weekend of that week (problems, results, top 5 on the left, analysis). Being fast was not a requirement this time, as the penalty time did not factor into advancement, but of course a competition is always a competition :) Congratulations to Kevin (are you ksun48?..) on the win!

In my previous summary, I have mentioned a very nice AtCoder problem: two players play a game on an array of integers ai with at most 300000 elements. The players make alternating turns, and on each turn a player takes a number from the array that is not previously taken. Moreover, when possible, a player must take a number adjacent to a number taken by the other player on the last turn. When taking such adjacent number is not possible (on first turn, or after a player has taken a number which has both neighbors either taken or nonexistent), any number can be taken. The game ends when all numbers have been taken, and each player tries to maximize the sum of the numbers they take. Which sum will each player get if both play optimally?

Let's color all numbers with alternating colors, first one is red, second one is blue, third one is red, and so on. First, suppose the total amount of numbers is even, in other words the last number is blue. The first player has a few options:
  • Take the first number. Then the rest of the moves is uniquely determined, they will take all numbers from first to last, the first player taking all red numbers, and the second player taking all blue numbers.
  • Take the last number. In this case everything is determined as well, but the first player gets all blue numbers, and the second player gets all red numbers.
  • Take a number in the middle. In this case the second player has choices as well, so let's study this case more carefully.
Suppose the first player starts by picking a red number that is not the first number. The second player has two choices now: go left or right. If they go left, they will collect all blue numbers to the left, and the first player will collect all red numbers. Since the first number is red, the first player will be the last to move in this chain, and the second player will be able to pick any number. First key observation is that they can then take the last number, and thus collect all remaining blue numbers. So if the first player picks a red number, the second player can always take all blue numbers.

Similarly, if the first player starts by picking a blue number, the second player can take all red numbers. So the second player can always guarantee at least the minimum of the two sums: all red numbers or all blue numbers. However, the first player can force the second player to get at most that minimum (by taking the first or the last number). Hence with optimal play the second player will get exactly that minimum (and thus the first player will get the maximum of the two sums).

Note how we didn't have to explore all possibilities here — for example we didn't consider the case where the first player starts with a red number and the second player moves to the right. We don't need to: by finding an upper bound and a lower bound for the second player's score that match, we have proven that other options will not change the answer. This observation will also be key to solving the harder case, where the overall amount of numbers is odd.

When the overall amount of numbers is odd, both first and last numbers are red, and the first player can still take all red numbers by taking the first number. However, there's no way for the first player to do the opposite and take all blue numbers. Let's again consider the other options the first player has:
  • Take a red number that is not the first or last. Then the second player can still collect all blue numbers as in the even case, and since the first player can force the second player to take all blue numbers, we have matching upper and lower bounds again, and we don't need to investigate other second player's strategies in this branch.
  • Take a blue number. In this case the second player chooses a side, and takes all red numbers on that side, and then the first player is again first to play on the other (remaining) side, which once again has an odd amount of numbers.
The first player can continue picking blue numbers when they have a choice for some time, until they decide to pick a red number in some remaining segment. Then the second player will have gotten all red numbers outside this remaining segment, and all blue numbers inside this segment.

Can the first player choose this segment arbitrarily? No, since the second player decides whether we go left or right every time the first player picks a blue number. In fact, we can imagine the optimal strategy for the first player like a decision tree: we start by picking a certain blue number. If the second player takes all red numbers to the left, we are left with the right part, and will pick a certain blue number there; if we have the left part, we will pick a certain blue number there, and so on. Ultimately, each branch ends with us (first player) picking all red numbers in the segment.

Now we can notice that the decision tree structure actually does not matter much. The blue numbers used for branching in the decision tree split the other numbers into segments. In the end, the second player gets all blue numbers from one of those segments, and all red numbers from the rest. The first player can split all numbers into such segments arbitrarily, and the second player effectively gets to choose the segment it gets blue numbers from.

Note that we did not find an arbitrary strategy for both players — we have shown that the optimal strategy for them must look like this. The only remaining question is: how should the first player split all numbers into segments?

This is another cool side of the problem: after solving the "more mathematical" strategy part, the remaining "algorithmic" part is also interesting to solve! We have an array of numbers of odd length, with first, third, ... numbers colored red and the rest colored blue. We need to choose a set of blue numbers in such a way that minimizes the maximum of (sum of blue numbers minus sum of red numbers) over the segments between the chosen blue numbers.

There's a straightforward quadratic dynamic programming solution which finds the optimal way to split each prefix of our array, and iterates over all possible positions of the last taken blue number in each prefix.

In order to speed it up, we have to slow it down first. Let's add an outside binary search for the answer. Now instead of minimizing the maximum, we just need to check if there's a split such that on each segment the difference is below the threshold. This can still be done using a similar dynamic programming, for the overall runtime of O(n2*logn).

But now we can notice that in this simplified dynamic programming if position X of the last taken blue number is better than position Y for some prefix, it will be better for all bigger prefixes as well, since what happened before X/Y does not matter anymore (it just needs to be under the threshold), and the only thing that matters is the difference between blue and red numbers after X/Y. Whichever is smaller once will keep being smaller, since we add the same new numbers to both. So instead of trying all possible positions for the last taken blue number, we can try just two possibilities: the best position for the previous prefix, or just the previous blue number (which was not considered for the previous prefix because it was not there). This makes the solution run in overall O(n*logn) time.

Here is my entire solution from the contest:

int n = in.nextInt();
int[] a = new int[n];
for (int i = 0; i < n; ++i) a[i] = in.nextInt();
int s1 = 0;
int s2 = 0;
for (int i = 0; i < n; ++i) {
    if (i % 2 == 0)
        s1 += a[i];
    else
        s2 += a[i];
}
if (n % 2 == 0) {
    out.println(Math.max(s1, s2) + " " + Math.min(s1, s2));
    return;
}
int left = s1 - s2;
int right = s1 + s2 + 1;
outer: while (right - left > 1) {
    int middle = (left + right) / 2;
    long bestSoFar = s1 - s2;
    int r1 = s1;
    int r2 = s2;
    for (int i = 1; i <= n; i += 2) {
        r1 -= a[i - 1];
        long cost = bestSoFar - (r1 - r2);
        if (i < n) r2 -= a[i];
        if (cost >= middle) {
            if (i == n) {
                left = middle;
                continue outer;
            } else {
                bestSoFar = Math.max(bestSoFar, r1 - r2);
            }
        }
    }
    right = middle;
}
out.println((s2 + left) + " " + (s1 - left));

Thanks for reading, and check back for more!

Sunday, September 2, 2018

A Skyglow week

Codeforces Round 497 took place during the Jul 9 - Jul 15 week (problems, results, top 5 on the left, analysis). The last 3 problems were, shall we say, more challenging than usual: only 9 accepted solutions for C, 3 for D, and 0 for E. Yosupo was one of those 12 people, and he solved the right set of problems in the right order to claim the first place. Congratulations!

Just a day later, AtCoder held its Grand Contest 026 (problems, results, top 5 on the left, analysis). yutaka1999 was unbeatable on the day, finishing all problems more than half an hour before anybody else. Congratulations on the dominant win!

I found the last problem very nice: two players play a game on an array of integers ai with at most 300000 elements. The players make alternating turns, and on each turn a player takes a number from the array that is not previously taken. Moreover, when possible, a player must take a number adjacent to a number taken by the other player on the last turn. When taking such adjacent number is not possible (on first turn, or after a player has taken a number which has both neighbors either taken or nonexistent), any number can be taken. The game ends when all numbers have been taken, and each player tries to maximize the sum of the numbers they take. Which sum will each player get if both play optimally?

Thanks for reading, and check back for the solution!

A week without centroids

The Jul 2 - Jul 8 week upped the stakes in the TopCoder Open 2018 race: only the top 50 would advance from Round 3A on Saturday (problems, results, top 5 on the left, parallel round results, analysis). With the hard problem having a much simpler solution than the one the problemsetters have anticipated, the scores were a lot higher than usual, and seeing this simple solution quickly was the key to victory. Congratulations to Blue.Mary on the win!

In my previous summary, I have mentioned a Codeforces problem: you are given a tree with n<=2000 vertices. How many cycles of length 1, 2, ..., k (k<=75) does it have, modulo 998244353? A tree does not have simple cycles, so we're interested in non-simple cycles of course. Two cycles that differ only by choosing the starting point and direction are still considered different.

The general approach is somewhat on the surface: let's do dynamic programming that would count said cycles for each subtree. When we're processing the subtree rooted at some vertex v, each cycle either doesn't touch v, in which case it's a cycle in one of the smaller subtrees, or it does touch v, in which case it looks like v->u (some child of v)->some cycle passing through u->u->v->...

In order to be able to count the cycles of each length passing through v, we need to know the number of cycles of each length passing through each of its children, so we need to compute two things in our dynamic programming for each subtree: the total number of cycles, and the number of cycles passing through the root of the subtree.

This gives a rough overview of the solution, but the details of the dynamic programming transition are still unclear: how do we make sure we correctly count the cycles differing only by the starting point?

Each cycle passing through v can decomposed into blocks between consecutive occurrences of v in the cycle. Each such block is obtained by taking a cycle passing through some child u of v, and adding a v->u edge in the beginning and a u->v edge in the end, so for a child cycle of length x the block has x+2 edges.

Actually, to make the previous statement entirely correct in the world where cycles differing by the starting point are considered different, we need to adjust it a bit: replace "cycle passing through v" and "cycle passing through u" by "cycle starting and finishing in v" and "cycle starting and finishing in u". Then our dynamic programming checks out, and we can find the answer for v given the answers for all its children by first adding up the answers for children to obtain the number of blocks of each size, and then doing an inner knapsack-style dynamic programming that counts the ways to combine the blocks.

However, since we have changed the definition of what we compute, we can no longer just add up those numbers to get the overall number of cycles in the tree. Here comes the most magic part of the solution in my opinion: in order to get the overall number of cycles in the subtree passing through v from the number of cycles that start and end in v, we need to just multiply that number by the size of the last block in the inner knapsack dynamic programming!

Indeed, this way we count the ways to choose the starting point within the last block. Why must it be within the last block? Because the cases where the starting point is in another block will be counted when we consider a cyclical shift of the blocks. To look at this from another angle, any cycle passing through v can be transformed into a cycle starting and ending in v by cyclically shifting it so that the first occurrence of v becomes the beginning of the cycle, and the number of ways to get each cycle doing this is equal to the size of the last block.

Here's the relevant part from my solution during the round:

static class Vertex {
    List adj = new ArrayList<>();

    public Description doit(Vertex skip, int k) {
        Description res = new Description();
        res.overallCycles = new long[k + 1];
        res.cyclesFromRoot = new long[k + 1];
        res.cyclesFromRoot[0] = 1;
        res.overallCycles[0] = 1;
        long[] singleStep = new long[k + 1];
        for (Vertex child : adj) {
            if (child == skip) continue;
            Description desc = child.doit(this, k);
            for (int i = 0; i <= k; ++i) {
                res.overallCycles[i] = (res.overallCycles[i] + desc.overallCycles[i]) % MODULO;
                if (i + 2 <= k) singleStep[i + 2] = (singleStep[i + 2] + desc.cyclesFromRoot[i]) % MODULO;
            }
        }
        for (int old = 0; old <= k; ++old) {
            long w = res.cyclesFromRoot[old];
            for (int a = 2; old + a <= k; ++a) {
                res.cyclesFromRoot[old + a] = (res.cyclesFromRoot[old + a] + w * singleStep[a]) % MODULO;
                res.overallCycles[old + a] = (res.overallCycles[old +a] + w * singleStep[a] % MODULO * a) % MODULO;
            }
        }
        return res;
    }
}

Thanks for reading, and check back for more!

Sunday, August 12, 2018

A week in memory of Leo

The Jun 25 - Jul 1 week presented the last of the last chances to progress in TopCoder Open 2018 with its Round 2C on Tuesday (problems, results, top 5 on the left, parallel round results with 2/3 shared problems, analysis). This round was ran in honor of Leopoldo Taravilse, who has tragically passed away recently. It was really sad to hear this news, and I express my sincere sympathy to Leopoldo's family and friends.

fruwajacybyk has squeezed out the first place through challenges from Min,lu and tozangezan who led after the coding phase. Well done!

Codeforces held its Round 493 on Sunday (problems, results, top 5 on the left, analysis). fjzzq2002 dominated the proceedings, solving all problems with 20 minutes to spare while everybody else could manage at most four. Congratulations on the impressive performance!

Problem D, after removing a somewhat artificial complication, boiled down to the following cute combinatorial puzzle: you are given a tree with n<=2000 vertices. How many cycles of length 1, 2, ..., k (k<=75) does it have, modulo 998244353? A tree does not have simple cycles, so we're interested in non-simple cycles of course. Two cycles that differ only by choosing the starting point and direction are still considered different.

In my previous summary, I have mentioned another Codeforces problem: you are given a prime modulo p up to 109 and two numbers u and v between 0 and p-1. In one step, you can either add one modulo p, subtract one modulo p, or take inverse modulo p. You need to obtain v from u in at most 200 steps (the solution doesn't need to be the shortest).

This problem allows many approaches, so I'd like to share a bit more how my thinking went. I've started to write down which numbers we can get in a few steps, like u+1 or 1/(u+1) or 1+1/(u+1)=(u+2)/(u+1). Then I've noticed that if we represent our current number as x/y, then the three operations we have are x->x-y, x->x+y, and swap(x,y). This has strongly resembled the Euclidean algorithm, which can go from (x,y) to (0,gcd(x,y)) using those operations. Now I had a sketch of the solution: we'll represent u as (u*k mod p)/k, then apply the Euclidean algorithm to go from u to 0. Now we do the same for v, and since all operations are reversible, we can now go from u to 0 to v.

However, the Euclidean algorithm takes a small (logarithmic) number of steps only if we have the modulo operation available. With just subtraction, it can take a lot of steps - for example, if we pick k=1, then we'll start with u/1 and need u steps to get to 0 just subtracting 1 every time. So we need to choose k wisely so that the number of steps to get from u to 0 will not exceed 100.

First I tried to find k so that (u*k mod p)/k is as close to the golden ratio as possible, as the golden ratio is the case where the Euclidean algorithm proceeds in the fastest way. However, this did not work as sometimes just being close is not enough, and on last steps we still start making too many subtractions. But then I've realized that I can just try random values of k until I find one that works, and this ended up working flawlessly.

Thanks for reading, and check back for more!

Saturday, July 28, 2018

A too simple week

The Jun 18 - Jun 24 week had Codeforces Round 492 (problems, results, top 5 on the left, analysis). I've also included myself in the standings on the left to highlight the fact that OO0OOO00O0OOO0O00OOO0OO's performance was so amazing that he got all 6 problems accepted before I got any one of those :) Well done!

Right after this round, Scott Wu and Andrew He streamed a post-contest discussion on twitch (CF post). Unfortunately the recording is no longer available, but the concept is exciting and I've enjoyed listening to a part of it.

The round had a few mathy problems, but I'd like to highlight problem E which had a more algorithmic flavor: you are given a prime modulo p up to 109 and two numbers u and v between 0 and p-1. In one step, you can either add one modulo p, subtract one modulo p, or take inverse modulo p. You need to obtain v from u in at most 200 steps (the solution doesn't need to be the shortest). Do you see a way?

Thanks for reading, and check back for more!

Wednesday, July 25, 2018

A week without automorphisms

The Jun 11 - Jun 17 week was supposed to present the last chance to qualify for further TopCoder Open 2018 rounds in Round 2B (problems, results, top 5 on the left, parallel round resultsanalysis). However, because of technical issues an extra Round 2C was added two weeks later. Those issues notwithstanding, congratulations to gs14004 on creating just enough cushion during the coding phase to withstand the challenge push from maroon_kuri, sky_love_high and FizzyDavid! sky_love_high in particular actually had 1262.53 points after four minutes of the challenge phase, which would be enough for the first place.

Codeforces had its own share of issues with Round 488 on Saturday (problems, results, top 5 on the left, analysis), this time not technical but with an incorrect reference solution for the hardest problem. It turned out that the test data was luckily correct anyway, so this ended up being a somewhat theoretical discussion that did not affect the round. Congratulations to Um_nik and Errichto on solving all problems!

In my previous summary, I have mentioned an exciting Code Jam problem. You are given a number n between 10 and 50, and need to print a connected simple undirected graph with n vertices, and each vertex having degree exactly 4. The interactor will then randomly permute the vertices of your graph and give it back to you, and you need to then restore the permutation that was used. In other words, you need to find such graph without automorphisms, and be able to identify its vertices after they're shuffled.

This is another example where there are two main ways: either solve it "on paper", or try various random-looking things at the computer until one works. Since there are only 41 possible inputs, it's quite easy to verify if an approach works or not.

It turns out that in this problem even the expected solution went the random way. First, we have to come up with a way we'll use to identify the vertices. Then, we'll try random connected graphs with all degrees equal to 4 until we can uniquely identify all vertices in one. Of course, this last step also requires some way of generating such graphs.

As a way to identify the vertices, we can use an iterative approach: initially all vertices start with the same label. Then we compute some function for all vertices that depends on the existing labels and the structure of the graph, but does not change when we permute the vertices. In case the values of the function for some vertices is different, we can update their labels to be different, and repeat the process. Eventually we need for all labels to become different.

The function we compute can't just depend on the neighbors of the node: since every node has exactly 4 neighbors, and initially they all have the same values, we will never get different function values. However, we can look further and for example check how many of those 4 neighbors are connected to each other, or what set of labels we have at distance 2,3,... from the vertex, and then one of those ideas will be enough to find a solution for all 41 possible testcases (see the official analysis for more details).

Finally, in order to quickly generate such graphs, we can also use various approaches. I find the following one the most logical: start with any such graph, and then repeatedly apply random local modifications that don't change the degrees of the vertices (again, check out the official analysis for more details).

I have also enjoyed the way this problem used the interactive problem paradigm to encode the "challenge-response" setup that is not usually seen in programming contests.

Thanks for reading, and check back for more!

Tuesday, July 24, 2018

An obtuse week

The Jun 4 - Jun 10 week was the week of the Google Code Jam: the onsite advancers were determined both in the normal and in the distributed competition.

First off, the Google Code Jam 2018 Round 3 took place on Saturday (problems, results, top 5 on the left, analysis). Somewhat surprisingly, none of the full scores stood during the system testing. Errichto.rekt and ifsmirnov lost the least points at that stage :) Congratulations!

I found the problem Name-Preserving Network really exciting. You are given a number n between 10 and 50, and need to print a connected simple undirected graph with n vertices, and each vertex having degree exactly 4. The interactor will then randomly permute the vertices of your graph and give it back to you, and you need to then restore the permutation that was used. In other words, you need to find such graph without automorphisms, and be able to identify its vertices after they're shuffled. How would you approach this one?

The Distributed Code Jam 2018 Online Round followed a day later (problems, results, top 5 on the left, analysis). Errichto.rekt was at the top for the second day in a row, thanks to being one of only two solvers of the hardest problem E. Well done!

In my previous summary, I have mentioned an unusual TopCoder problem: You are given 3n sticks with lengths a, a+1, ..., a+3n-1. You need to find any way to split them into n triples in such a way that each triple forms a non-degenerate obtuse triangle, or report that there isn't one. n is up to 500, a is an integer between 1 and 10.

There are a few principal approaches to this kind of problem (did I already enumerate those on the blog? Please share a link, and also please add ones that I missed):

  • Just solve the problem on paper, in other words come up with a direct explicit construction.
  • Solve the problem on paper in two steps a-la induction: come up with a way to solve the problem for small instances of the problem, and also come up with a way to change a solution for n to a solution for n+5 (for some value of 5).
  • Only do the second inductive part on paper, and use brute force to find solutions to small instances.
  • Also replace the inductive part with something less formal: do some kind of greedy for most of the solution, and use brute force when the remaining problem is small enough.
The official analysis suggests to use the third approach, while I went with the last one since it requires the least amount of thinking :)

I like to code such solutions as a brute force that runs even for large values of n, with the greedy part being implicit by the order the brute force tries the possibilities: since for most of the decisions, we will never have time to come back to them, the first decision we try in the brute force is effectively the greedy decision. This way I don't have to explicitly choose the boundary between the greedy and the brute force, and thus can try different ideas faster.

You can take a look at my solution from the round for more details, but in short, the ordering that worked was: as the first attempt, try to pair the smallest remaining stick with the 1/3-rd and 2/3-rd ones in sorted order, and then go from those in both directions.

Thanks for reading, and check back for more!

Sunday, July 22, 2018

An extra log week

Codeforces Round 485 got the May 28 - Jun 3 week going (problems, results, top 5 on the left, analysis). OO0OOO00O0OOO0O00OOO0OO has tried an unusual problem solving order, but it didn't really help as tourist was faster overall and got the well-deserved first place. Congratulations!

The round thread is also notable for discussions about modern problemsetting practices (search for Um_nik's replies and surrounding comments).

On Saturday, TopCoder Open 2018 Round 2A saw the top-rated participants enter the competition (problems, results, top 5 on the left, parallel round resultsanalysis, my screencast). A lot of solutions failed challenges and system test in this round, and after the dust has settled it turned out that bmerry both had the highest coding phase score, and has protected the lead very well by adding 100 challenge points. Well done!

The hardest problem in this round allowed one to get quite creative. You are given 3n sticks with lengths a, a+1, ..., a+3n-1. You need to find any way to split them into n triples in such a way that each triple forms a non-degenerate obtuse triangle, or report that there isn't one. n is up to 500, a is an integer between 1 and 10.

Finally, AtCoder Grand Contest 025 wrapped up the week on Sunday (problems, results, top 5 on the left, analysis). Only Stonefeang was able to solve all problems, and thus got a clear first place. Contestants behind him solved quite varied subsets of problems in an attempt to score most points in the limited time available, but it did not really matter in the end. Congratulations to Stonefeang!

Thanks for reading, and check back for more.