Comments

I think this happens because the specific way problems are created and arranged for NOI and CTT is quite different. I don’t have solid proof, but here are a few key differences I’ve noticed:

  • Problem Order: In NOI, problems are always arranged in increasing difficulty, making it easier to pace yourself during the contest. On the other hand, CTT shuffles them randomly, which makes strategizing much harder.
  • Partial Scores:
  • NOI’s partial scoring system is pretty well thought out. It encourages you to move toward the full solution while still giving significant points for partial progress. You can often score quite a bit even if you don’t solve a problem completely.
  • CTT, however, seems to reward full solutions more and doesn’t benefit partial approaches as much. Some partial scoring setups even feel intentionally frustrating—like CTT24 D2T2, for example.
  • Interactive Problems: NOI typically has zero to one interactive problem, while CTT throws in several. This time, there were three interactive problems in total.

Another thing to consider is that after NOI, a lot of Chinese participants start pre-university programs at THU or PKU, where they spend a lot of time on college-level courses. That takes away from their training time.

It's just luck.

On PVsNPSolver → LIFO System Testing ?!, 5 years ago
0

Fun fact: A portion of system tests are actually taken during the contest, it's only that the results weren't shown until after the contest.

Additionally, this doesn't mean that you should learn LCT or suffix data structures. Because you can hardly really understand these and use them correctly. Understanding is more important than knowing.

Personally, I believe that the rating which you'll need talent to reach is much higher than CM, M, GM, and even IGM.

What you may actually need is so-called "systematic training", or a systematic knowledge of the whole Competitive Programming system. You need to build up your "talent tree", or "knowledge map".

To be more specific, don't aim yourself to some particular rating, like 1900 or 2100. That's limiting your potential on purpose. Learn new stuff. Learn DP, learn skills to optimize DP, learn common models of DP, such as common models of backpack DP, range DP, counting DP, and monotone queue, and the slope trick. Learn state compression. Learn the Quadrilateral inequality. Do some exercises on them, make sure you get very familiar with their concept and ideas. Just don't get driven too far and learn things that you can't understand at all.

Learn maths, learn combinatorics. Learn basics data structures as well. Segment trees are the most basic thing, and I believe that they have a variety of applications that's not at all obvious. Learn Sparse Table, BIT, HLD, balanced trees, disjoint sets and their revoke operation.

It's enough of a list when you get what I'm saying. What you really need is not stability at solving Div.1 ABs at the moment. It is, however, a general knowledge of algorithms and more importantly, their common applications and the ideas behind it. Try to understand every technique that you learn. Sync with them.

Most CodeForces problems below 2400 I guess do not involve complicated algorithms. Some of them hardly involve any algorithm at all. But this doesn't mean that you shouldn't learn them, for two reasons:

  • The ideas behind the algorithm is really helpful for improving your problem-solving skills.
  • Simple problems can't stimulate your skills, and therefore has little help on your ability.

With a little practice, you can totally reach CM and even much higher. But advancing does require a firm understanding of the fundamental algorithms. Only practising 1900~2100 problems simply aren't enough.

Thanks for your correction, but I meant to say that It costs $$$\mathcal{O}(\sqrt[\lambda]M)$$$ time to use the data structure to handle EACH update operation, and $$$\mathcal{O}(1)$$$ time to use the data structure to handle EACH query operation QwQ.

It is amusing that this is kind of a "two-layer" segment tree, and if you change it into three layers, the time complexity handling updates will reduce to $$$\sqrt[3]M$$$ while not changing the time complexity of queries(since its adds up $$$3$$$ pieces of information instead of $$$2$$$).

That means that you can actually chose ANY constant number $$$\lambda$$$ and make the time complexity $$$\mathcal{O}(\sqrt[\lambda]M)$$$ — $$$\mathcal{O}(1)$$$......

But in practice I've only seen choosing $$$\lambda=2,3,4$$$ and a large proportion of them $$$2$$$...... QwQ

My solution with a time complexity of $$$\mathcal{O}(N\sqrt M)$$$ passed all the pretests using $$$3400\space\text{ms}$$$ and then passed all the system tests using $$$3416\space\text{ms}$$$.

Note: this is not a comment talking about creative solutions, but a comment talking about how to use some ordinary data structure to compensate stupidity, so please forgive me if this sounds not so inspiring...... QwQ

Just sharing some thoughts...... QwQ

If you use enumerate all of the possible results of $$$\lfloor\dfrac{a_i}{x}\rfloor$$$, you will end up with a condition in which you need to maintain a sequence allowing you to perform to operations:

  • Updating one single element in the sequence(we will simply call this "update").
  • Query the sum of a continuous prefix of the sequence(we will simply call this "query").

And the length of the sequence is $$$\mathcal{O}(M)$$$, the total number of "update"s is $$$\mathcal{O}(N)$$$, while the total number of "query"s is $$$\mathcal{O}(N\sqrt M)$$$.

You choose a power of $$$2$$$ near $$$\sqrt M$$$, in my case I chose $$$2^9=512$$$, and divide the sequence into several blocks, each have a length of $$$512$$$.

You maintain two sequences, $$$C_i$$$ and $$$\Delta_i$$$, in which $$$C_i$$$ means the sum of elements in the $$$i-1$$$-th, $$$i-2$$$-th, ......, and the $$$1$$$-st block, while $$$\Delta_i$$$ means the sum of elements in the $$$i$$$-th position, $$$i-1$$$-th position, $$$i-2$$$-th position, ......, and the earliest position that still belongs in block $$$i$$$.

It's not hard to see the answer to any queries to position $$$i$$$ is $$$C_{\lfloor\dfrac{i}{2^9}\rfloor}+\Delta_i$$$, meanwhile $$$\lfloor\dfrac{i}{2^9}\rfloor$$$ can be calculated quickly enough using the bitwise >> operation.

When an update occurs, if the update is a plus $$$x$$$ at position $$$i$$$, you just enumerate all the blocks $$${\lfloor\dfrac{i}{2^9}\rfloor}+1,{\lfloor\dfrac{i}{2^9}\rfloor}+2,{\lfloor\dfrac{i}{2^9}\rfloor}+3$$$,...... and add $$$x$$$ to the $$$C$$$ of those; and within block $$${\lfloor\dfrac{i}{2^9}\rfloor}$$$, you just enumerate all the positions and add $$$x$$$ to the $$$D$$$ of those.

This data structure handles each update in $$$\mathcal{O}(\sqrt M)$$$ time, each query in $$$\mathcal{O}(1)$$$ time, or constant time, and it also has a pretty excellent constant factor.

My implementation(may be very ugly QAQ) is here: Submission #123330049 — Codeforces

Thank you very much for your time reading this! I really appreciate it.

I think the reason behind this is that in Codeforces, if two competitors with a rating difference of $$$400$$$ compete in a single contest, it is expected that one competitor is $$$10$$$ time more likely to win the contest; and with a rating difference of $$$800$$$, the ratio becomes $$$100$$$; with a rating difference of $$$1200$$$, the ratio becomes $$$1000$$$, and so on...... (it's actually not bad to think that the ratio between any master to tourist is no more than $$$13183$$$ LOL), but in Atcoder the $$$400$$$ becomes $$$600$$$, so lower-rated participants in Codeforces becomes even more lower-rated in Atcoder, while higher-rated participants in Codeforces becomes even more higher-rated in Atcoder......(the bound between is extremely high, namely $$$3169$$$ QWQ); additionally, I personally think that Atcoder choses a rating calculation method more optimistic and tends to give more importance into "good times" contests of a participant, while Codeforces is more pessimistic and and tends to give more importance into "bad times" contests of a participant. Maybe there's consideration behind this ^_^.