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.
+1
Very good point, I was thinking exactly the same even before that entry.
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
i like the way u used the word bet, then talked about Texas Hold 'em Poker and compared it with locking of solution. :D
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.
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. :)
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.
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.
sorry, i was only quoting from OP.
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.
Can you explain more clearly or with examples what is "detect submission"?
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.
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.
no way! that ruins the contest completely!
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 ...)
they could be limited lets say 5 per contest
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).
Yeah, I surely mean "pretests passed".
But In normal case you got -50 for each testing submit
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.
Nice, it's the same with I thought right after I see your previous comment:)
I think better idea is to allow detect submission only after locking.
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.
Well, I dislike the idea and its really bad to know what is included to pretests.
*casts detect trap*
I've just found this blog. I think this idea is very nice.
Answering to mnbvmar's comment and drawback found by riadwaw: