It will be unofficial unrated round.

Perhaps it's built in the platform that a normal contest has to be flagged as either div1 or div2 ?!?!

For fear of too much hacking maybe.

next time try to register before starting time by 5 minutes or more.

when ur at ith index, just keep taking (or giving) the required number of matches from i+1th index.
even if i+1 doesnt contain enough, it will become negative temporarily, but later it will take whatever it needs from i+2.
this process will go on until n-1 takes (or gives) something from n. after this last operation, all boxes will contain same number of matches.

PS: be careful of integer overflow (use long long instead of int)!

If your solution has passed the pretests , it can be hacked by anyone in your room who has locked his/her solution.

Спасибо, интересно было ли подобное у кого-то еще?

My solution is brute force, which I'm not quite sure whether it's correct or not but sounds "correct enough" to worth implementing.

Let a_n be the number with n ones, so a₁ = 1, a₂ = 11, a₃ = 111, ....

Suppose we have the number n, satisfying a_k ≤ n < a_k + 1. We either try to represent n = p₁a_k + m₁ for some p₁, m₁ such that 0 ≤ m₁ < a_k, or n = a_k + 1 - p₂a_k - m₂ for some p₂, m₂ such that 0 ≤ m₂ < a_k. In other words, put as many a_k's as possible while leaving the result nonnegative, or otherwise put a_k + 1 and negate the remaining number. We then take the minimum of number of ones used in each possibility.

Thus we can induct downward, doubling the number of subproblems but reducing k by 1, or in other words cutting n by roughly a factor of 10. This gives a runtime of approximately , fast enough for our purposes. The "proof" of why we only need to test those two possibilities follows.

We're wasting ones if we include any of a_i with i ≥ k + 2; if we have some such a_i, then we need at least eleven  - a_i - 1 (or otherwise  - a_i, but that's clearly useless) to bring the value close enough to n, and there we waste i + 11(i - 1) = 12i - 11 ones just to obtain the number a_i - 11a_i - 1 = 1. So the largest a_i that might be included in n's representation is a_k + 1.

Moreover, since n < a_k + 1, we cannot have two or more a_k + 1 for a similar reason; the second a_k + 1 must be negated with eleven  - a_k. So we have at most one a_k + 1. We can thus represent n = a_k + 1 - m for some m.

Now, the only way to get rid of the first digit of n is by including as many a_k as possible, because the next alternative of including 9 a_k - 1 uses too many ones. Thus the result: either we include as many a_k as possible to n, or include as many a_k as possible to m. Because I was uncertain which of these gives quicker result, I just coded both possibilities and took the minimum.

Here's my submission: 6789561. Unfortunately it's not commented, and it's in Python which is not as popular as C++ for competitive programming. If you don't understand any, just point out and I'll try to explain.

Nice Observation !! Not sure of the reason !!

Scanf fails to read the next integer, since there is no more input. It recognizes that input is over and won't wait for it. x remains uninitialized, and s.erase attempts to remove a garbage value. The chance of it removing the actual answer is about 1 in 4 billion, so it passes all test cases most of the time.

Did you mean Editorial?

Вроде же всегда было, если посмотрел чьё-то решение в комнате, то и в итоговой таблице оно будет подсвеченным?

Не у тебя одного. Я когда ещё пытаюсь посмотреть результаты друзей, меня иногда выкидывает из системы.

Или просто после обновления страницы.

weak pretest contest more challenge contest than other contests

num = tot/n ... In python 3.2 / denotes float division even if the operands are integers.

For integer division you should use // instead of /

Float division causes some problems due to round-off errors.

i have an idea to solve this problem, but i cannot make it recursive. here is my example:

let k=34.

• 1st way: from the largest number which has the same "number" in each poistion and still smaller than k, we add up to k.

34=33+1

• 2nd way: from the smallest number which has the same "number" in each position and still larger than k, we subtract down to k

34=44-10

• 3rd way: from the smallest number 111..1 which is still larger than k, we subtract down to k

34=111-77

now we can calculate the number of 1 we need to get k by calculate the number of 1 to get each addends. of course that the 3-way can also apply to each of addends.

still, i cannot figure out when the recursive will stop. for example if k=22, obviously we have 22=11+11 and use four 1. but when k=99 we use 99=111-11-1 and use six 1. with larger k the calculation became more complex :(

There are usually no editorials for Testing rounds, you can consider this round just being a bonus to other rated rounds. You can write one though and link it as an editorial to this contest.

I think the people who tested the system are not us but them.