feat(cp): more cses sorting and searching
This commit is contained in:
parent
1c1346689e
commit
a825851b7f
1 changed files with 305 additions and 232 deletions
|
|
@ -35,6 +35,311 @@
|
|||
<h1 class="post-title">Competitive Programming Log</h1>
|
||||
</header>
|
||||
<article class="post-article">
|
||||
<h2>sorting and searching—24/2/2025</h2>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<div>
|
||||
<ol>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1621" target="_blank"
|
||||
>distinct numbers</a
|
||||
>: unordered classes are exploitable and nearly always tle. Keep
|
||||
it simple, use a map or PBDS.
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1084" target="_blank"
|
||||
>apartments</a
|
||||
>: distracted working on this during class but figured it out.
|
||||
<b>prove statements and use descriptive variable names.</b>
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1090" target="_blank"
|
||||
>ferris wheel</a
|
||||
>: leetcode copy from people fitting in boats. Can't say
|
||||
much because I already did it.
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1091" target="_blank"
|
||||
>concert tickets</a
|
||||
>: totally used PBDS, which is most likely way overkill.
|
||||
<b>if it works, it works</b>.
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1619" target="_blank"
|
||||
>restaurant customers</a
|
||||
>: already seen it (line sweep)
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1629" target="_blank"
|
||||
>movie festival</a
|
||||
>: already seen it but
|
||||
<b>improve greedy/exchange arguments</b>
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/2216" target="_blank"
|
||||
>missing coin sum</a
|
||||
>:
|
||||
<b>I still don't get this. Write it out.</b>
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/2217" target="_blank"
|
||||
>collecting numbers ii</a
|
||||
>: 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 <i>completely</i> understand my idea,
|
||||
which lowered my confidence.
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<h2>more cses—22/2/2025</h2>
|
||||
<div>
|
||||
<ol>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/2205" target="_blank"
|
||||
>gray code</a
|
||||
>: Missed the pattern + <b>gave up too <i>late</i></b>
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/2165" target="_blank"
|
||||
>towers of hanoi</a
|
||||
>: <b>Recursive grasp is limp</b>—missed the idea.
|
||||
<b>Math/proof grasp too</b>—still don't understand how its
|
||||
\(2^n\).
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1623" target="_blank"
|
||||
>apple division</a
|
||||
>: 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".
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/2431">digit queries</a
|
||||
>: got the idea + time complexity quickly, but the
|
||||
<b>math-based implementation is weak</b>. Jumped into the code
|
||||
<i>before</i> outlining a strict plan.
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<h2>cses—21/2/2025</h2>
|
||||
<div>
|
||||
<p>
|
||||
Everyone recommends CSES so I started with it, doing the first 8
|
||||
problems.
|
||||
</p>
|
||||
<ol>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1068" target="_blank"
|
||||
>weird algorithm</a
|
||||
>: Trivial, but I forgot to print 1 at the end.
|
||||
<b>Return the exactly correct answer.</b>
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1083" target="_blank">
|
||||
missing number </a
|
||||
>: N/A
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1069" target="_blank">
|
||||
repetitions </a
|
||||
>: Use invariants.
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1094" target="_blank">
|
||||
increasing array </a
|
||||
>: Run through one iteration of the algorithm. Here, I
|
||||
erroneously added <code>x - last</code> to a quantity,
|
||||
<i>after manipulating <code>x</code></i
|
||||
>.
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1070/" target="_blank"
|
||||
>permutations</a
|
||||
>: I'd seen this problem before yet struggled.
|
||||
<b>Fully understand the problem constraints</b>. In this case,
|
||||
While I understood the definition of a permissible permutation,
|
||||
I didn't fully internalize that you could place number
|
||||
<i>wherever</i> you want. Instead, I was locked in on placing
|
||||
some <code>x</code> at <code>i, i + 2, i + 4, ...</code>.
|
||||
Further, the fact that I didn't immediately recognize this
|
||||
solution means I need to improve at
|
||||
<b>upsolving and reviewing problems</b>.
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1071" target="_blank"
|
||||
>permutations</a
|
||||
>: Absolutely disastrous. I continually just f*dged with the
|
||||
offsets I was adding to my strategy until I happened to get the
|
||||
answer right. <b>Don't guess</b>. Also,
|
||||
<b
|
||||
>don't be lazy—if an algorithm works, focus, write it
|
||||
out, and enjoy being correct</b
|
||||
>.
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1072" target="_blank"
|
||||
>two knights</a
|
||||
>: Required 2 hints from Sam Altman.
|
||||
<b>git gud at combinatorics</b>. Use the paradigm "count good,
|
||||
remove bad." Lock in less on counting specifics—instead,
|
||||
consider what objects <i>mean in aggregate</i>. 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.
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1092" target="_blank"
|
||||
>two sets</a
|
||||
>: <b>Don't lock in on one approach</b>. 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\).
|
||||
<b>git gud at greedy</b>.
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<h2>
|
||||
<a href="https://codeforces.com/contest/1955" target="_blank"
|
||||
>938 (div. 3)</a
|
||||
>—15/2/2025
|
||||
</h2>
|
||||
<div>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<h3>A</h3>
|
||||
<p>Brute-forced it but it still took me a few minutes.</p>
|
||||
<ol>
|
||||
<li>Read (and exploit) problem constraints</li>
|
||||
<li>
|
||||
Go back and derive the linear optimization (choosing the one
|
||||
with better marginal utility)
|
||||
</li>
|
||||
<li>If you have a (simple enough) solution, just go with it.</li>
|
||||
</ol>
|
||||
<h3>B</h3>
|
||||
<p>
|
||||
Easily recognized how to form the matrix (i.e. smallest element
|
||||
first with positive integers \(c,d\)) but tripped up on the
|
||||
implementation.
|
||||
</p>
|
||||
<ol>
|
||||
<li>
|
||||
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 <code>i==n-1</code>) <i>especially</i> on
|
||||
implementation-heavy problems
|
||||
</li>
|
||||
</ol>
|
||||
<h3>C</h3>
|
||||
<p>
|
||||
Did a horrific (but correct) binary search solution. Tripped up by
|
||||
specifics of <code>std::{upper,lower}_bound</code> 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.
|
||||
</p>
|
||||
<ol>
|
||||
<li>THE INT OVERFLOW INCIDENT</li>
|
||||
<li>
|
||||
Deepen understanding of binary search & STL functions to the
|
||||
point that it is second nature
|
||||
</li>
|
||||
<li>Consider simple solutions first.</li>
|
||||
</ol>
|
||||
<h3>D</h3>
|
||||
<p>
|
||||
Instantly recognized sliding window but struggled with minor
|
||||
details (i.e. keeping track of match count) by rushing to the
|
||||
solution.
|
||||
</p>
|
||||
<ol>
|
||||
<li>
|
||||
Problem statement took a long time to grasp. Look at examples
|
||||
and just read through slower (don't rush!)
|
||||
</li>
|
||||
<li>
|
||||
Sliding window grasp isn't <i>rigorous</i>—improve this
|
||||
later
|
||||
</li>
|
||||
<li>
|
||||
When you don't remember 100% of how an algorithm works,
|
||||
<b>mentally walk through a few iterations</b>
|
||||
</li>
|
||||
<li>Improve PBDS API familiarity (practice)</li>
|
||||
</ol>
|
||||
<h3>E</h3>
|
||||
<p>
|
||||
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 <i>before</i> coming back to E, robbing me
|
||||
of 10 minutes that could've been the difference between another
|
||||
solve.
|
||||
</p>
|
||||
<ol>
|
||||
<li>
|
||||
You're not like that. Solve problems in order (most of the time,
|
||||
although skipping to F first was a wise decision).
|
||||
</li>
|
||||
<li>
|
||||
Consider ideas <i>fully</i> before dropping them. I considered
|
||||
the difference array, then <i>discarded</i> it, erroneously
|
||||
believing a boolean was sufficient and completely forgetting
|
||||
that the concept of ranges complicates flipping.
|
||||
</li>
|
||||
<li>
|
||||
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.
|
||||
</li>
|
||||
<li>
|
||||
Prove correctness. I didn't prove that iterating left to right,
|
||||
toggling a range of k actually would always give a correct
|
||||
answer.
|
||||
</li>
|
||||
</ol>
|
||||
<h3>F</h3>
|
||||
<p>
|
||||
Had the solution quickly but overcomplicated the implementation.
|
||||
Walked through the examples and took my time.
|
||||
</p>
|
||||
<ol>
|
||||
<li>
|
||||
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.
|
||||
</li>
|
||||
</ol>
|
||||
<h3>G</h3>
|
||||
<p>
|
||||
Wasted time believing this was primitive DP, when it totally
|
||||
wasn't.
|
||||
</p>
|
||||
<ol>
|
||||
<li>You're not that guy (yet >:))</li>
|
||||
<li>
|
||||
Prove optimal substructure and overlapping subproblems before
|
||||
using DP & walk through the test cases. In this case, test case
|
||||
3 immediately disproves dp.
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<h2>the beginning—12/2/2025</h2>
|
||||
<div>
|
||||
<p>
|
||||
|
|
@ -61,238 +366,6 @@
|
|||
difficulty.
|
||||
</p>
|
||||
</div>
|
||||
<h2>
|
||||
<a href="https://codeforces.com/contest/1955" target="_blank"
|
||||
>938 (div. 3)</a
|
||||
>—15/2/2025
|
||||
</h2>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<h3>A</h3>
|
||||
<p>Brute-forced it but it still took me a few minutes.</p>
|
||||
<ul>
|
||||
<li>Read (and exploit) problem constraints</li>
|
||||
<li>
|
||||
Go back and derive the linear optimization (choosing the one with
|
||||
better marginal utility)
|
||||
</li>
|
||||
<li>If you have a (simple enough) solution, just go with it.</li>
|
||||
</ul>
|
||||
<h3>B</h3>
|
||||
<p>
|
||||
Easily recognized how to form the matrix (i.e. smallest element
|
||||
first with positive integers \(c,d\)) but tripped up on the
|
||||
implementation.
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
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 <code>i==n-1</code>) <i>especially</i> on
|
||||
implementation-heavy problems
|
||||
</li>
|
||||
</ul>
|
||||
<h3>C</h3>
|
||||
<p>
|
||||
Did a horrific (but correct) binary search solution. Tripped up by
|
||||
specifics of <code>std::{upper,lower}_bound</code> 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.
|
||||
</p>
|
||||
<ul>
|
||||
<li>THE INT OVERFLOW INCIDENT</li>
|
||||
<li>
|
||||
Deepen understanding of binary search & STL functions to the point
|
||||
that it is second nature
|
||||
</li>
|
||||
<li>Consider simple solutions first.</li>
|
||||
</ul>
|
||||
<h3>D</h3>
|
||||
<p>
|
||||
Instantly recognized sliding window but struggled with minor details
|
||||
(i.e. keeping track of match count) by rushing to the solution.
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
Problem statement took a long time to grasp. Look at examples and
|
||||
just read through slower (don't rush!)
|
||||
</li>
|
||||
<li>
|
||||
Sliding window grasp isn't <i>rigorous</i>—improve this
|
||||
later
|
||||
</li>
|
||||
<li>
|
||||
When you don't remember 100% of how an algorithm works,
|
||||
<b>mentally walk through a few iterations</b>
|
||||
</li>
|
||||
<li>Improve PBDS API familiarity (practice)</li>
|
||||
</ul>
|
||||
<h3>E</h3>
|
||||
<p>
|
||||
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 <i>before</i> coming back to E, robbing me of 10
|
||||
minutes that could've been the difference between another solve.
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
You're not like that. Solve problems in order (most of the time,
|
||||
although skipping to F first was a wise decision).
|
||||
</li>
|
||||
<li>
|
||||
Consider ideas <i>fully</i> before dropping them. I considered the
|
||||
difference array, then <i>discarded</i> it, erroneously believing
|
||||
a boolean was sufficient and completely forgetting that the
|
||||
concept of ranges complicates flipping.
|
||||
</li>
|
||||
<li>
|
||||
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.
|
||||
</li>
|
||||
<li>
|
||||
Prove correctness. I didn't prove that iterating left to right,
|
||||
toggling a range of k actually would always give a correct answer.
|
||||
</li>
|
||||
</ul>
|
||||
<h3>F</h3>
|
||||
<p>
|
||||
Had the solution quickly but overcomplicated the implementation.
|
||||
Walked through the examples and took my time.
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
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.
|
||||
</li>
|
||||
</ul>
|
||||
<h3>G</h3>
|
||||
<p>
|
||||
Wasted time believing this was primitive DP, when it totally wasn't.
|
||||
</p>
|
||||
<ul>
|
||||
<li>You're not that guy (yet >:))</li>
|
||||
<li>
|
||||
Prove optimal substructure and overlapping subproblems before
|
||||
using DP & walk through the test cases. In this case, test case 3
|
||||
immediately disproves dp.
|
||||
</li>
|
||||
</ul>
|
||||
<h2>cses—21/2/2025</h2>
|
||||
<p>
|
||||
Everyone recommends CSES so I started with it, doing the first 8
|
||||
problems.
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1068" target="_blank"
|
||||
>weird algorithm</a
|
||||
>: Trivial, but I forgot to print 1 at the end.
|
||||
<b>Return the exactly correct answer.</b>
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1083" target="_blank">
|
||||
missing number </a
|
||||
>: N/A
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1069" target="_blank">
|
||||
repetitions </a
|
||||
>: Use invariants.
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1094" target="_blank">
|
||||
increasing array </a
|
||||
>: Run through one iteration of the algorithm. Here, I erroneously
|
||||
added <code>x - last</code> to a quantity,
|
||||
<i>after manipulating <code>x</code></i
|
||||
>.
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1070/" target="_blank"
|
||||
>permutations</a
|
||||
>: I'd seen this problem before yet struggled.
|
||||
<b>Fully understand the problem constraints</b>. In this case,
|
||||
While I understood the definition of a permissible permutation, I
|
||||
didn't fully internalize that you could place number
|
||||
<i>wherever</i> you want. Instead, I was locked in on placing some
|
||||
<code>x</code> at <code>i, i + 2, i + 4, ...</code>. Further, the
|
||||
fact that I didn't immediately recognize this solution means I
|
||||
need to improve at <b>upsolving and reviewing problems</b>.
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1071" target="_blank"
|
||||
>permutations</a
|
||||
>: Absolutely disastrous. I continually just f*dged with the
|
||||
offsets I was adding to my strategy until I happened to get the
|
||||
answer right. <b>Don't guess</b>. Also,
|
||||
<b
|
||||
>don't be lazy—if an algorithm works, focus, write it out,
|
||||
and enjoy being correct</b
|
||||
>.
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1072" target="_blank"
|
||||
>two knights</a
|
||||
>: Required 2 hints from Sam Altman.
|
||||
<b>git gud at combinatorics</b>. Use the paradigm "count good,
|
||||
remove bad." Lock in less on counting specifics—instead,
|
||||
consider what objects <i>mean in aggregate</i>. 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.
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1092" target="_blank"
|
||||
>two sets</a
|
||||
>: <b>Don't lock in on one approach</b>. 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\). <b>git gud at greedy</b>.
|
||||
</li>
|
||||
</ul>
|
||||
<h2>more cses—22/2/2025</h2>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/2205" target="_blank"
|
||||
>gray code</a
|
||||
>: Missed the pattern + <b>gave up too <i>late</i></b>
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/2165" target="_blank"
|
||||
>towers of hanoi</a
|
||||
>: <b>Recursive grasp is limp</b>—missed the idea.
|
||||
<b>Math/proof grasp too</b>—still don't understand how its
|
||||
\(2^n\).
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/1623" target="_blank"
|
||||
>apple division</a
|
||||
>: 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".
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://cses.fi/problemset/task/2431">digit queries</a>:
|
||||
got the idea + time complexity quickly, but the
|
||||
<b>math-based implementation is weak</b>. Jumped into the code
|
||||
<i>before</i> outlining a strict plan.
|
||||
</li>
|
||||
</ul>
|
||||
</article>
|
||||
</div>
|
||||
</main>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue