I think that people disagree with you

I agree. B and C probably should've been flipped but that says nothing about the quality of B. I think it was a great problem.

For me, B is one of the best Div2 problems in 2022 so far. I want more of these problems.

I don't know if I'd say I like problem B. I will say that I audibly laughed out loud when I realized the solution to B.

I agree!!

its a mastapiece!!

This problem has a bit of a similar statement, but the solution and the idea are very different.

oh no ! ! !

i hope you will recover from this very soon . . .

this is

so

sad . . .. . . ..

Do you know why your solution was hacked? Seems ok to me.

I think they maybe forget to judge (k==1) in problem A. :(

This is the first time I get FST :D I struggled to understand the problem and missed that case

Damn I was really close. Only missed the last condition :')

I cant figure out, why this solution is giving Idleness limit exceeded on pretest 1 — https://codeforces.me/contest/1634/submission/145464144

exactly the same thing I was trying, would have got AC only if I didn't give up so early :(,

here is my code for atmost 2n-4 queries but using almost no case work

Can you tell me, what's wrong in my code Thanks in advance!

If A[i] is odd, then regardless of which operation they choose, their number will change parity. If A[i] is even, then regardless of which operation they choose, their number will stay the same parity. x and x+3 are different parity, so regardless of what operations they choose, they will remain different parity. Check the parity of x compared to the parity of y after going through k odd numbers.

Since XOR and SUM(or addition) have same effect on parity

• odd + odd = even

• even + even = even

• odd + even = odd

Hence after performing all the operations on input x there must be some parity of the result that should be same as parity of given output. Say after performing all the operations on x we get the result as odd number so output y given in the question must also be odd hence (sum(a) + x + y)%2 == 0 . And Why is it sufficient to check just the parity? Because it's given in the problem that answer always exist and parity of (x + 3) is different.

In this problem, if the answer is not Alice, it must be Bob (Jury guarantees). Vice versa.

The + and $$$\oplus$$$ operations have one thing in common: the parity of the res of A + B or A $$$\oplus$$$ B will be opposite with A only if B is an odd number. Visually:

So we can count the odd numbers in the input array. If the number of odd numbers is an odd number, the parity of the final result will be opposite to the starting.

If the number of odd numbers is odd, then the parity of the starting number and ending number must be different. So if $$$x$$$ and $$$y$$$ have the same parity, it's impossible to let Alice win. Then the answer will be Bob.

On the contrary, if the number of odd numbers is even, the parity of the starting number and ending number must be the same. So if $$$x$$$ and $$$y$$$ have different parity, it's also impossible to let Alice win. Therefore, the answer is also Bob.

For other conditions, Alice will win.

Your account has no submissions in the past two weeks, so evidently, you're outing yourself for competing with an alt in this round. That also makes it impossible for anyone to look at your submission and figure out what was going on.

But besides that, I'm not sure why it's the authors' fault that you chose a slow I/O method. My solution (145428158) passes comfortably using cin with the standard line of I/O optimizations.

In addition, your solution uses absurd amount of extra % operations, that are very slow when modulo is not constant.

Nowdays solutions usually requires fast io to work in time because everyone uses it. More people will send slow solutions but just with fast io and get AC if tls were oriented on slow io solutions. The fact that nlogn and nsqrtn were accepted is sad, but we can't do anything about that because these solutions are vety optimized, and we want people not struggle TOO much with linear solutions, so we can't make tl even lower. Anyway, we have pyhton solutions that works under 1 second, so cpp solutions should feel more than comfortable.

(Also, don't talk too much that you use fakes, it's kinda bannable)

Even a relatively unoptimized solution passes in 280ms, which is very comfortable:

145479475

Definitely!Just now I submitted a code with "cin" and sentences,such as "ios::sync_with_stdio(false)",to read,and then I got TLE on test 9. 145534508

Then I change nothing in my code but "cin" to an inline reading function "read()".Guess what?I got AC！ 145534597

Both my code run an algorithm about O(n) and the first submission failed because of READING!

I think the problem which can't make the code with right complexity get AC is stupid.

My motivation: the difficult part of this problem is clearly performing range Fibonacci updates, so our first order of business is to simplify the queries. One common way of simplifying range queries is to transform the array in order to turn range queries into point queries (consider, for example, the standard trick of storing the difference array instead of the original array in order to handle range updates/point queries using a BIT or standard segtree). When we perform standard range additions, the change in $$$x_n - x_{n-1}$$$ is zero for points in the middle of the array; in this case, we see that for points in the middle of the update, the change in $$$x_n - x_{n-1} - x_{n-2}$$$ is zero. Therefore, after performing the given transformation, the range updates influence only a few points of the array, which is what we hoped to achieve.

Python i/o

There are 6 if conditions when eliminating non-zero elements. There's a typo in 2 of your if conditions, the third and fourth one. (You seem to have accidentally swapped the v.push_back(...) line of these 2 blocks).

I think they chose x+3 in order to make the solution not so obvious.

why would they want to make it more solvable you have to do this thing....

We had 3 options for this number: $$$x + 1$$$, $$$x + 3$$$ and $$$x^2 - 1$$$. Third one tricks you with $$$x^2-1 = (x-1)*(x+1)$$$, so we decided it'll be too hard. We thought that with $$$x+1$$$ problem becomes easier than we want, because it forces you to think about a parity. So finally we decided to pick $$$x+3$$$ as "the golden mean". After contest I can say, that it was better to put $$$x+1$$$ instead of $$$x+3$$$, but we really didn't expect that problem B will be that hard, sorry for this.

1,1,2 have mean of 1.5

l=1 r=2 i=1 (1+2)/2 is not an integer

(x+y)%2 == (x xor y)%2 so whatever you do doesn't matter at the beginning alice and bob have numbers with different parity so at the end also they will have numbers with different parity hence only one of these can be winner

No I guess

Loved B problem, so simple but did not got during contest

Hey, I had the same idea but didn't get it to work during the contest. I have thought about it and am starting to feel convinced that this cannot always work i.e. it not possible to find the max and min of the first four elements reliably. For this, consider the first 4 numbers to be 1, 1, 2, 2. Note that there are exactly 4 possible queries on these 4 numbers (each query leaving out a different number). Moreover, each query must contain a 1 and a 2 which means that each query returns 1. So no matter how your code uses the information of your 6 queries (each of them would return 1), there must be a permutation of 1, 1, 2, 2 such that your min and max both point to 1s (or both point to 2s).

I personally failed because of this issue on test 5. Since you passed all tests I am wondering whether my argument has some flaw. Or maybe not all permutations were actually checked in test 5?

You're right, will fix