wucstdio's blog

A Suggestion about the Hacking System
By wucstdio, 5 years ago, In English

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.

  • Vote: I like it
  • +195
  • Vote: I do not like it

Comments Comments (20)
| Write comment?
»
5 years ago, # |
  Vote: I like it +36 Vote: I do not like it

Uphacking may be useful. :)

→ Reply
  • »
    »
    5 years ago, # ^ |
      Vote: I like it +46 Vote: I do not like it

    Yes, but the verdict during the contest won't change.

    → Reply
    • »
      »
      »
      5 years ago, # ^ |
        Vote: I like it -16 Vote: I do not like it

      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.

      → Reply
»
5 years ago, # |
← Rev. 2   Vote: I like it +18 Vote: I do not like it

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.

→ Reply
»
5 years ago, # |
  Vote: I like it +56 Vote: I do not like it

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.

→ Reply
  • »
    »
    5 years ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    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 ?

    → Reply
    • »
      »
      »
      5 years ago, # ^ |
        Vote: I like it +44 Vote: I do not like it

      But that allows people to submit wrong solutions intentionally from say, their fake accounts and then hack them afterwards to gain points.

      → Reply
      • »
        »
        »
        »
        5 years ago, # ^ |
          Vote: I like it +13 Vote: I do not like it

        I get your point. It's not something easy to fix :-\

        → Reply
    • »
      »
      »
      5 years ago, # ^ |
        Vote: I like it +29 Vote: I do not like it

      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.

      → Reply
»
5 years ago, # |
  Vote: I like it +11 Vote: I do not like it

Maybe making rooms -in combined rounds only- div2 rooms and div1 rooms (combined tasks but separated rooms)

→ Reply
  • »
    »
    5 years ago, # ^ |
      Vote: I like it +16 Vote: I do not like it

    In case A has very weak tcs. Div1 participants will be at huge disadvantage.

    → Reply
»
5 years ago, # |
  Vote: I like it +107 Vote: I do not like it

How about having an open hacking period on every contest?

→ Reply
  • »
    »
    5 years ago, # ^ |
      Vote: I like it +16 Vote: I do not like it

    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).

    → Reply
    • »
      »
      »
      5 years ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      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).

      → Reply
»
5 years ago, # |
  Vote: I like it +8 Vote: I do not like it

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

→ Reply
»
5 years ago, # |
  Vote: I like it +16 Vote: I do not like it

I don't think that your solution works. There are two things which motivate hacking:

  • Solution are very short and easy to implement. In this case, people expect low-rated contestants to have silly bugs.
  • There are tricky test cases. In this case, people expect others not to consider it, so that they can hack them without reading their lengthy code.

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.

→ Reply
  • »
    »
    5 years ago, # ^ |
    ← Rev. 2   Vote: I like it 0 Vote: I do not like it

    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 of wrong 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?)

    → Reply