Strong agree. Hacking was during Topcoder days when pretests were weak/nonexistent, and with room-based rounds. Modern codeforces rounds have strong pretests and systests, so hacks are basically only by tryhards to cancel div3/4 solutions using a dict in python. I support this feature being removed during the round.

I totally agree. And while we are at it, another feature request would be to enforce rating recalculation for everyone who is registered as rated for the round. Imagine someone opens problems, can't solve anything, doesn't make a submit and there's no penalty for that. Such pussy behaviour should not be tolerated. Topcoder had it, Atcoder has it, this is the way.

Hi! We're making progress on this issue. Don't go too far, and you'll see changes soon.

Yes, it's been pretty pointless for a while and gradually becoming more pointless. Just move it to post-round phase and problem solved.

I would be very sad to see hacking go, but you might be right.

For what it's worth, most of my recent hacks aren't at all in the "authors didn't break some popular wrong solution" category. I'm always surprised when people say that the only kind of hack these days is breaking unordered_map, randomized algorithms and similar because this hasn't matched my experience at all.

The most common cases are (a) bizarre, haphazardly hacked together attempts to solve the problem and (b) solutions that should very obviously get TLE. Case (b) might be surprising but it kind of does make sense — in a Div2B problem there are some 4-6 pretests, which might mean only one max test. And if that max test doesn't fail all solutions that are too slow, then the test cases are weak. Surprisingly, there are not as many people who write solutions with blatantly bad time complexity.

Your claim of 99% might still be correct, because in cases where you really have 15 hacks per room, the total number of hacks greatly outnumbers the number of hacks in a round where

I do recommend trying hack, by the way. The chaotic code that you see makes you understand grey people a lot more.

People these days just can't prepare good rounds with hacks and say it's impossible. When I was the author, there were hacks, they were interesting, not trivial and not deciding. Look at rounds 124 and 222 and learn.

I wrote a similar proposal a while ago: https://mirror.codeforces.com/blog/entry/131115

I wonder how you think about it.

Also I suggest to have the std::hash patched to have randomized behaviour to make it not hackable, considering how many people use STL hash tables without knowing their working principle and how tricky is it to write randomized hashes during contest for those who don't use long templates. This is still a viable issue even if we only allow post contest hacking. I wonder if there is any downsides to this, but I don't think there's any solution to an actual problem dependent on the hash policy, right?

Though I completely have no idea how hard will it be to implement this, since std::hash is implemented on lots of data types and it doesn't seems easy to write an universally unhackable hash policy for each of them while keeping the original time complexity and constant factor.

I think there still needs to be some form of reward for hacking even if the hacking phase will always be after the contest, otherwise the testdata may not always be strong enough.

Personally, I liked during-the-round-hacking. But it became almost obsolete as multiple tests replaced single tests hence covering most of corner cases in compound TC#2. It looks as if the splitting point of the TCs array into pretest and final tests sub-arrays was moved rightwards, i.e. some after-tests become pre-tests.

And there plays psychology and democracy (https://mirror.codeforces.com/blog/entry/76133#comment-618041 (4 ya) and https://mirror.codeforces.com/blog/entry/59465#comment-431304 (6 ya)). If most of the community like to have instant "Accepted" over "Pretest passed", they will influence the stearing of the platform. Therefore nowadays "Pretest passed" became much closer to "Accepted" than in earlier days.

Moreover, the platform is rarely accessible, so the reading solutions of others and hacking is usually from difficult to impossible. E.g. it isn't possible when using m1, m2, m3 skeleton platform versions.

Besides my older (3 ya) suggestions in https://mirror.codeforces.com/blog/entry/98654#comment-874867, I would also agree of variation where during-the-round-hacking is removed. But that means of no difference in so called "Educational" (whatever it means) and usual (non-educational) div.2 rounds.

An alternative thought is to split coding and hacking, i.e. to make rounds dedicated only for hacking (https://mirror.codeforces.com/blog/entry/98770#comment-875485 (3 ya)). E.g. not to hack each other inside the room, but rather to hack some code everyone individually, similarly to usual problem solving. This could be named as "hacking problem solving" or so. But another variation with fighting each other may be also interesting if invented.

Also worth to mention, that hacking isn't popular for >A problems because of the costs being regressive. Moreover, usually only few other competitors of the room have solved higher problems (i.e. scarcity of codes to check for hacks).

And one additional note is that two communities — coders and hackers can't peacefully live in one place, because more populous group will ask for better evaluation compared to another group (example of it — https://mirror.codeforces.com/blog/entry/87524#comment-759372 + https://mirror.codeforces.com/blog/entry/87524?#comment-759105 (4 ya)). Therefore better is not to have coding and during-the-round-hacking combined until it is fair.

If all the problems nowadays have pretests == full_tests, why do we wait for so long during system testing? :( Especially it annoys when you want to submit your solution you wasn't able to fix before the end of the round.

IMO Educs have the best hacking system. Doesn't allow for braindead points farming yet leaves an opportunity to punish someone using, for example, polynomial hashes.

I agree to remove both the pretest and system test, to make everyone to get Accepted in all problems.

Maybe there's a way to solve while(t < const), I'm not sure:

divide the return value of all time-returning functions by 2.

I have another question, which might have started when I was green:

Why can't we hide all the const values when hacking?

If pretests are equal to systests, why do we still run system tests? It only wastes computational resources.

It makes sense, but I want to know how to deal with such solution or mistakes then:

1. Hashing up(I sometimes use it to AC Atcoder problems).
2. Bruteforce that might be fast mostly.
3. Using queue/stack to make a fast Bellman-fold(sometimes as fast as BFS).
4. Wrong greedy that often get correct answer and passed.
5. Wrong impletion that may die of details.
6. Imperative case that some people not considered.
7. Incorrect guessing.
8. Wrong magic ideas.

They might not be found and tailored to by data-maker,then can be used to solve the problem.This sometimes happens in other contests like this link1 link2 link3.So,I want someone to answer.

I absolutely loved the old days of CF hacking, when pretests were very often intentionally weaker than systests, and hacking was about finding algorithmic inefficiencies or missed corner cases. That being said, if the official policy now is pretests = systests, the only viable hacking strategy is killing poorly randomized solutions and also standard data structures and algorithms, like Java's sort, C++'s unordered set/map or Python's dict.

I think that it is spiritually against the concept of hacking as it was initially introduced, and on the other hand it allows and encourages some behavior that I find unhealthy, such as rewhile using scripts to do a few thousand hack attempts on standard library data structures after each Div. 3 contest.

I assume certain bad solution strategies that are missed by the authors and still can be hacked exist, but they become exceedingly rarer with the current system, and basically makes it not worthwhile to try hacking during live contests, as the risk/reward ratio of wasting your time on it is completely off.

I would personally prefer to go back to the "good old" concept of hacks and use weaker pretests much more often, but unfortunately it seems that in most cases it just leads to people being frustrated with the contest author, and downvoting the announcement. Quite saddening to me, but if it's not the option, then it might indeed be better to disable hacks altogether.

I think one really good thing about old CF contests was that you could never depend on your solution being correct due to it just passing pretests. It forced you to put much more attention on the correctness of whatever you're doing before the submission, and I think it's a very nice habit to develop, and the currently existing system doesn't help with it that much, as "Proof by AC" officially works on CF now.

I agree that during-the-round hacking was pretty useless now. In problem F of the recent Codeforces Round 1100, many people around me submitted code with incorrect complexity (with some pruning) and passed the system test. Seems now people are focused on solving problems, and none of them are thinking about hacking others. Also, solving the problem before hacking reduces the number of people who were able to hack. Even if you solved the problem, there must be someone else in your room who also solved the problem for you to hack; for difficult problems, the conditions were really hard to meet. This leads to many wrong codes passing the system test.

I suggest removing during-the-round hacking and add 12 hours open hack to every round, just like the edu round and div3/4 did.