We invite you to participate in CodeChef’s Starters129, this Wednesday, 10th April, rated for till 5-Stars(ie. for users with rating < 2200).
Time: 8:00 PM — 10:00 PM IST
Joining us on the problem setting panel are:
- Setters: Archit Pols_Agyi_Pols Kumar, Vaibhav kingmessi Khater.
Tester: Aryaman WAtoAC2001 Das.
Text Editorialists:Nishank IceKnight1093 Suresh.
Statement Verifier: Nishank IceKnight1093 Suresh.
Contest Admin : Mridul MridulAhi Ahi, Nishank IceKnight1093 Suresh.
Written editorials will be available for all on discuss.codechef.com. Pro users can find the editorials directly on the problem pages after the contest. The video editorials of the problems will be available only to Pro users.
Also, if you have some original and engaging problem ideas, and you’re interested in them being used in CodeChef's contests, you can share them here. Hope to see you participating.
Good Luck!
WAtoAC2001 MridulAhi orz
WAtoAC2001 MridulAhi orz
WAtoAC2001 MridulAhi orz
WAtoAC2001 MridulAhi orz
As a tester, I highly recommend participating in the contest!
Good Luck On The Contest :D
kingmessi, Pols_Agyi_Pols orz
As someone who didn't give valuable feedback in this round, kingmessi Pols_Agyi_Pols orz
As a Ronaldo fan, kingmessi Pols_Agyi_Pols orz
bro made ronaldo cut cake for messi
The last three problems are okay, everything else is subpar. Irrelevant details in statements, low beauty (idea to implementation ratio), messed up order, inconvenient input format.
Among the first 3 problems for div1, only cake cutting might have long statement and implementation (depending on the method you choose). Beauty is subjective. These problems were one of the problems where you have to 'think before implementing'. It's your mistake if you decide to implement an overcomplicated solution. In construct xor, try to separate different bits instead of n and you get a very simple implementation with not much casework. Anyways, I'll try to work on improving problem statements and order from next time.
Can you please link the cool solution for construct xor? I've gone through all the model solutions from the editorial, and they are just case work.
code
$$$dp_i$$$ — number of elements in array having $$$i^{th}$$$ bit on. We need to maximise summation of it (to have as many non zero elements as we can) while satisfying that every term of it is even (to have xor 0) and $$$\leq n$$$. So greedily turn higher bits of $$$s$$$ into lower bits.
Thanks
For reference, my in-contest solution to constructor xor separates bits. I was not too fond of this problem because it's mathematically obvious why such a process results in a correct solution whenever one exists but ensuring all the constraints in code was rather troublesome. I had to write two nested loops over bits to guarantee that I would perform all necessary splits. As far as I'm aware, one loop (neither ascending nor descending) doesn't work.
For the purpose of maximising summation, yes, a single loop isn't enough. Although, we just need summation to be $$$\geq n$$$. For that, a single decreasing loop is enough (if $$$dp_i$$$ decreases to allow $$$2$$$ more transitions from $$$dp_{i+1}$$$ to $$$dp_i$$$, then we already have summation $$$\geq n$$$). Since most people submitted the other solution, it is not an obvious solution, at least for the intended audience for this problem.
Thanks for the feedback! I'll try to address what I can.
Most problems had, in my opinion, pretty short (and uncomplicated) implementations.
The non-div $$$1$$$ problems are trivial to implement.
CKCUT is perhaps the biggest loser here: I think it'd have been much better if we'd included an image or two to explain things.
I'm curious though: if you (or anyone else) misunderstood the statement entirely to be something else, can you share your interpretation? The only one I've heard so far is one person assuming that when a flavor is applied, it overwrites any existing ones (though that interpretation immediately fails if you look at the second sample).
In my opinion (and I hope you agree with me here), the other statements are fairly alright: GPL, XRSM, TRCLR are just formal statements, and SMXOR is mostly formal (except for the one line about Leo forgetting the array).
TIKI has a pretty long statement, but that's partially because there are several definitions to be made and a few examples within the statement itself. Imo every part of it is relevant to ensure there's no ambiguity in the passing process and what sort of sequence defines the score. I also chose to explicitly mention certain situations in the statement (such as what happens when the ball passes through the center).
I probably could've made it a bit shorter as-is, but likely the only way to make it much shorter would be to write a formal statement about a circle and simple polygons in it, which loses the flavor of the problem entirely.
As a final note to anyone still reading this, if you're ever confused about a statement, you can ask for a clarification using the "Comments" tab, and if it's a reasonable question someone from the problemsetting team will respond soon enough.
Probably wasn't the greatest, true.
I personally found SMXOR and TRCLR to be of similar difficulty, so I didn't have a particular opinion about their ordering.
SMXOR is definitely more standard of the two, and I'm not too surprised that Div1 found it the easier problem (as a side note, I expected a lot more ACs on both these problems in Div1).
CKCUT also I found simpler than XRSM, I think prefix sums are easier than doing casework. If I had to hazard a guess, the difference in solve counts comes from the fact that XRSM was solved first, so for most people it became the second problem they tried rather than the third; and then they got stuck in casework.
I observed a similar scoreboard effect in Starters 127, when the hardest problem of the contest got solved pretty early which made a lot of people try it (and it was easy to come up with wrong guesses to it, which exacerbated the issue) instead of the easier problems.
I assume you're talking about CKCUT and SMXOR, where the arrays were given in two lines rather than $$$N$$$ lines of two integers each.
I did notice this, but decided it wasn't worth changing — for languages that read input line-by-line (hi Python), this input format is vastly superior since you read way fewer lines. If the input is large enough, it can drastically bring execution time down.
CKCUT probably would've been fine with the traditional style, SMXOR might actually have had issues with the time limit (my PyPy code already runs not-too-fast with the current format).
My solution for TRCLR was two dfses. For XRSM I assume you mean doubling n if it's odd, which I also came up with, but at that point, I was too tired to implement it.
Um_nik taught me to put a legend into a problem only if it helps with understanding. I don't follow soccer and reading about it didn't help me. For CKCUT I was initially confused if a flavor is applied to cherries or segments between cherries. Eventually, samples cleared it up for me.
Problem order is not much of an issue, I wouldn't mention it if there weren't other issues.
I understand the reasoning behind the two-line input format, but I hope that most contestants already have fast IO and I doubt that they will remove it from the template just for codechef. On the other hand, I need to write two loops (either one for each array or two nested ones for a 2xn matrix) instead of one loop with unpacking.
Maybe my questionable experience stems from a skill gap between my math skills (all ideas except TIKI were trivial for me) and my implementation skills (all implementations were boring).
How many casework questions do you want?
CodeChef : YES
Fun contest :)
Kudos to the authors!
I wonder what goes through authors minds when they write problems like construct xor. Do people actually consider those beautiful?
This is what goes through their mind
:)
It's not my alt but I also think that it's an ugly problem.
I see. My bad for doing a codechef contest.
it would be beautiful if there were care being put into the constraints that eliminates all the edge cases (maybe if they guaranteed n > 6 and k > 3), but what a shame
in construct xor the only cases where ans is not possible
Think about the cases where n == 3 and s is a power of 2. Are those cases possible?
I was stuck at this case only.
oh! i have that case in on of my WA submission but forget about it latter. nice problem Thank you for the contest. missed 5* by 6 points :(
The editorial will be uploaded in some time.
if n = 3 and s = 4*X then what will be solution ??? example n = 3 and s = 16
n = 3 and s = 16 has no solution. s = 4*x will have a solution as long as 4*x is not a power of two.
what is wrong in this submission? I mean i was looking for a counter test case.
if $$$n=3$$$, there must atleast be two set bits in S and S should be even. We can break the bits, in smaller parts like and distribute in the 3 numbers, for eg. if $$$S = (110)_2$$$, we can break the set bits and our 3 numbers will be {$$$(010)_2, (011)_2, (001)_2$$$}. By this process, we can find our answer.
I am shocked how IceKnight1093 even approved some of these ugly problems
Have look at this ;)
It doesn't change the fact that some problems were forced
I love the problems. Thanks for the contest.
Honestly, It looks like you codechef guys have run out of good problems or authors and are just doing weekly contests for formality or because you get sponsors time to time. No hard feelings, i loved and learned a lot from codechef in my first year but seeing contests made by single author most of the times and then a joke contest like this hurts me and also codechef as a brand.
A hint for B :: Palindromic Substrings?
It can be observed that any binary string of length $$$\geq 3$$$ will always contain a palindromic cyclic substring of length $$$\gt 1$$$; meaning the game can only possible end with the length of $$$S$$$ being either $$$1$$$ or $$$2$$$.