This is the second time I've had a problem in a codeforces round. My program failed system test because the time limit was exceeded. I handed in the TLE code after the game and passed. I guess this is because system tests have to evaluate a lot of programs in a short period of time.
First example:
https://codeforces.me/contest/1500/submission/109859256 https://codeforces.me/contest/1500/submission/109932270
Second example (for last round) :
https://codeforces.me/contest/1609/submission/137256555 https://codeforces.me/contest/1609/submission/137341465
And this kind of question is usually the kind of so-called card question, card is very tight, there is no problem. Last time for question F, someone applied for a rejudge and was successful, so I would like to apply for a rejudge.
In addition, I find C++20 is faster than C++17, and I will use C++20 in future competitions.
I don't think people should have stuck with the time constant and let this happen. I also have doubts. When we submit the code and find that we can pass pretest but the time card is very tight, what should we do?
"I also have doubts. When we submit the code and find that we can pass pretest but the time card is very tight, what should we do?"
I think it may not be the intended solution, it will be likely FST for TL. So either you want to choose to rely on luck or improve it.
These two problems are exactly the way to do it, and many people have already written this.
Are you normally crossing a railroad like this: https://www.youtube.com/watch?v=SeQoJs4hoyM&t=30s ? Do you think that it is exactly the way to do it? Maybe, just maybe, trying not to get into such situation in the first place and ensuring some safety headroom is a much better idea?
I think that geranazavr555 made a mistake and created a bad precedent. Now we are going to have dozens of people demanding a rejudge after every contest.
BTW, do you even expect a favorable redjudge outcome with this success probability?
If you hand in C++20, you will find that the state is stable through
I believe that reason behind it is not C++20, but rather compiling using 64 bit instead of 32 bit. 64 bit C++17 should lead to similar results (and many people have shifted from 32 bit to 64 bit already).
I suggest we also rejudge programs which fail because of sheer random chance (bad luck in using randomized solutions). It is unfair to penalize people simply because they got unlucky and hit a wrong answer with a very low probability when their solution is correct. I would also like to apply for a rejudge, in addition to retroactive rating updates over the past 2 years. Thank you for your consideration. MikeMirzayanov
https://codeforces.me/blog/entry/69036
In addition, I humbly request that you include a subsection containing my comment in all future blog posts with this sort of content, else I will be forced to copy-paste it again MoRanAirConditioner (and anyone else thinking of posting similar blogs). Have a great day!
Based
https://codeforces.me/contest/1609/submission/137513721 this is your code getting TLE
Fuck this shit, evaluation in online judges isn't perfect, it's obvious there'll be some fluctuation. If your solution is barely AC/barely TLE then you have no room to complain (same as your solution doesn't have room to AC all the time). There should be NO REJUDGING in these situations. An option would be for them to queue TLE solutions after systest to rejudge ALL OF THEM but that doesn't make sense as it TLE'ing or AC'ing isn't due to load in the server, it's just due to your solution being in the limbo between AC and TLE.
Also, the TLE trick relies on the fact that if some code gets TLE, it is run again a couple more times already to account for the fluctuations in judging time. Taking this into account, a rejudge due to TLE doesn't make sense at all.