Why is the announcement of round #773 heavily downvoted?
source link: http://codeforces.com/blog/entry/100243
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
I didn't like the round because:
1) Div1A is well-known, I think I already saw it a couple of times before
2) Div1C is standard segment tree problem
3) Div1D has such constraints that almost every approach passes(a lot of solutions that passed are probably not intended) easily within TL while intended approach(I guess it was intended, not sure about that) is hard to fit in 3s.
I was also curious why it got so many downvotes, and here are some reasonable complaints from the comments to the announcement:
1) Pretests are weak for div2B — div1D
2) div2A has heavy image in it's statement
3) the gap between div1A and div1B is too big(although I don't think it's a problem)
4) there were complaints about how it is hard to understand the problems, but I understood every problem from the first try, not sure about these
4 hours ago, # |
I think maybe it's timing (college and school time for a timezone with a lot of participants) and people who weren't able to participate downvoted it to discourage the contests of this time period, leading up to such downvotes. Can't say for sure.
My main reason for downvoting was the tight time limit on D1D. I had to spend the last 40ish minutes of my contest trying various constant factor optimizations to get my O(N2MlogN)O(N2MlogN) solution to pass; meanwhile, many others were able to get AC far more easily using cheese solutions (e.g. bitsets, randomized approaches, etc).
That said, I think this contest had several other noteworthy issues:
D1B derived most of its difficulty from the implementation, in which it was a bit annoying to avoid off-by-one errors. The implementation was far more time-consuming than coming up with the general construction.
The time limit for C rejected some Nlog2NNlog2N solutions while accepting others, which is probably undesirable. EDIT: Complaint about the implementation length of C removed; this was largely my fault for overcomplicating the implementation, as there's a pretty intuitive implementation that's very clean/doesn't require much bashing. Aside from the TL issues, this was a pretty nice problem :)
The pretests appear to have been rather weak. This is obviously a topic of active debate, but I think contest authors should do their best to set strong pretests; I can't think of any particularly compelling reason that failing a test excluded from pretests should be penalized more severely than failing a pretest, and thus, it seems most fair to me to try to make pretests strong enough to reject every incorrect solution.
These problems individually may not seem like the end of the world, and in particular, I understand that my comments about B ultimately come down to personal preference. (That said, the impression I got from the AC Discord after the contest was that most Div. 1 competitors generally shared my complaints.) However, the combination of all of these issues meant that I spent almost all of the contest, with the exception of the three minutes I spent on A, code-monkeying--first to implement and debug B, then to implement and debug C, and finally to perform constant factor optimizations on D--rather than actually thinking about problems.
I think it's a shame that the round turned out the way that it did, because I actually enjoyed the ideas behind the problems. Hopefully, the issues with this contest will make the importance of careful preparation clear to future authors.
As an aside, I think that the proposed theory that the downvotes were caused by the timing of the round is highly implausible. The contest had several hundred upvotes prior to the round, suggesting that the contest was downvoted retroactively by participants, not in advance by people unhappy with the timing.
-
I kind of agree with the points about B and D, but not so much about C. Yes, the nlog2nnlog2n situation is no doubt undesirable, but for the first part — there is a nice solution with just one range minimum segtree with point updates and no "bashing" involved. I actually thought it was pretty interesting and pleasant (even though maybe not completely new) and don't think it deserves much hate.
-
Point taken; I'll need to take a look at the cleaner solution :) Even if the uglier solution was the only way to solve the problem, I wouldn't consider it a glaring issue, and I would have certainly considered the round successful if that was the only problem. I view the implementation issues are largely secondary to the issues with constraints and the FSTs (in particular, I found it frustrating to go straight from a DS implementation problem to a problem that ultimately consumed lots of time on constant factor optimizations).
-
-
"I can't implement in 5 lines" -> bad problem.
Only complaints on D seem valid to me. If anything I think problems like A should be eliminated. I think the many FSTs and supposedly large jump in difficulty for div2 caused more of the downvotes.
-
This is a pretty ridiculous strawman argument. I'm not claiming that any problem that I can't implement in five lines is bad. My argument is that problems that require vastly more time to implement than to come up with the general solution are not ideal, and a contest should not exclusively consist of such problems. (In comparison, I think there are lots of nice USACO problems that involve long implementations; those problems are nice because they require some depth of thought to solve, rather than being instantly reduced to a problem that is standard but annoying to implement.)
Admittedly, any implementation-heavy problem requires vastly more implementation time than thought for competitors who are significantly stronger than the problem is difficult, so it's impossible to avoid this sort of problem entirely. What I found frustrating was that my entire two hours was spent doing lots of implementation and very little thinking--I spent twenty minutes, thirty at most, of this contest thinking about solutions and the rest of the contest code monkeying, which is not a particularly fun experience.
-
I think being able to write relatively concise code is part of the thinking and fun in itself. I do not want to spend all my time on tedious implementation either, but neither my B nor C implementation felt tedious nor long enough to be drastically longer than thinking for even a better competitor like you, and I do not like problems with no implementation at all.
It looked like majority of your code-monkeying came from problem D anyway, which I agree does seem like an issue. I actually don't mind constant optimization in general, but I don't think it is fit for cf-style rounds. And your solution to C could be cut down drastically, which to me is part of a problem's thinking aspect.
-
-
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK