How does hacking work with the new feature of unrated registration? I have seen this question raised in the comments to the announcement several times, but there is no answer still and I think it's weird that Mike hasn't thought about it before announcing.
I was working recently on a div.2 Codeforces round (still might happen in the future) and I was told by my coordinator that pretests should be equal to systests in all the problems. From this I can conclude that it is a Codeforces policy and intentionally weak pretests do not happen. It doesn't mean that it is impossible to hack anybody, but it doesn't sound like a viable strategy. I find it weird that this information is not public, it's like I'm getting bonus information about all other Codeforces rounds by setting a round myself.
I have done exactly zero research on the matter, but my feeling is that 99% of hacks (I'm talking about during-the-round-hacking here, not open hacking of education rounds and such) happen in rare cases when authors didn't break some popular for some reason wrong solution, and every room has (15+-3) solutions with the same bug. So somebody in the room gets (1500+-300) points that have no correlation with their problem-solving skill, and even if somehow it is the top participant in the room, it still can affect the results in a random way due to rooms. It doesn't feel good to win a round like this. It feels even worse to lose a round in such a way.
I would be glad if during-the-round-hacking was removed.
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
dictin 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.
Don't agree with this — what if you register but then have an emergency which means you can't participate...
Register immediately before the round
Making stuff hard to take advantage of is much more important than accounting for such people.
I have never missed a rated atcoder round that i registered for.
but this isn't possible because of that braindead 5 minute period before the round where you can't register
That would go away if hacking got removed fyi (since no need of rooms)
Either way, is it too much effort to sit down 10mins before a contest?
Then we can talk about this change after the 5 min period gets removed.
5 minutes is not a long time at all
Register when you know you are capable of attempting the contest, as of me I always find myself before 10-15 minutes in front of my PC before a round and we have the option to register before 10-15 minutes so better register then.
strongly agree very unethical
Hi! We're making progress on this issue. Don't go too far, and you'll see changes soon.
Kindly look at the above request too.
What do you think about all rounds having hacking, but strictly after the round, like in div3/4? That way, the potential for cheats stealing innocent people's solutions and putting them on Telegram is removed
Please don't remove systest phase
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.
I agree that it might be fun for some people. I think that uphacking is a nice feature and I have nothing against it. Maybe even add post-round open hack phase that affects the results, although it needs some tweaking.