sorting and searching—24/2/2025
++ A lot of these problems I'd seen before but this is good + practice anyway. This really is a great problem set. After being + stuck on implementation details, I took less time banging my head + against the wall and just looked at the solution. +
+-
+
- + distinct numbers: unordered classes are exploitable and nearly always tle. Keep + it simple, use a map or PBDS. + +
- + apartments: distracted working on this during class but figured it out. + prove statements and use descriptive variable names. + +
- + ferris wheel: leetcode copy from people fitting in boats. Can't say + much because I already did it. + +
- + concert tickets: totally used PBDS, which is most likely way overkill. + if it works, it works. + +
- + restaurant customers: already seen it (line sweep) + +
- + movie festival: already seen it but + improve greedy/exchange arguments + +
- + missing coin sum: + I still don't get this. Write it out. + +
- + 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. + +
more cses—22/2/2025
+-
+
- + gray code: Missed the pattern + gave up too late + +
- + towers of hanoi: Recursive grasp is limp—missed the idea. + Math/proof grasp too—still don't understand how its + \(2^n\). + +
- + 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". + +
- + digit queries: got the idea + time complexity quickly, but the + math-based implementation is weak. Jumped into the code + before outlining a strict plan. + +
cses—21/2/2025
++ Everyone recommends CSES so I started with it, doing the first 8 + problems. +
+-
+
- + weird algorithm: Trivial, but I forgot to print 1 at the end. + Return the exactly correct answer. + +
- + + missing number : N/A + +
- + + repetitions : Use invariants. + +
-
+
+ increasing array : Run through one iteration of the algorithm. Here, I
+ erroneously added
x - lastto a quantity, + after manipulatingx. +
+ -
+ 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
xati, 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. +
+ - + 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. + +
- + 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. + +
- + 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. + +
+ 938 (div. 3)—15/2/2025 +
++ 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.
+-
+
- Read (and exploit) problem constraints +
- + Go back and derive the linear optimization (choosing the one + with better marginal utility) + +
- 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. +
+-
+
-
+ 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.
+
-
+
- THE INT OVERFLOW INCIDENT +
- + Deepen understanding of binary search & STL functions to the + point that it is second nature + +
- 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. +
+-
+
- + Problem statement took a long time to grasp. Look at examples + and just read through slower (don't rush!) + +
- + Sliding window grasp isn't rigorous—improve this + later + +
- + When you don't remember 100% of how an algorithm works, + mentally walk through a few iterations + +
- 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. +
+-
+
- + You're not like that. Solve problems in order (most of the time, + although skipping to F first was a wise decision). + +
- + 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. + +
- + 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. + +
- + 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. +
+-
+
- + 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. +
+-
+
- You're not that guy (yet >:)) +
- + Prove optimal substructure and overlapping subproblems before + using DP & walk through the test cases. In this case, test case + 3 immediately disproves dp. + +
the beginning—12/2/2025
@@ -61,238 +366,6 @@ difficulty.
- 938 (div. 3)—15/2/2025 -
-- 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.
--
-
- Read (and exploit) problem constraints -
- - Go back and derive the linear optimization (choosing the one with - better marginal utility) - -
- 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. -
--
-
-
- 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.
-
-
-
- THE INT OVERFLOW INCIDENT -
- - Deepen understanding of binary search & STL functions to the point - that it is second nature - -
- 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. -
--
-
- - Problem statement took a long time to grasp. Look at examples and - just read through slower (don't rush!) - -
- - Sliding window grasp isn't rigorous—improve this - later - -
- - When you don't remember 100% of how an algorithm works, - mentally walk through a few iterations - -
- 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. -
--
-
- - You're not like that. Solve problems in order (most of the time, - although skipping to F first was a wise decision). - -
- - 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. - -
- - 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. - -
- - 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. -
--
-
- - 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. -
--
-
- You're not that guy (yet >:)) -
- - Prove optimal substructure and overlapping subproblems before - using DP & walk through the test cases. In this case, test case 3 - immediately disproves dp. - -
cses—21/2/2025
-- Everyone recommends CSES so I started with it, doing the first 8 - problems. -
--
-
- - weird algorithm: Trivial, but I forgot to print 1 at the end. - Return the exactly correct answer. - -
- - - missing number : N/A - -
- - - repetitions : Use invariants. - -
-
-
- increasing array : Run through one iteration of the algorithm. Here, I erroneously
- added
x - lastto a quantity, - after manipulatingx. -
- -
- 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
-
xati, 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. -
- - - 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. - -
- - 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. - -
- - 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. - -
more cses—22/2/2025
--
-
- - gray code: Missed the pattern + gave up too late - -
- - towers of hanoi: Recursive grasp is limp—missed the idea. - Math/proof grasp too—still don't understand how its - \(2^n\). - -
- - 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". - -
- - digit queries: - got the idea + time complexity quickly, but the - math-based implementation is weak. Jumped into the code - before outlining a strict plan. - -