Please subscribe to the official Codeforces channel in Telegram via the link https://t.me/codeforces_official. ×

BledDest's blog

By BledDest, 2 months ago,

1879A - Rigged!

Idea: Roms

Tutorial
Solution (Roms)

1879B - Chips on the Board

Idea: BledDest

Tutorial
Solution (Neon)

1879C - Make it Alternating

Idea: Roms

Tutorial
Solution (Roms)

1879D - Sum of XOR Functions

Idea: Roms

Tutorial
Solution (Roms)

1879E - Interactive Game with Coloring

Idea: BledDest

Tutorial
Solution (BledDest)

1879F - Last Man Standing

Idea: BledDest

Tutorial
Solution (awoo)
• +76

 » 2 months ago, # |   +5 Clear editorial!
 » 2 months ago, # |   +1 Clear Editorial, but it should have appeared in a more clear place lmao
•  » » 2 months ago, # ^ |   +3 It's now in the right place now
 » 2 months ago, # |   0 the editorial link in the contest problems is wrong, (problem c).
 » 2 months ago, # |   +6 D was pretty fun
•  » » 2 months ago, # ^ |   0 Agreed
 » 2 months ago, # |   0 There is a question on task D, why we don't take into account carry-over units from previous digits when counting the i-th bit? Thanks in advance.
•  » » 2 months ago, # ^ |   0 There are no such carry-over units because it is the sum of XOR not plus(maybe)
•  » » » 2 months ago, # ^ |   0 Yes, I agree, but after XOR we also add them to each other and we have to take into account that the previous bits affect the current one
•  » » » » 2 months ago, # ^ |   0 if the i-th bit is on then it contribute to the sum as (1 << i).
 » 2 months ago, # |   +8 F was really fun
 » 2 months ago, # |   +1 In D's editorial, if pref(x) is equal to the number of ones on the prefix of length x modulo 2, then for even number of ones, shouldn't pref(x) be 0?
•  » » 2 months ago, # ^ |   +1 Yeah, this is an error, thank you. Will be fixed in a couple of minutes
 » 2 months ago, # |   -21 E is so cringe
 » 2 months ago, # |   0 For anyone else struggling to formalize why their intuition for B leads to an optimal arrangement of chips:The key insight is what the tutorial notes -- a valid chip arrangement must satisfy either (1) each row has at least 1 chip or (2) each column has at least 1 chip.Now, we have two cases.Say we have a valid chip arrangement that satisfies (1). Then, we can make an arrangement that is as cheap or cheaper by removing any extra chips so that each row has exactly one chip (vs. at least one). From here, observe that the cheapest 1-chip-per-row arrangement is the one you get by picking the cheapest column and filling each cell in it with a chip. Any other 1-chip-per-row arrangement is more expensive because there will be a chip in the same row, but a more expensive column.Similarly, say we have a valid chip arrangement that satisfies (2). Then, we can make an arrangement that is as cheap or cheaper by removing any extra chips so that each column has exactly one chip (vs. at least one). From here, observe that the cheapest 1-chip-per-column arrangement is the one you get by picking the cheapest row and filling each cell in it with a chip. Any other 1-chip-per-column arrangement will be more expensive because there will be a chip in the same column, but a more expensive row.
•  » » 2 months ago, # ^ |   +10 Proof of the insight: Suppose that there is at least one row missing and at least one column missing. You can then pick a cell such that the cells location is (missing row,missing col) which isn’t covered.
 » 2 months ago, # | ← Rev. 2 →   +9 In problem F, it's not necessary to use a sparse table. It is enough to store 2 maximums for every suffix and for a segment [l, r] we can take suff max on [l, a]. This works because if exist some hj >= hi, where l <= i <= r and j > r, we will get j's real value in a different segment and this value will be definitely greater than i's
•  » » 2 months ago, # ^ |   0 Oh, that's neat. Cool idea!
 » 2 months ago, # |   0 can someone explain D, such that we are taking L as fixed and varying R, then incorporating the length of the subarray factor? please tell me the distance update in this code (code for XOR sum of all subarray) Your code here... #include using namespace std; int main(){ int n; cin>>n; vector arr(n); for(int i=0; i>arr[i]; } int ans = 0; int mul = 1; for(int i=0; i<32; i++){ int c_odd = 0; bool odd = false; for(int j=0; j0){ odd = (!odd); } if(odd){ c_odd++; } } for(int j=0; j
 » 2 months ago, # | ← Rev. 2 →   0 Thanks to the authors for their work on this round :)Here is my advice about the problems ANice A, simple statement, it's not an A+B problem, no ""math"" involved BGetting the right difficulty for B is super hard but I believe that this was a great B! It is also very éducative. CThe problem feels a bit too standard but I think it's fine since it's impossible to always create fresh problems (+ it's an edu round and this problem is indeed educative) DI feel like it was maybe a bit too easy for D. The problem is still cool (and educative) though. EI find this problem really cool! It felt very original and it was fun to solve.
 » 2 months ago, # |   +3 Nsqrtn pass on F:225085205
 » 2 months ago, # |   0 In problem D, can someone please explain how are they handling 1 in (r — l + 1) while computing the answer ?
•  » » 2 months ago, # ^ | ← Rev. 2 →   0 I'm having the same problem over the past two days.i can get the Xor sum of all subarrays but intervalls is pretty hard for me .did you get it ?
•  » » » 2 months ago, # ^ |   0 I inferred it this way.As we know (r — l + 1) is the length of the subarray and we are computing the prefix sums on the bits-array comprising of 0s and 1s. If you look at the editorial code, the sumOfL[x] denotes the sum of lengths of subarray where parity of count of 1s is x. Now, if for the given r, let say there are 3 subarrays with odd count of 1s. Then our ans is (1 << b) * 3 * r — (1 << b) * (sum of l values for those 3 subarrays). We compute length from the difference of lengths of subarray ending at r — subarray ending at l.Hope that helps or atleast give you some direction.
 » 2 months ago, # |   0 can someone explain why have we considered every number as 0 or 1 in PROBLEM D.i could'nt understand the editorial.it would be really helpful.
•  » » 2 months ago, # ^ | ← Rev. 2 →   0 We do this to find out how much each bit contributes to the final answer. We are xoring a bunch of different segments of the original array, but we know the numbers, and we know which of those numbers have n-th bit set. This means we can very quickly find out which segments $[l;r]$ will have the bit set after xoring, prefix sum can answer that. We also know the length of those segments, the $(r-l+1)$ factor, so we have everything, after calculating it on single bits you need to construct the answer back by shifting to left, and summing up all those answers for different bits.I think the hardest thing in this problem is noticing that the prefix sum allows to find all the "working" segments for given bit, but there's no way to do that without taking the numbers apart into single bits.If this still doesn't help, solve an example where the numbers are actually all 0 and 1, because it's easy to follow.
•  » » » 2 months ago, # ^ |   0 Oh now I understood. Thanks for clarification.
 » 2 months ago, # |   0 How are we colouring a bamboo (All nodes having one child except the last one) in E ?
•  » » 3 weeks ago, # ^ |   0 By the explanation, it will use three colors. 1 2 3 1 2 3 ...
 » 6 weeks ago, # | ← Rev. 4 →   0 My approach on C: If we consider a maximal block of same character sequence of size say $l$ then the number of ways we can pick an element to survive in that block is $l$ ways, after which there exists $(l-1)!$ arrangements to delete the remaining elements in the block. Hence there exists a total of $(l - 1)! \times l = l!$ ways within the block to perform the valid operation. And if there are $k$ such blocks then there exists a total of $\prod_{i}^{k}l_{i}!$ valid operations. This approach fails however, not sure why. Any help/corrections appreciated!
•  » » 8 days ago, # ^ |   0 Did you figure it out?
•  » » » 8 days ago, # ^ |   0 I just thought of a counter example: 0011 expected answer: 8 because n-k = 2 -> 2!*2*2 = 8 The solution you provided is 4. Still not sure why it doesn’t work
•  » » » » 8 days ago, # ^ | ← Rev. 2 →   0 So after thinking for a bit your solution only computes the number of ways to permute each group, in other words, the number of ways you can pick a number from each of the groups. It doesn’t take into account that you can select numbers from different groups before fully finishing one group (I don't know if that makes sense).