DISCLAIMER: sorry for my poor english, hope you can understand this text :)
Hello!
Firstly: Codeforces is a beautiful platform, sure.
In my mind hacks became useless. Why? Ok, see:
Many easy problems (D1AB/D2ABCD) are "multitest" problems. It is really hard to hack them, because pretests are very strong. But what if I want to hack some hard problems? Hm, i tried to hack some hard problems, but in div2 rooms are very small, and i discovered that there were only 2-3 people who solved some hard problems.
Anyway, i saw that jqdai0815 in one of his screencasts was very annoyed about it too.
But if i will try to hack D2B for example, i would find roughly 10 people, and the chance of succes hack is very small, so it is useless to spend time on it.
So, it is really hard to hack someone, and we can see that the quantity of hacks is very small in some previous rounds!
-
What is my solution? Ok, lets make rooms bigger from 40 to 80.
What you think about it? Share your opinion in comments.
To be ownest, I think that rooms are useless at all(it's only my opinion). And it would be great to have a chance to hack everyone. If this happens, there will be huge number of hacks during the round, so some hacks will taken to final tests and the probability that wrong solution passes all tests will be smaller than now.
It would be a mess if something like THIS happens. Some guys would be the first on the contest, by just hacking A. And you can't tell "make stronger pretests", because you never know. So open hacking is bad in my opinion.
I personally made 16 successful hacks on that contest and it was only inside of one room. Imagine having access to all the people.
There are many ways to improve my idea. For example to give only 20 or 10 points for successful hack. This way less solutions won't pass system tests. And also hacks will be for participants that couldn't solve anything else on the contest, while others will solve problems and not hacking. Also your example is rare enough.
Giving such a small reward for a successful hack will lose the point of hacking and people would just stop doing it.
As I have said "hacks will be for participants that couldn't solve anything else on the contest, while others will solve problems and not hacking". Please read carefully next time
I'm reading carefully. Isn't it like this right now? For example I go to the room when there is nothing for me to actually solve.
Maybe it's better to give a variable number of points for a successful hack, for example $$$\frac{300}{2+n}$$$ for the $$$n$$$-th hack.
I mean the $$$n$$$-th hack of each person, considered independently.
I think that allowing the possibility to hack anyone in the contest will encourage things like this, people intentionally creating alts and hacking their own solutions. I think that making the room bigger should solve the problem.
Nope, it won't solve the problem, it will only make it worse...
However, the issue magically disappears if the admins can "cancel" all the hacks of a particular person if he is guilty cheating. (say add a "flag solution" option?)
I don't think so.
Yes, authors make pretests better by using multitest, but it doesn't necessarily mean it's harder to find hacks. For example, on the previous Div1 round a lot of D1B solutions didn't pass system test. Almost in every room you can find 2+ solutions that failed. Why were there so few hacks? I guess people are just scared, because of multitest and the problem difficulty (which was not difficult btw). And for the point: multitests didn't stop solutions from failing on the last D1B, but for sure made pretests less weak.
I agreed this. And I think authors will sometimes even make pretests weaker on purpose.
Such as 1321 div2B, there is an obvious wrong way to solve a detail, which can be easily hacked by random datas, but in contrast the wrong code can pass pretests.
I believe that the current model of having strong pretests and not intentionally leaving out edge cases, is much better than the old one where we had Hackforces — no hacking is certainly better than leaderboard decided mostly on hacks.
However, increasing the room size to 2x its current size seems like a fair proposal, considering that the number of participants on Codeforces has gone up by >2x nowadays — so there is just as much, or a lower probability, of multi-accounts ending up in the same room even with the increase of room size.
Although I agree with the second point, I don't fully agree with the first point. We can occasionally have contests where sometimes an odd edge case(not talking about the obvious corner cases) are left out, because of the fact that it would help and train programmers to have better accuracy at handling all the cases and not getting a lifeline at the pretests itself. So more is at stake and more alertness is required.
Also that adds for good drama during the system testing :)
I think that in the ideal competition, there should be 0 hacks and 0 FSTs at all. It also seems for me that the pretest + hack system has only 2 purposes: making queue smaller, and improving the testcases if they were poor.
Exactly. The hacking system should be reserved for cases like anti-hash hacks, missing fast I/O etc. Otherwise pretests should include all corner cases.
Time complexity based hacking is still somewhat acceptable. But pretests should be that strong that there should be no WA in system testing or hacking.
But the tests are tested on full tests during the round, not just pretests, so the queue purpose does not apply.
They are tested on full tests only if there aren't many submissions to judge and it has some spare time
I don't totally agree with you here. I think that hacks/FSTs can be positive, when it's about wrong ideas (and not about bugs or details):
Creating a testcase is sometimes (albeit too rarely) a challenging and interesting task
It punishes those who submit a greedy/heuristic/randomized solution without knowing whether it's correct, and rely too much on the judge.
For example, I think that randomized solutions getting FST on 1148F - Foo Fighters was a good thing. And it would have been cool to see people gaining points by coming up with the one-solution test! (Unfortunately, it was combined, so nobody could hack)
Sadly, most of hacks/FST are about dumb bugs or edge cases. I'm glad that multitest came and highly diminished their number. I nonetheless hope to be able to see interesting hacking opportunities from time to time in the future.
That's the coordinator we need, but coordinator we don't deserve...
(Btw, on two last contests I got FSTs because of some really small and stupid bugs...)
Sorry if this sounds stupid but what exactly is FST? I've seen it being used as FSTForces, etc. I used to think it's some sort of algorithm/technique like FFT tbh in the start.
FST stands for "Failed System Test" — your worst enemy here
Oh cool, thanks! So, I've been hacked once but never FST'ed before as far as I remember.
So maybe it is just mine worst enemy then :)
They can also make the queue smaller by using the t testcases in a single input type format more frequently and having less inputs.
I, for one, would actually like it if there were no hacks and no systests (you get the final result during the round). Hacks are pretty random and annoying, and systests usually make you wait for the results for like two hours nowadays :)
I feel hacking and system tests are remnants of the old contest format idea that is not that relevant now.
if there is only main tests in contest, the queue during contest would be super large for some contests. :(
Sure, I never said it was easy :)
But at the same time AtCoder seems to be doing fine with 10k people in their Beginner contests, and Codejam had around 10k people in round 1A as well. So I think it is possible.
Here is a raw idea: Making separate rooms for each problem (fewer rooms for harder problems). When a contestant solves a problem, he/she gets added to one of the rooms for that problem randomly. This makes hacking easier for harder problems, since you can view more submissions.
This is genius and doesn't require registering 5 minutes before the contest!
Yep, looks really good, but how you estimate the number of rooms for each problem? You don't want to place the first 30 people to solve some problem in the first room, they wouldn't be random. But if only <30 people will have some problem solved at the end then you want to make sure that they'll be in the same room.
Yeah your point is really important and this is exactly where it gets tricky. Honestly I haven't thought very much about the idea. Maybe the number of rooms for a particular problem should be kind of dynamic over time; I mean maybe there should be an algorithm that estimates the total number of contestants who will pass the pretests by the end of the contest (I think the algorithm should do this multiple times during the contest. But when exactly? Maybe this should also be dynamic? I don't know. :D) and if it is significantly lower than
current_number_of_rooms×room_capacity, begins to merge rooms randomly (or even redistribute those who have passed the pretests to a fewer number of rooms). (Also I think the algorithm should inform those who have passed the pretests a few minutes before merging/redistributing.) Also, if the estimation is significantly larger thancurrent_number_of_rooms×room_capacity, the algorithm can simply increaseroom_capacity(or again it can redistribute those who have passed the pretests to a larger number of rooms).Again, it's just a raw idea and I think if the headquarters decide to implement it, there should be a lot of discussion about the details, and also it should be tested multiple times at first. Maybe it does not work very well in action. :D
Another change along with doubling room size which i think should be done is that if you register in a contest, regardless of whether you make a submission or not, it will be rated for you otherwise deregister yourself or register only when you are sure that you'd participate in it, im suggesting this because i see that in room out of 40 participants i can see that in last div2 8 people didn't submit a solution and in 2nd last div2 this number in my room was 20!, i mean scope of hacks decreases at very first stage at this point only and people just register in contests for fun without even giving it a chance!
Sometimes I(read people), also register and later figure out they have other commitments.. This would be very unfair if you just did not participate at all. In, Topcoder the scoring (and hence rating) is only affected once you open the problem. But again, this would encourage alt accounts..
But i think that if someone expects commitment ,He generally will know about it atleast 10 minutes before starting of contest and thus, can register once he's sure he is giving the contest as registrations are open upto 5 minutes before onset of contest and also late registrations(even if he wasn't unsure before 5 minutes of beginning of contest) are there, because reading the problem while onset of contest isn't the main problem i think so, people are just taking register button for granted like just register right now and then it doesn't matter if they attempt the contest or not! Yes ,alt accounts might increase but still i think overall it would decrease such non attempt participations!
Generally it's still fair.
What about some partial score problems rated contest and make it Div1.5 That makes hacks discount points from hacked person not full score .. he shouldn't be punished for weak tests :p
I have a proposal to implement a process wherein we can keep the fun of hacking alive and avoid scenarios where people hack self submission from alternate account.
Let's now consider a problem $$$P$$$ whose points at the start of contest are $$$T$$$. Let's take a scenario if a person $$$X$$$ wants to hack the solution of person $$$Y$$$ for Problem $$$P$$$. Then $$$Y's$$$ solution can be hacked if participant $$$Y$$$ meets any of following criterion:
If rating of $$$Y$$$ ≥ rating of $$$X$$$.
If $$$Y$$$ has rating more than 1300.
If 1200 ≤ Rating of $$$Y$$$ < 1300. Total number of contest participated by $$$Y$$$ ≥ 10. (Total contests in a month is almost 10).
If 1100 ≤ Rating of $$$Y$$$ < 1200. Total number of contest participated by $$$Y$$$ ≥ 20.
If 1000 ≤ Rating of $$$Y$$$ < 1100. Total number of contest participated by $$$Y$$$ ≥ 30.
If Rating of $$$Y$$$ < 1000. Total number of contest participated by $$$Y$$$ ≥ 50.
If $$$Y$$$ is not unrated.
Let $$$H$$$ be total number of points that $$$X$$$ has already earned only by hacking $$$Y'S$$$ solution for problem $$$P$$$. Then $$$H$$$ < $$$10$$$% of $$$T$$$.
The values above can be changed. I have used them to describe the model.
make rooms on the basis of rating. Same Rating groups are more likely to solve same problems as u.
That's an old story bro.
It's a policy to become more popular, because more folks are aware of hacks than those who like to hack.
The price is that it loses its uniqueness and become similar to other platforms. But democracy here usually wins.
It's not only about "multitest" problems, but it's also about divisions where folks considered less able to hack during round, or that this hurts too much someone if he become hacked.
And also it is an old story that usually you can not successfully hack, because the platform works unsuccessfully too slow.