Блог пользователя MinakoKojima

Автор MinakoKojima, 10 лет назад, По-английски

People always hope strong pretests. There's reasons: it will be a huge lost if someone get the correct solution but fail by tricks (Especially for hard problem). But is that a good taste if we remain all tests in the pretest? Well, I don't think so, there will be no difference between ACM-ICPC rules if we do so.

The question is, the reward of hacking is uncertain while the cost is high. Not only the time, but also it will stop you from resubmitting. Imagine that you solve a problem and found a trick in it, will you lock it immediately? Well, since I do not know whether the trick is involved in the pretests. I prefer only to do hacking until there is no solvable problem.

In Round #201, cgy4ever resubmit the problem C, thus he knew the trick is not involved in the pretests definitely, this is a rare case.

So, what I suggest is, involved some things called detect submission. It won't increased the penalty and will skip during the system test. What the “detect submission” do is to tell you whether a trick is involved in the pretests, it can be only used after you pass the pretests.

With this feature, the risk of hacking could be reduce to a certain extent. So it will also benefit to other participant who doesn't do hacking without excessive strong pretests. Just a imagination, waiting for hear something better then this.

  • Проголосовать: нравится
  • +113
  • Проголосовать: не нравится

»
10 лет назад, # |
  Проголосовать: нравится +12 Проголосовать: не нравится

+1

»
10 лет назад, # |
  Проголосовать: нравится +14 Проголосовать: не нравится

Very good point, I was thinking exactly the same even before that entry.

»
10 лет назад, # |
Rev. 2   Проголосовать: нравится +51 Проголосовать: не нравится

I'll argue a bit.

First of all, let's say that this feature is included in the rules. Would you then spend time on changing your code so that it doesn't cover some cases, submitting it, waiting until the server tests the faulty code against the pretests and so on? I think that still many people would make such submissions only when almost sure that this case isn't covered or there is no solvable problem anymore. In both cases, you would probably lock the submission either way.

Secondly, in my opinion hacking was intended to be a kind of... gambling? That is, you need to "bet" your program is correct in order to gain ability to hack someone. Of course, the possible price is quite big, but I think giving such ability is like the following in Texas Hold'em poker: 'well, I have two aces and I know that the third one will be drawn on the table (giving me a triple of aces)'. This makes things less interesting, doesn't it?

And finally, note that this would result in increasing the number of submissions. If there were many people trying to do their detect submissions, Codeforces servers would be even more overloaded than they're now (and they're quite overloaded as we've seen around the end of round #260).

Of course I may be totally wrong and this change will substantially improve the contests. Either way, I'd be happy to hear some counterarguments. :P

»
10 лет назад, # |
Rev. 2   Проголосовать: нравится +29 Проголосовать: не нравится

I totally disagree.

This is overkill and it will complicate the rules that are already not very easy for beginners. Moreover, the best thing about hacking is that you have almost zero information and the only thing you see is other guy's code — so I agree with mnbvmar it's like gambling and it's one of the most exciting parts of the contest.

»
10 лет назад, # |
Rev. 2   Проголосовать: нравится -8 Проголосовать: не нравится

In Round #201, cgy4ever resubmit the problem C, thus he knew the trick is not involved in the pretests definitely, this is a rare case.

this happened to me in TopCoder SRM 627. i found bug in my 250 and resubmitted, then challenged 4 others with the same testcase. then became yellow after the SRM too. :)

  • »
    »
    10 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    It happened to me with A in this Codeforces Round 260 (Div. 1). Considering all resubmission losses and 2 successful hacks, I gained 6 more points compared to the situation if I didn't make the mistake at all and didn't realize that it could occur.

  • »
    »
    10 лет назад, # ^ |
      Проголосовать: нравится +5 Проголосовать: не нравится

    It also happend to me in 500p of TCO2014 Round 3B (yesterday), and it helps me to advanced to the finals.

    But they are a bit different because in TC we already know the examples (pretests).

    By the way, in Round#201 I didn't realized "the trick is not involved in the pretests", I just feel that trick is very evil so I locked and tried to hack.

»
10 лет назад, # |
Rev. 2   Проголосовать: нравится +12 Проголосовать: не нравится

But guys, hey, sometimes you discover a tricky case and you don't know whether it is included in pretests and you have to view all submissions in order to find omittment of that case. If it is included, that will be simply a waste of time spent in a completely unproductive way. We are here to gain abilities mainly from problem solving, during hacking we also benefit from learning understanding other's codes, but in the case when we read whole solutions/main part, not when we search for not covering corner case. Given knowledge that some kind of case is covered in pretests we can prevent losing our time. And argument that those detect submissions will significantly increase number of submissions is simply nonsense. "Would you then spend time on changing your code so that it doesn't cover some cases, submitting it, waiting until the server tests the faulty code against the pretests and so on?" — Yes, I definitely will. That is much less time than going through all submissions in a room. By the way hacking is indeed some kind of gambling, but I see no relevance between arguments presented by mnbvmar and caustique to those detect submissions.

»
10 лет назад, # |
  Проголосовать: нравится +1 Проголосовать: не нравится

Can you explain more clearly or with examples what is "detect submission"?

  • »
    »
    10 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    Well.. lets say you solved the task and you know there is a trick. But you dont know if the trick is not included in the pretest. So you are not sure: "To lock, or not to lock". Detect submission can allow you to check freely whether the trick is included in the pretests or not, so you can know what to do.

    • »
      »
      »
      10 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      Pfff.. Firstly it is difficult (and stupid) to decide what is trick and what is not a trick, and for composers it can be a trick and for participant it can be not a trick. So if you want to show for participant who passed pretests are there tricks or not — you should show for him all set of pretests, and let him decide is there trick test included or not.

      • »
        »
        »
        »
        10 лет назад, # ^ |
          Проголосовать: нравится +10 Проголосовать: не нравится

        you should show for him all set of pretests

        no way! that ruins the contest completely!

»
10 лет назад, # |
  Проголосовать: нравится +20 Проголосовать: не нравится

Well, I like the idea and its really good to know what is included to pretests.

But I see one drawback: If you got AC, and after that found that your solution is incorrect, then you may for free test your solution on pretest(Well, pretests aren't so good, but ...)

  • »
    »
    10 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    they could be limited lets say 5 per contest

  • »
    »
    10 лет назад, # ^ |
    Rev. 2   Проголосовать: нравится +5 Проголосовать: не нравится

    by "AC", do u mean Pretests passed?
    also, it isn't technically free testing. since it takes time to judge this submission, u may lose 0 - 20 points by the time u finish this testing (assuming ur solution is correct).

    • »
      »
      »
      10 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      Yeah, I surely mean "pretests passed".

      But In normal case you got -50 for each testing submit

      • »
        »
        »
        »
        10 лет назад, # ^ |
        Rev. 2   Проголосовать: нравится +5 Проголосовать: не нравится

        yeah, i understand ur argument.
        how about this: each Detect submission will be free (i.e. zero penalty) only if there is no resubmission after that which receives Pretests passed.

        • »
          »
          »
          »
          »
          10 лет назад, # ^ |
            Проголосовать: нравится 0 Проголосовать: не нравится

          Nice, it's the same with I thought right after I see your previous comment:)

          • »
            »
            »
            »
            »
            »
            10 лет назад, # ^ |
              Проголосовать: нравится +8 Проголосовать: не нравится

            I think better idea is to allow detect submission only after locking.

  • »
    »
    10 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    Oh, I know one way to fix that:

    give a penalty for testing submissions if after them was correct re-submission.

    But it'll we kind of pain to understand these rules for newbie.

  • »
    »
    10 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    Well, I dislike the idea and its really bad to know what is included to pretests.

»
10 лет назад, # |
Rev. 2   Проголосовать: нравится -14 Проголосовать: не нравится

*casts detect trap*

»
8 лет назад, # |
  Проголосовать: нравится +38 Проголосовать: не нравится

I've just found this blog. I think this idea is very nice.

Answering to mnbvmar's comment and drawback found by riadwaw:

  1. Yes, I would spend time on changing my code and submitting it. A few times in the past I thought "I would need info if some_case is included in pretests". So I'm sure I would use it.
  2. I think we should be able to do "detect submission" thing only after locking a problem. So, it's still gambling. Also, it wouldn't make rules complicated and it would remove the issue found by Alex.
  3. The only thing my proposal changes is that after seeing some corner case you don't have to risk that much (but still you must lock your submission) to read all codes in the room. It's stupid to check for some "dividing by 0 if something" case if pretests include it.