TL Issue in the #659 (Div. 1) Problem F

Revision en3, by maroonrk, 2020-07-26 13:53:12

I've hacked all AC solutions of this problem, which were submitted during the contest, and I believe I can hack most of upsolving solutions. Currently, I only checked that they time out on my local machine, because "Unexpected Verdict" prevents me from uphacking. I even hacked model implementation in the editorial.

Here's my latest generator. Feel free to challenge it.

Side Note: yosupo wrote a solution, which passes the above case, but I failed it with another generator.

What I want to argue is that TL of this problem is too tight, and it affected some of the competitors. For example, I got almost the same idea as the model solution during the contest. Still, I was too scared to write it because I suspected it would time out without full optimization and possibly some tweaks like shuffling vertices/edges or contracting vertices. As I proved it myself, my thought was correct. However, this observation didn't help me, and some people who didn't think of this (or believed the weakness of the test) passed F, which seems unfair to me.

I'm not saying the round should be unrated; I think there exists a really well-optimized solution that can pass all tests. But please, problem setters and coordinators, you should give careful consideration to TL of problems. Don't set the TL by how fast your solutions run on your test. I wish future CF writes and coordinators read this, and that's the reason why I posted it as a separate blog, not a comment to the round.

P.S. Please notify me when you believe your solution can pass all tests, I'll try to challenge it.

History

 
 
 
 
Revisions
 
 
  Rev. Lang. By When Δ Comment
en3 English maroonrk 2020-07-26 13:53:12 0 (published)
en2 English maroonrk 2020-07-26 13:51:05 1 (saved to drafts)
en1 English maroonrk 2020-07-26 13:49:43 1826 Initial revision (published)