Hi CodeForces!
As we can see, during the last contest:Manthan, Codefest 19 (open for everyone, rated, Div. 1 + Div. 2), a number of codes that passed system test in problem F is wrong. And, unfortunately, there are almost no hacks during the contest. So the tests were definitely pretty weak.
I think one of the main reasons is that in each room, the number of people who passed pretest in this problem is very small (probably none), and so do the problem E and G. In this case, there are almost no chances to hack these problems.
So I suggest each participant be divided into two rooms, the first one is divided randomly, and the second one is divided by their rating. In this way we will have more chances to hack difficult problems.
Uphacking may be useful. :)
Yes, but the verdict during the contest won't change.
Orz wqy! Nice suggestion! Only one question: can I hack other submission after contests? It makes me feel bad to see submission with algorithms totally wrong, and many people will follow wrong algorithm, since wrong algorithms are easier to write/think.
read this
But the rank changes quickly, for some users (mainly who have poor network), maybe when he/she sees one's code, they are already not in a room.
UPD: now it is ok.
I think that by "rank" he meant "rating"
Oh, thanks
I have a great suggestion : remove hacking altogether.
Just make stronger pretests. Because a hundred points can make a great difference in some contests and hacking is more often than not purely luck based. Sometimes you have three hackable codes in your room sometimes you have none.
What about allowing to hack every solution that has been locked ? It would remove the room issue and we would still keep the hacking part. What do you think ?
But that allows people to submit wrong solutions intentionally from say, their fake accounts and then hack them afterwards to gain points.
I get your point. It's not something easy to fix :-\
Well locked submission aren't that common and if you lock your submission you are pretty sure it is correct. That would lower the number of hacks significantly making them useless. In that way hacks end up in a limbo state where they exist and they don't. And I belive more people would give up on hacking which would again lower the number of hacks and the spiral would continue until there is no hacking whatsoever.
Maybe making rooms -in combined rounds only- div2 rooms and div1 rooms (combined tasks but separated rooms)
In case A has very weak tcs. Div1 participants will be at huge disadvantage.
How about having an open hacking period on every contest?
And it should be of at max 30 mins. 24 hours is a very long time. (Normal rounds can have 30 mins hacking phase and educational rounds 24 hrs hacking phase).
A good way to do it would be to reward more points (say 200 points) for a successful hack, BUT then all submissions are judged again on the test case, and if they fail no points are given, so one person cannot use some scraper program to hack like 100 submissions with the same test and get insane points (he would only get 1 successful hack).
Problem of not having people that you can hack on nontrivial tasks is a problem with combined rounds mainly. Instead of people having average rating of sth like 2200 in my room I have people with average rating 1700, so number of submissions to harder problems is significantly smaller. People that solved F (>100) are uniformly spread around 200 rooms instead of 20. However hacking harder problems is harder anyway, so I would not do this anyway without a good reason for it
I don't think that your solution works. There are two things which motivate hacking:
Problem F does not satisfy neither of them. The implementation is not so short, and there are no trivial corner cases either. Hence no people want to waste time reading others' code.
One more thing, problem F should be considered a difficult one in a contest. As coming up with the idea is hard, it is very annoying to fail system tests because of silly bugs (as it is not the main part of the problem). Hence for F or G, I think it is contest setter's fault not to have strong pretests.
Does that mean it's ok to make codes with silly bugs if the problem is hard?
Also, you mentioned that
it is contest setter's fault not to have strong pretests. That's not a reason not to make hacks. One of the main purpose of hacking is to avoid some unfair situations (like some wrong codes passed but others didn't).One more thing, since
lots ofwrong solutions passed F, and also many wrong solutions in practice failed at test 139, that should be a common mistake.(A question I want to ask for a long time: do you prefer being hacked on a problem you won't lock or failing at system test?)