Блог пользователя Stepavly

Автор Stepavly, 3 года назад, По-русски

1490A - Плотный массив

Автор задачи: MikeMirzayanov

Разбор
Решение

1490B - Сбалансированные остатки

Автор задачи: MikeMirzayanov

Разбор
Решение

1490C - Сумма кубов

Автор задачи: MikeMirzayanov

Разбор
Решение

1490D - Трансформация перестановки

Автор задачи: MikeMirzayanov

Разбор
Решение

1490E - Случайная победа

Авторы задачи: Stepavly, Supermagzzz

Разбор
Решение

1490F - Уравняй массив

Автор задачи: MikeMirzayanov

Разбор
Решение

1490G - Старый дисковод

Авторы задачи: Stepavly, Supermagzzz, MikeMirzayanov, sodafago

Разбор
Решение
Разбор задач Codeforces Round 702 (Div. 3)
  • Проголосовать: нравится
  • +87
  • Проголосовать: не нравится

»
3 года назад, # |
  Проголосовать: нравится +40 Проголосовать: не нравится

Balanced Round with good and Interesting problems !!

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Can we use ternary search to solve F?

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится +8 Проголосовать: не нравится

    I think no, in order ternary search to work you would need the cost to be decreasing and then increasing as a function of C (U shape).

    But here it's more complicated it's increasing on some of the value which are number of times a given number appears, and decreasing everywhere else

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится +1 Проголосовать: не нравится

    I think you can not use ternary search on integers if there are f(i) == f(i+1).

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится +3 Проголосовать: не нравится

    You can solve it with ternary search if you erase counter duplicates. But then it is not necessary to use ternary search because the size drops to sqrt(n) and it fits in the time limit.

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится +21 Проголосовать: не нравится

    I used ternary search and it passed pretests

    • »
      »
      »
      3 года назад, # ^ |
        Проголосовать: нравится +14 Проголосовать: не нравится

      I am sure it only passed pretests because no setter considered that someone would try ternary search on a function so potentially far from having a single local minimum. You are lucky nobody hacked any similar-enough solutions during the open hacking phase.

      • »
        »
        »
        »
        3 года назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится

        Thanks for the hack, I wasn't pretty sure that it would pass systests I guess I was lucky enough

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    can anyone please tell me why this code(link )for F gives tle while this code(link) passes? Unordered map is faster on average than map right?

  • »
    »
    9 месяцев назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    No but we can do it by quadrinary search.

»
3 года назад, # |
  Проголосовать: нравится +9 Проголосовать: не нравится

For E maybe the linear solution is find largest i such that prefix_sum[i-1]<v[i]. Then everyone from that index till last can win.

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

In D, isn't the worst-case time complexity of given solution O(n^2)? Then how will it not give TLE?

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

In Problem G Once we change x = x — full_spins*s

How we can be sure that new x will be less than max(pref) and we will be able to find it using lower_bound?

  • »
    »
    3 года назад, # ^ |
    Rev. 2   Проголосовать: нравится +3 Проголосовать: не нравится

    Now we have a new problem, given x, find the first position i in the array, such that pref[i]≥x. This problem can be solved using binary search. If pref is not sorted into the array, that is, there is j, such that pref[j−1]>pref[j], then pref[j] can simply be thrown out of the array (the answer will never be reached on it).

    After assigning new value to x = x — full_spins*(sum) we can not be sure that it will be less than max(pref) and above argument is not valid then.

    E.X.

    a = [1,1,1,1,-2] x = 15

    Sol S = 2 full_spins = (15-4)//S = 11/2 = 5

    so new x = 15 — 5*2 = 5 and as max(pref) = 4 < 5 we can not find it using lower_bound()

    I think full_spins should be ceil instead of floor

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится +8 Проголосовать: не нравится

    Have you noticed how full_spins is calculated? full_spins = (x — maxPref + sum — 1) / sum, where maxPref is the maximum prefix of the array, and sum is the sum of the entire array. After full_spins turnovers, at least maxPref is suitable for us to cover the entire amount. There is a small error in editorial — you need to divide with rounding up.

    • »
      »
      »
      3 года назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      Yeah their is mistake in editorial while code is right. I didn't see the code and thought my approach would be wrong which is basically same

    • »
      »
      »
      3 года назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      I also tried to implement it based on the editorial but didn't get the correct output for the sample. I looked at the solution and I found that ceil was used instead of floor.

      So the formula in the editorial should be changed from: ($$$\lfloor \frac{x - \max_{i=0}^{n-1} pref[i]}{S} \rfloor$$$) to ($$$\lceil \frac{x - \max_{i=0}^{n-1} pref[i]}{S} \rceil$$$)

      Stepavly Can you please check this and update the editorial accordingly? Thanks

»
3 года назад, # |
  Проголосовать: нравится +5 Проголосовать: не нравится

I overlooked the constraints in problem D and ended up with an efficient solution of nlogn. :)

»
3 года назад, # |
  Проголосовать: нравится +19 Проголосовать: не нравится

Here are some video solutions to all of the problems, and a bit of hype around being 1st

»
3 года назад, # |
Rev. 3   Проголосовать: нравится +2 Проголосовать: не нравится

Linear solution(after sorting) for E:

Sort players by tokens in ascending order. The player $$$i$$$ can win if $$$a_1+\dots + a_i\ge a_{i+1}$$$ and player $$$i+1$$$ can win(player $$$n$$$ can always win). So we can calculate the prefix sum and iterate from player with max tokens to player with min tokens and this gives us the linear solution.

code: 107566237

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    Hey Thallium54 I have also done by prefix sum approach by sorting and my code looks similar to you but my code is giving wrong answer on test case 2 , can you please tell me why it is giving wrong answer Code 107641891

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится +5 Проголосовать: не нравится

    i did exactly did this, did not even think about the solution from the editorial, since this was just right there in front of my eyes after realizing what the problem wanted lol

  • »
    »
    3 года назад, # ^ |
    Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

    Hey Thallium54, i solve the problem exactly like your approach but i got stuck in the last loop and i know exactly the test case that i got stuck into but i dont know why iterating from the max giving me AC while iterating from minimum giving me WA on 2, i would appreciate your help

    WA: 107739869 AC: 107733400

    • »
      »
      »
      3 года назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      See here, the reason your second code works is that you broke the loop if the winning condition isn't satisfied, thus the later players won't be counted. The editorial also says that winning players form a suffix, that's why you should iterate from the max.

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    hi, i try nearly the same code as yours, but change a little when sort, then get WA at test 5. sadly, i can't see the wrong case. and when i use a normal sort it passed. so... maybe the order of a[i].second does matter the result. but why...i think only tokens matter. or are there other problems. thx

»
3 года назад, # |
Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

Recursion Solution for D was very elegant, I wasted a lot of time on coming up with an iterative Solution :(
My Iterative solution for anyone interested.

AC_CODE
»
3 года назад, # |
Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

Editorial has mentioned nlogn solution for problem F. but my O(nlogn) solution got TLE on test case 5 :( Link: https://codeforces.com/contest/1490/submission/107615964

»
3 года назад, # |
  Проголосовать: нравится +18 Проголосовать: не нравится

Can problem G be solved if the drive only stopped when the sum was exactly $$$x$$$?

I misread the problem statement and while trying to solve it and I got some interesting observations (until I realized my mistake) but I'm not sure they make a solution that always works.

I noticed that for each query we need to get something like $$$k*sum + pref = x$$$, being $$$sum$$$ the sum of all the elements of the array, $$$pref$$$ any prefix of the array (even an empty one), $$$x$$$ the number in each query, and $$$k \geq 0$$$. So we can rewrite it as $$$k = \frac{x-pref}{sum}$$$ and since $$$k$$$ has to be an integer, then $$$x-pref$$$ has to be divisible by $$$sum$$$, i.e. $$$x-pref \equiv 0 \pmod{sum}$$$, so $$$x \equiv pref \pmod{sum}$$$. Knowing this, I can store and sort all the prefixes of the array by having them $$$\mathrm{mod}\ sum$$$, while also keeping the original numbers (for example, by storing the prefix sum in a separate array and the corresponding indices in the sorted array, with pairs of numbers, so then I know both the original value and the index to calculate the number of movements).

Then when answering queries, I only need to get $$$x \pmod{sum}$$$ and find it in the sorted prefix array I calculated before, with binary search, for example. If I can't find it, then it's impossible. Otherwise I can calculate the number of movements retrieving the original value of the prefix I found, and the answer would be I think $$$\lfloor{}\frac{x-pref}{sum}{}\rfloor{}n + prefInd$$$ being $$$prefInd$$$ the index of the chosen prefix. Note that I would have to be careful if $$$x \equiv 0 \pmod{sum}$$$, which in that case we don't sum any prefix index, and even subtract $$$1$$$ from the previous expression as we are looking for the amount of movements (we didn't do this before when having a prefix since if we have the array 0-indexed, we were already considering one movement more from the end back to the start of the array).

Something to note is that I may not have to store all the prefixes from the original array, as they can be both positive and negative. This means I can end up choosing a negative prefix while $$$sum$$$ was positive. To explain this better, let's look at how I'm supposedly getting $$$k$$$. I said $$$k = \frac{x-pref}{sum}$$$. $$$x$$$ is always a positive integer (given by the constraints of the problem), while both $$$sum$$$ and $$$pref$$$ can either be positive or negative. $$$k$$$ has to be non-negative (obviously, we can't make a negative amount of full turns with the drive), so we need to consider some cases:

  • If $$$sum < 0$$$, then I would have to keep all $$$pref \geq x$$$ so that $$$k$$$ is not negative.
  • If $$$sum > 0$$$, then I would keep all $$$pref \leq x$$$, because of the same reason.
  • If $$$sum = 0$$$, then we would only reach our goal if some $$$pref = x$$$ exists, because after each full turn is practically a reset back to the start, and if there is no such $$$pref$$$, the drive will keep spinning indefinitely.

And I think by processing the queries offline from lower to greater $$$x$$$ (we can sort them beforehand), and also using some data structure like a set to add and erase the prefixes, sorted by $$$\mathrm{mod}\ sum$$$, while keeping up with the cases mentioned, it's possible to do it efficiently.

Please correct me if I'm wrong, as it's quite probable that I messed up when thinking of this and it's everything wrong. But I thought it was an interesting problem to think of, which derived from a silly mistake in my part.

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Can Someone please explain how is the first optimization in F working, i.e. how are there there are no more than sqrt(n) unique values of C, thanks in advance.

P.S.: I tried to write sqrt(n) in the fashion shown on the Katex website, but didn't see the symbol in the preview, so if someone could help me with that too, it would be great. Thanks in Advance

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    Cnt cannot have more than root N values Because in worst case you will have count array as 1,2,3,4,5,...X which will lead you to n=X*(X+1)/2 . So X <root N

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

For G, the number of spins should be ceil instead of floor?

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

For problem F, just curious, what is the binary search approach? Any explanation or code will be helpful..

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится +3 Проголосовать: не нравится

    107604489 of user MasterMind uses ternary search

    • »
      »
      »
      3 года назад, # ^ |
        Проголосовать: нравится +8 Проголосовать: не нравится

      bcollet It turns out that my solution doesn't work. thanks to clyring for the hack. here is the graph for the hack where my solution fail. There are several local minimums

      Spoiler
      • »
        »
        »
        »
        3 года назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится

        What exactly is plotted in this graph? The costs I calculated when preparing the hack were [24, 14, 15, 12], tricking your code with the local minimum at $$$C=2$$$. It is possible to create more local minima, but the size $$$n$$$ of such testcases will get rather large fairly quickly.

        • »
          »
          »
          »
          »
          3 года назад, # ^ |
          Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

          The x-axes represent the value of $$$C$$$. and the y-axes represent the cost (which is the minimum number of elements to remove) based on the hack test data. $$$cc$$$ in my code represent the frequency of frequencies of numbers provided by your hack test data. The function I used is:

          Spoiler
          Spoiler
          • »
            »
            »
            »
            »
            »
            3 года назад, # ^ |
              Проголосовать: нравится +3 Проголосовать: не нравится

            That's what I calculated... and I used your code to calculate it! Now I see the problem: The x-axis on your chart is the parameter mid you passed into get, which causes out-of-bounds accesses when it is greater than 3, since cc.size() is 4.

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

In problem F, complexity of my code is O(nlogn) which is fine according to constraints but it is giving TLE in system testing can anyone please find out the problem. solution link

  • »
    »
    3 года назад, # ^ |
    Rev. 2   Проголосовать: нравится +4 Проголосовать: не нравится

    Use map instead of unordered_map. In case of unordered_map, it can hit worst case complexity (O(n)) in case of collisions. Map will never go beyond log(n), since it implements self-balancing tree. Please correct me if I am wrong.

  • »
    »
    3 года назад, # ^ |
    Rev. 3   Проголосовать: нравится +4 Проголосовать: не нравится

    use map instead of unordered_map because worst case complexity is o(n) my solution was also giving tle but when I used map it got accepted in a given time limit see my solution I have also used binary search. Heuit Invincible06

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    Use a custom hash function to avoid anti-hash hack. I added one to your code and it passed easily 107711223

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Can someone explain how to get the formula for the number of full spins in problem G.

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится +1 Проголосовать: не нравится

    Let us suppose we get maxima as the maximum prefix sum during first spin. Now let's assume we have y full spins and sum[n] is the prefix sum at the end of first spin.

    So we should have (y*sum[n] +maxima)>=x. This implies y =((x- maxima +sum[n]- 1)/sum[n]).

»
3 года назад, # |
Rev. 2   Проголосовать: нравится +11 Проголосовать: не нравится

.

»
3 года назад, # |
Rev. 2   Проголосовать: нравится +8 Проголосовать: не нравится

.

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Could anyone please help me as to why my submission gets a TLE for D? I have implemented the same idea during contest. I tried several times to debug but I couldn't :/ I can see that it's because there are 1e6 operations involved at max, there needs to be some optimisation to prevent TLE. But I don't know what exactly to do. My submission: 107614061

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится +3 Проголосовать: не нравится

    You're solving subparts(recursion) inside the loop.Try taking it outside,it'd work then.

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится +2 Проголосовать: не нравится
    rec(l,mx_idx — 1, depth + 1);
    rec(mx_idx+ 1, r, depth + 1);

    These function calls should be outside(after) the loop.

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

1490D - Трансформация перестановки can be solve in $$$O(n)$$$ time and space complexity using Cartesian tree 107689365

»
3 года назад, # |
Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

Problem F — Equalize the Array

"you can consider only unique values of C (there are no more than O(n*√n)), and get a solution in O(n*√n)"

I used this approach mentioned in the editorial during the contest and get a TLE in test case 12.

Here is my submission:107609642

»
3 года назад, # |
  Проголосовать: нравится +1 Проголосовать: не нравится

Will someone please attach this editorial to the contest itself? I think my color grants me the power to do so, but haven't tried and don't want to risk making a mess on a public round.

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

For problem 1490C — Sum of Cubes : In the Editorial's code there is precomputation of the cubes upto 10^9. It means this loop is going to iterate that 10^9 times , then it is supposed to give TLE. Since we are allowed to have only 10*8 operation per sec as per the standards of OJ. Please suggest if I am wrong.

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

There is a small bug in the editorial for 1490G - Старый дисковод. The formula

$$$\left\lfloor\frac{t}{s}\right\rfloor \cdot S + pref[t \bmod n]$$$

needs to be changed to

$$$\left\lfloor\frac{t}{n}\right\rfloor \cdot S + pref[t \bmod n]$$$

So that in the first member you have amount of full cycles multiplied by the total sum during the cycle.

»
3 года назад, # |
Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

for Problem G: for testcase

1

2 2

2 0

1 2

according to me ans should be:[-1 0]

but the query is giving: [0 0]

can someone help me understand where i am going wrong. here is my code:

  • »
    »
    3 года назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    see the third step in the algorithm, 'sum is at least x'. so when query for the case x=1, the sum=2 will be just ok, and time is 0.

»
3 года назад, # |
Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

I have a 'problem' with task F.

I use map to count number of occurences of a given number. When i use unordered_map<int,int> I get TLE on test 12( > 2sec). https://codeforces.com/contest/1490/submission/107876739

When I change to map<int,int> my solution takes < 200ms. This means, that unordered_map<int,int> in this case is at least 10 times slower. Why is it so? My previous experience (including performance tests) was, that for unordered_map is not slower than map, especially, if the number of elements is large (as probably in test case 12, where the sequence seems to be arithmetic). https://codeforces.com/contest/1490/submission/107876786

Test case 12: 1 200000 53201 106402 159603 212804 266005 319206 372407 425608 478809 532010 585211 638412 691613 744814 798015 851216 904417 957618 1010819 1064020 ...

Edit: I could have read previous comments before posting this, sorry. Problem solved.

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Really liked this contest!

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Problem G.

In the full spin calculating step, Why do we have to (x — max(pref[0..n])) before / sum?

Because the pointer could not reach the max(pref[0..n]) at the end, and we will substract more than necessary. The full spin could less than the answer.

Please help me, thank you.

»
3 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

In problem F(equalise the array) i am getting wrong answer at test case 20. I have tried a lot of test cases but i am not able to figure out the problem. Can someone please help me with this. This is my submission 109139946.

»
3 года назад, # |
Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится
Your code here...
#include <bits/stdc++.h>
using namespace std;
typedef long long int lli;
typedef long double lld;
#define FOR(i,l,u) for(lli i=l;i<=u;i++)

void solve()
{
    
lli t;cin>>t;
while(t--)
{
    lli n;cin>>n;
    lli A[n];
    FOR(i,0,n-1)
    {
        cin>>A[i];
    }
    unordered_map<lli,lli> count;
    FOR(i,0,n-1)
    {
        count[A[i]]++;
    }
    vector<lli> C;
    for(auto x: count)
    {
        C.push_back(x.second);
    }
    sort(C.begin(),C.end());
    lli greater_than_or_equal_to_count,mini = n,size=C.size() ;
    for(lli i=0;i<size;i++)
    {
        greater_than_or_equal_to_count = size-i;
        mini = min(mini,n-(greater_than_or_equal_to_count*C[i]));
    }
    cout<<mini<<"\n";
    
}
    
}
int main()
{
    solve();
}

Why am I getting TLE? Isn't it O(nlogn) algorithm?

»
2 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Is it necessary to use unordered_set instead of set in problem C ??

»
9 месяцев назад, # |
Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!We Want Div4!!

»
5 месяцев назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

wee my first ever comment on Codeforces , I don't know if someone will ever reply in the problem 1490F - Уравняй массив my 228090314 got a TLE but has the same logic with galen_colin except that he added ++m[(a[i] + 88) ^ 910591789]; , I did m[a[i]]++; when dealing with the map I don't understand why adding 88 XOR that big number and why does this fix the TLE problem , thank you guys