cses (range queries, sorting and searching)—1/3/2025
+
+
+ + A good review and challenge of data strucures. I've become even + more of a fan of CSES. On codeforces, the application of fenwick + trees and segment trees are usually on problems out of my reach, + where I'm battling both the problem and the data structures. +
+-
+
- + static range minimum queries: sparse table. copy-pasted from + template, should be able to derive + +
- + range update queries: fenwick tree difference array. + understanding of fenwick trees fundamentally flawed. "guessed + and checked" on the ranges to update. + +
- + forest queries: inclusion-exclusion principles. + think before implement. + +
-
+ hotel queries: fun question, derived segment tree
+
{lower,upper}_bound(a "walk", apparently). +
+ -
+ list removals: overcomplicated it a lot. Note that an index can
+ be interpreted as a relative position into an array, so an
+ indexed set works perfectly fine.
+ Reinterpret problem constraints.
+ Extreme lack of familiarity with PBDS/STL APIs. I
+ constantly confuse
find_by_order, +order_of_key,erase(*it)vs. +erase(it). +
+ -
+ traffic lights: destroyed. I'm at the point where I thought "oh,
+ there's no way I'd need two data structures. Too complicated,
+ let me see the solution."
+ Trust your intuition a bit more, especially if you know your
+ solution will lead to a right answer. The offline solution also fully went over my head, in which
+ answering queries backwards presents a 4x (performance-wise)
+ faster solution.
+ Answer the question—you can do so by any means
+ necessary. In this case, reinterpreting the key insight that adding a
+ traffic like can only shrink intervals to removing a traffic
+ light can only increase them isn't only enough. I knew handling
+ the first case simply was too hard but I needed to
+ dig deeper into ideas. In this case, asking "ok, well is
+ it easier to answer the queries in reverse order? Well, yes,
+ because removing the
ith light can either create a + larger gap around it, which I can easily find, or its the same + gap as before" would've saved me. +
+
+ 1006 (div. 3)—25/2/2025 +
+
+
-
+
- A: easy, messed up on the math a bit for a second +
- + B: for the second contest in a row, missed a B and solved E or + later. Solved ~2 min after the contest ended. + Prove mathematical correctness. Here, I did not and still + don't fully understand why a configuration like: + “hyphens...underscores...hyphens>” is even + optimal... + Still, I was mad that I couldn't get it and submitted + solutions that I had nowhere near certainty of their + correctness. If you aren't sure, you're better off + skipping it. Fortunately, in this case, maximizing your codeforces ranking + also coincides wiht optimal problem-solving: don't guess. + +
- + C: knew a solution almost instantly but got held up nearly 30 + minutes on small implementation details and edge cases. Ended up + submitted something I wasn't certain was correct. Taking an + explicit extra minute to consider: “what do I print for + the last case? I must maximize the MEX and ensure the bitwise OR + equals x. If the MEX hits x, then print it. Otherwise, print + x” would've saved me upwards of 10 minutes. + +
- + E: masterclass in throwing. I knew the algorithm pretty much + immediately (manhattan distances and euclidean distances must be + equals means at least one coordinate must be the same between + each point). I then broke it down into building pairs + column-wise, the correct approach. Then, I simply + forgot to check a core constraint of the problem: place + \(\leq500\) staffs. I decided to brute force the last pairs rather than repeat + the strategy, which actually runs in logarithmic time (I also + didn't prove this). The final product was elegant, at + least. + +
sorting and searching—24/2/2025
A lot of these problems I'd seen before but this is good @@ -305,6 +416,10 @@ example, the idea that flipping things twice makes no difference, permitting the use of a boolean difference array. +