*CONTEST HAS ENDED!* You can find the solutions in the archive.

Hm, the link's acting strange: it was written correctly in HTML, but http://codeforces.net/ was added before it when displayed on the page. Adding http:// in it solves the problem.

Shit happens. I had an onsite competition during CF round 248.

Maybe you could write an alternative one later? It's already bad enough when there aren't multiple dates for exams.

+8 but no one reply with teams? Well I'll start :D

My team: Zenith

Members: I_love_Hoang_Yen flashmt ngfam_kongu

Me team: TrailBlazers

Members: asdoc nishad94 xennygrimmato

I think author can start adding teams to the main post.

MSU Trinity:

Zlobober, sankear, malcolm.

team: cutie, dropout & useless woman

Members: vadimmm, Rubanenko, baba_beda

Havka-papstvo Egor, pashka and Petr

It's best to write right to the official contact mailbox — if it doesn't get read there, then it's hopeless anyway :D

I'll try to dropbox or something the statements and archive when they're available and I download them, at least.

They allow to download full package (problem set, in files, etc.) before contest starts and after that just wait for a short text password. It's easy and we don't have any problems with that (this and previous year)

The solutions have been published already. Short idea: fix a vertex; we need to assign a binary string to each son of this vertex, so that the sum of (substring length * son's subtree size) is minimal; the optimal solution is known as Huffmann encoding.

As I said: the solutions have been published... I don't know, anyway :D

They made a preliminary version of the booklet available: http://ipsc.ksp.sk/2014/real/solutions/booklet.pdf

Nowadays, most contests only set problems with fancy efficient algorithmic solutions. Maybe the art of writing good brute force solutions is getting lost :)

Well, we had first 100 millions digits of pi. So I got 46K rows, which was enough to solve F1, but then I figured out that we could group rows into triples, which could solve F2, by iterating over 3 triples. But, of course, with 46K rows my triple computation was taking too long and I didn't thought of reducing 46K to 1K (like in solution).

So, indeed, sometimes less is better.

The piped programs run in parallel, not sequentially. The pipe can be seen as a temporary buffer. On my Linux, the size of this buffer is 64 kB. Roughly, it works as follows: whenever a program wants to read from an empty pipe or write into a full one, it is suspended until it can do so. In this way, you get a simple synchronization between the piped programs:

• whenever cat easy.in writes a bunch of data, the first bunzip2 reads it
• whenever the first bunzip2 reads an entire compressed block of data, it decompresses it and outputs the result
• detto for the second bunzip2
• tr operates character by character, so whatever it reads, it outputs immediately

So there never is the entire unpacked file in memory anywhere. At any moment, each of the bunzips only sees a small part of the file it decompresses.

It's pipe technology. Every input/output happening in three inner pipes can be made using temporary buffer of little size (64kb on linux by default). For example, cat easy.in writes 64kb of output then freezes until bunzip2 starts reading this buffer producing his output tp the next pipe and so on.

The main idea is that cat, bunzip2 and tr are stream-processing algorithms that need only O(1) of input data to produce O(1) of corresponding output data.