ACM ICPC World Finals 2017
Disclaimer This is an unofficial analysis of some possible ways to solve the problems of the ACM ICPC World Finals 2017. They are not intended to give a complete solution, but rather to outline some approach that can be used to solve the problem. If some of the terminology or algorithms mentioned below are not familiar to you, your favorite search engine should be able to help. If you find an error, please send an e-mail to austrin@kth.se about it.
— Per Austrin and Jakub Onufry Wojtaszczyk
The major but actually not that big change this year was the addition of Python as an available language in the Finals. This is a major change in the sense that it has taken several years to put into action (because changing the World Finals rules is a very slow process), but not that big in the sense that it actually has a pretty small impact on the practicalities of the contest.
Congratulations to St. Petersburg ITMO, the 2017 ICPC World Champions!
In terms of number of teams that ended up solving each problem, the numbers were:
| Problem | A | B | C | D | E | F | G | H | I | J | K | L |
| Solved | 35 | 8 | 105 | 31 | 127 | 123 | 18 | 0 | 127 | 1 | 15 | 27 |
| Submissions | 710 | 37 | 255 | 311 | 191 | 174 | 33 | 18 | 137 | 14 | 99 | 150 |
In total there were 617 Accepted submissions, 1279 Wrong Answer submissions, 164 Time Limit Exceeded submissions and 69 Run Time Errors, and 16 Compile Errors (though these do not give any penalty). The most popular language was (as usual) C++ by a wide margin: 1946, trailed by Java at 111, Python 3 at 8, and C at 2.
About Python: Ultimately, Python did not get a lot of submissions (but more than C did!), and only from a single team, meaning that this was the only language where the judges wrote more solutions than the teams did. Whether this is because it was a new feature this year (which is still in the process of trickling down to regionals), or whether Python will remain unpopular among ICPC World Finalists, remains to be seen. Teams had the option of submitting either in Python 2 using the pypy interpreter, or in Python 3 using the standard CPython interpreter. For each problem below, we’ll list the extent to which the judges had written Python solutions (whether there were Python solutions in both Python 2 and 3, or only in Python 2 – pypy is a lot faster than CPython – or none at all).
A note about solution sizes: below the size of the smallest judge and team solutions for each problem is stated. It should be mentioned that these numbers are just there to give an indication of the order of magnitude. The judge solutions were not written to be minimal – though some of us may have a tendency to overcompactify their code – and it is trivial to make them shorter by removing spacing, renaming variables, and so on. And of course the same goes for the code written by the teams during the contest! Previous years, the shortest team solutions have been roughly on par with (or shorter than) the shortest judge solutions for pretty much all problems. This year, there are a few where the shortest judge solutions are noticably shorter. In all of those, this difference seems to come from the shortest judge solution being in Python (which often results in fairly short code) but teams not solving it in Python.