+ 1020 (div. 3) + +
++ Unfortunately, the moment this contest started I'd already given up. + In contest my main weakness is that I just rush and panic. If my + next contest results in me wasting 2 hours I'm going to take a step + back and just do intentional practice. +
++ I learned nothing. I didn't read problem statements nor prove my + answers. +
970 (div. 3)04/21/2025
-~1450 performance. OK contest, not very exhilirating. Hedonistic treadmill at work with me solving A-F on Div. 3 when a 2 weeks ago I couldn't even do that on Div. 4. Definitely need to upsolve this to improve my ability at expressing ideas simply. -
From now on, prioritize actually learning and problem-solving in a pressurized format (we all die eventually, everything is under @@ -97,9 +115,9 @@ -++~1300 performance. Consistently finishing E, getting F occasionally. -
- B: took me way too long because I just wanted to code. Wasted 5 @@ -162,11 +180,11 @@ -
++Decent contest. Lost focus near the end and was not paying attention at the start (I was working on my makefile). This is a telltale sign that Div. 4 is a bit too easy. F & G should've been lightwork. -
- D: submitted what I knew to be incorrect. Can't account for @@ -206,23 +224,23 @@ -
++ +Improvement is marginal. My desire for rating is unquenchable (joke). Really, though, I'm improving slower than I like. 1400 performance, my best yet—I'll do one more Div. 4 then I need to upgrade to Div. {2,3}. I think the most core realization I made after this contest was: -
- Separate what your code does from what you think it should do. - Conceptualize an approach, then put it aside. Implement exactly - what the approach says to do (not what you think it should say). - If the approach left something out, - step away from implementing, reconsider the approach, then - resume implementing. Never reconsider and alter your strategy while coding. --+ Separate what your code does from what you think it should do. + Conceptualize an approach, then put it aside. Implement exactly what + the approach says to do (not what you think it should say). If the + approach left something out, + step away from implementing, reconsider the approach, then resume + implementing. Never reconsider and alter your strategy while coding. +
- B: realized parity-based removal immediately. Still, I once again @@ -307,11 +325,11 @@ -
++Defeating. My speed is improving but I completely wasted my focus. Div. 4 is too easy for me to take seriously now. This itself, though, is a problem with discipline. -
I only practice for 2 hours a day. There's no point in practicing problems and not trying—just go do something else. @@ -365,10 +383,10 @@ -++Horrendous competition but I refrain from cringing for the sake of improvement. -
- A: trivial
- @@ -439,17 +457,19 @@ -
++ +Placed top 2000 but did not learn much. Was distracted (thinking about writing this post itself) and was not taking the problems seriously because they were not that challenging in the first place. -
- Take problems seriously or you're wasting your time. -- . I was also continually nervous/pressuring myself and thought about + ++ Take problems seriously or you're wasting your time. +++ I was also continually nervous/pressuring myself and thought about my own thought process. The time for analysis is after, not during. -
Pressure ruins performance.-Pressure ruins performance.
- A: couldn't come up with the extensible solution and checked all @@ -495,7 +515,7 @@ -
++Div. 4 to practice implemenation skills + mathematical observations thanks to Paul Zeitz. From now on, I will only note useful problems. -
- B: typo, costing a few minutes. Go slower. Declare variables. @@ -587,70 +607,68 @@ -
-+Decent.
--
-- - A: math intuition building. Jumped to assuming the problem - statement but it was much simpler. - Answer the problem only. -
-- - B: textbook simple problem that I struggle to mathematically - quantify being distracted by many components. In retrospect, I - should interpret the problem simply like: -
-- Each trap has a known time I must return by. The answer is - therefore the minimum of these. -- I also just plug in \(ceil\) and \(floor\) until I find the - right answer (I'm not lying). Instead, note that for - \(s,k\in\mathbb{Z}\), - \[\frac{s}{2}>k\leftrightarrow\lfloor\frac{s-1}{2}\rfloor\geq - k\]. This simply "edges out" the fractional term to line up - cleanly with the divisor. -- C: cooked. Practice number theory.
-- - D: took me a while because I was distracted with the moving - parts. Specifically, I forgot that I could choose the - permutation and that the question was merely asking to pick the - largest/smallest numbers on \(x\)/\(y\) slots respectively. End - solution was expressive and elegant. - Express the question and reframe the constraints in simple - but accurate terms. -
-- - E: Black-boxed a lazy segment tree (with the help of AI, I must - admit—I need to make a template). -
- In this problem, I immediately saw the application of the lazy - segment tree but decided to hold off on it, failing to find the - simpler prefix-XOR solution. Therefore, I not only wasted my time, - but also cemented in unrealistic practice (I would never do this - in a real contest) and worsened my virtual contest performance. As - for the prefix-XOR solution, focusing on just one/zero - corresponding elements and - walking through small examples - (i.e. "what happens when \(l=r\)?") would've help me pick up the - pattern. -- Everything I did here was wrong and this problem showed an - embarrassingly fundamental flaw in my practice strategy. -- Namely, I should divide up practice time into: --
-- Contests, emphasizing speed and implementation
-- - Single problems, emphasizing specific learning objectives -
-Decent.
++
- + A: math intuition building. Jumped to assuming the problem + statement but it was much simpler. + Answer the problem only. +
+- + B: textbook simple problem that I struggle to mathematically + quantify being distracted by many components. In retrospect, I + should interpret the problem simply like: +
++ Each trap has a known time I must return by. The answer is + therefore the minimum of these. ++ I also just plug in \(ceil\) and \(floor\) until I find the right + answer (I'm not lying). Instead, note that for + \(s,k\in\mathbb{Z}\), + \[\frac{s}{2}>k\leftrightarrow\lfloor\frac{s-1}{2}\rfloor\geq k\]. + This simply "edges out" the fractional term to line up cleanly + with the divisor. +- C: cooked. Practice number theory.
+- + D: took me a while because I was distracted with the moving parts. + Specifically, I forgot that I could choose the permutation and + that the question was merely asking to pick the largest/smallest + numbers on \(x\)/\(y\) slots respectively. End solution was + expressive and elegant. + Express the question and reframe the constraints in simple but + accurate terms. +
+- + E: Black-boxed a lazy segment tree (with the help of AI, I must + admit—I need to make a template). +
+ In this problem, I immediately saw the application of the lazy + segment tree but decided to hold off on it, failing to find the + simpler prefix-XOR solution. Therefore, I not only wasted my time, + but also cemented in unrealistic practice (I would never do this in + a real contest) and worsened my virtual contest performance. As for + the prefix-XOR solution, focusing on just one/zero corresponding + elements and + walking through small examples + (i.e. "what happens when \(l=r\)?") would've help me pick up the + pattern. ++ Everything I did here was wrong and this problem showed an + embarrassingly fundamental flaw in my practice strategy. ++ Namely, I should divide up practice time into: ++
+- Contests, emphasizing speed and implementation
+- + Single problems, emphasizing specific learning objectives +
+1013 (div. 3)03/22/2025
--+- 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 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. +
+891 (div. 3)02/12/2025
--+- 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 - sigpipe) and CSES, using - the - CP Handbook - and browsing by related problem tags with ever-increasing - difficulty. -
-+ 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 + sigpipe) and CSES, using the + CP Handbook + and browsing by related problem tags with ever-increasing + difficulty. +