Competitive Programming Log

Solved in a coffee shop. Used AI for smaller things (otherwise I'd have no idea).

• A: Solved a much harder problem related to majority element paths on tree—realized the solution after a minute.
• B: was confused for about 7 minutes but realized some properties of divisibility and odd numbers. Math is still a weakness. Take simpler approaches to complex constraints, such as considering parity.
• Went off of gut instinct that it is always possible to form the given \(x\) if encompassed in the range of numbers. Failed to prove this mathematical validity but had fair intuition (i.e. just "take off one" if too big/small). This is acceptable, though not perfect.
• D: cooked. Solved E first and had mentally given up by this point. If you've given up, just stop trying and take a break/do something else. You're wasting your time.
• E: incredibly easy with segtree. Realized the lower bound/walk solution after 2-3 minutes. Binary search indexing can be improved (i.e. which pointer to return?) as well as realizing one binary search is necessary across both arrays. Good mathematical deduction to realize relationship between input arrays. Revisit sparse table + simpler solution—don't be content with an advanced solution when a simpler/elegant idea also suffices.

Solved partially on the plane and at home. Best round in terms of acceptance rate. After bombing another codeforces contest & more CSES work, it's clear that my biggest weakness is algorithmic correctness and certainty. To remedy:

• Test edge cases (boundary + tricky)
• Don't submit unless you're certain you're right
• In analysis, leave no stone unturned (be thorough)
• Don't rely on the given test cases as proof of correctness.

1. A: ironically, although I got AC in ~1 minute, this is exactly where I go wrong. I did not check the actual correctness of my parity checks but submitted anyway.
2. B: AC once again but implementation is still a weakness. In this case, it was due to a lack of problem understanding, i.e. rounding up sets all right digits to 0, but carries can still affect the number after that.
3. C: skipped and came back later. The idea of sorting came up but I was overwhelmed. My end solution was a bit overcomplicated but still logically sound. I'm getting better at making observations, in this case explicitly identifying the fact that the largest element must have one more element greater than or equal to itself, permitting you to build the answer in reverse order. Did not prove the correctness of this.
4. D: skipped and came back later. Given the large amount of vertices I did a good job of rephrasing the data (thanks George Pólya) and proving the correctness with transitivity/contradiction. Initial solution complex—ponder implementation before going at it.
5. E: took me a while (I believe) because I was on a plane without a notebook and visualizing was hard. Good mathematical formulation, but initially returned the answer in wrong order. Relied on the test cases to save me—ensure you're solving the actual problem (in this case, returning the queries in the right order).
6. F: Quadratic equation flew over my head. I was unsure but should've just played with the numbers—if you plug them in, you derive the quadratic equation relevant to the problem. I then (maybe) could've gotten an answer. Instead, I was intimidated because I thought I needed some fancy DSA/dp/two-pointers/two-sum thing. Just have to build more intuition. Also, totally did not know how to count number of distinct pairs \(i, j\) with \(i\lt j\) for two elements. I missed the case when the elements are equal and, yes, seriously forgot it is just the product (I do not want to talk about it but thanks Deepseek). Overflow, again. rly dude?
7. F: doing this later, got the core insight of the minimal weight edge path. Once again, for surveying path

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.

1. static range minimum queries: sparse table. copy-pasted from template, should be able to derive
2. range update queries: fenwick tree difference array. understanding of fenwick trees fundamentally flawed. "guessed and checked" on the ranges to update.
3. forest queries: inclusion-exclusion principles. think before implement.
4. hotel queries: fun question, derived segment tree {lower,upper}_bound (a "walk", apparently).
5. 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).
6. 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.

1. A: easy, messed up on the math a bit for a second
2. 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.
3. 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.
4. 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.

1. distinct numbers: unordered classes are exploitable and nearly always tle. Keep it simple, use a map or PBDS.
2. apartments: distracted working on this during class but figured it out. prove statements and use descriptive variable names.
3. ferris wheel: leetcode copy from people fitting in boats. Can't say much because I already did it.
4. concert tickets: totally used PBDS, which is most likely way overkill. if it works, it works.
5. restaurant customers: already seen it (line sweep)
6. movie festival: already seen it but improve greedy/exchange arguments
7. missing coin sum: I still don't get this. Write it out.
8. collecting numbers ii: I had the exactly correct idea but I thought it was too complex. Practice will improve me developing my better sense of this. Still, I didn't completely understand my idea, which lowered my confidence.

1. gray code: Missed the pattern + gave up too late
2. towers of hanoi: Recursive grasp is limp—missed the idea. Math/proof grasp too—still don't understand how its \(2^n\).
3. apple division: I got distracted by the idea that it was NP-hard. Even when Sam Altman told me it was DP, I failed to simplify it to "add every element either to one or the other set".
4. digit queries: got the idea + time complexity quickly, but the math-based implementation is weak. Jumped into the code before outlining a strict plan.

Everyone recommends CSES so I started with it, doing the first 8 problems.

1. weird algorithm: Trivial, but I forgot to print 1 at the end. Return the exactly correct answer.
2. missing number : N/A
3. repetitions : Use invariants.
4. increasing array : Run through one iteration of the algorithm. Here, I erroneously added x - last to a quantity, after manipulating x.
5. permutations: I'd seen this problem before yet struggled. Fully understand the problem constraints. In this case, While I understood the definition of a permissible permutation, I didn't fully internalize that you could place number wherever you want. Instead, I was locked in on placing some x at i, i + 2, i + 4, .... Further, the fact that I didn't immediately recognize this solution means I need to improve at upsolving and reviewing problems.
6. permutations: Absolutely disastrous. I continually just f*dged with the offsets I was adding to my strategy until I happened to get the answer right. Don't guess. Also, don't be lazy—if an algorithm works, focus, write it out, and enjoy being correct.
7. two knights: Required 2 hints from Sam Altman. git gud at combinatorics. Use the paradigm "count good, remove bad." Lock in less on counting specifics—instead, consider what objects mean in aggregate. In this case, a \(2\times3\) grid represents an "area" of attack, contributing 2 bad knight pairs. This is much easier to digest then attempting to remove overcounting per-knight. Fundamentally, the problem involves placing 2 knights, so breaking it down 2 knights at a time is the most intuitive take.
8. two sets: Don't lock in on one approach. Here, this is dp. The fact that I knew the idea of partitioning the first \(n\) numbers into two groups of size \(\frac{n(n+1)}{4}\) but failed to recognize the greedy approach means I didn't grasp the fundamental arithmetic of the problem, nor the greedy idea: every number must go into a set. If you add the largest number possible to set 1 to not exceed the target, this number can always be formed in the other set by choosing \(1\) and \(x-1\). git gud at greedy.

What would've been my best contest. Unfortunately, CodeForces decided to go down for TREE[3] centuries, which absolutely ruined my groove in the contest and terminated my virtual. No excuses, though, as I set a timer and finished up later.

A

Brute-forced it but it still took me a few minutes.

1. Read (and exploit) problem constraints
2. Go back and derive the linear optimization (choosing the one with better marginal utility)
3. If you have a (simple enough) solution, just go with it.

B

Easily recognized how to form the matrix (i.e. smallest element first with positive integers \(c,d\)) but tripped up on the implementation.

1. Flesh out the steps before coding (i.e. walk through iterations in head, transitions, edge cases on the rows and columns, i.e. checking if i==n-1) especially on implementation-heavy problems

C

Did a horrific (but correct) binary search solution. Tripped up by specifics of std::{upper,lower}_bound regardless. Technically, generating the prefix and postfix arrays takes two passes and two binary searches to find the answer but this is still more inefficient than the trivial linear scan.

1. THE INT OVERFLOW INCIDENT
2. Deepen understanding of binary search & STL functions to the point that it is second nature
3. Consider simple solutions first.

D

Instantly recognized sliding window but struggled with minor details (i.e. keeping track of match count) by rushing to the solution.

1. Problem statement took a long time to grasp. Look at examples and just read through slower (don't rush!)
2. Sliding window grasp isn't rigorous—improve this later
3. When you don't remember 100% of how an algorithm works, mentally walk through a few iterations
4. Improve PBDS API familiarity (practice)

E

I had mentally tapped out by this point (I submitted a TLE \(O(n^2k)\) solution without using my brain). I solved F first, then took a look at G before coming back to E, robbing me of 10 minutes that could've been the difference between another solve.

1. You're not like that. Solve problems in order (most of the time, although skipping to F first was a wise decision).
2. Consider ideas fully before dropping them. I considered the difference array, then discarded it, erroneously believing a boolean was sufficient and completely forgetting that the concept of ranges complicates flipping.
3. Formalize constraints more clearly to help form a solution. For example, the idea that flipping things twice makes no difference, permitting the use of a boolean difference array.
4. Didn't get it, still don't get it, don't know why. Way easier than D.
5. Prove correctness. I didn't prove that iterating left to right, toggling a range of k actually would always give a correct answer.

F

Had the solution quickly but overcomplicated the implementation. Walked through the examples and took my time.

1. Failed to formalize the answer to the problem. I noticed patterns but should've strictly defined the following rule: "Every even count of a number contributes one to the score. Further, one triple of 1, 2, 3 also contributes one." Ultimately, I ended up submitting something I wasn't certain would be correct.

G

Wasted time believing this was primitive DP, when it totally wasn't.

1. You're not that guy (yet >:))
2. Prove optimal substructure and overlapping subproblems before using DP & walk through the test cases. In this case, test case 3 immediately disproves dp.

This marks the (true) beginning of my competitive programming journey. By "true" I mean intentional, focused, daily practice. Driven by my admiration for competitive programmers, love of challenge, and desire for a decent new-grad job, I'm excited to start putting in the work.

This webpage will be an archive of everything related to this process, including my practice strategies, setup, shortcomings, logs, and more. For now, I'll be practicing on CodeForces (account sigill) and CSES, using the CP Handbook and browsing by related problem tags with ever-increasing difficulty.