fix: typos

src/content/posts/algorithms/competitive-programming-log.mdx

@@ -8,7 +8,7 @@ useKatex: true
 
 First contest in a while. Implementation lacked heavily but solving harder problems made easier problems easier.
 
-- A: rust immediately showed with the brute force. Since $n\cdot m\leq 25$, at most $\lceil\log_2(25)\rceil=5$ concatenations need to be made. **Slow down and consider constrains**.
+- A: rust immediately showed with the brute force. Since $n\cdot m\leq 25$, at most $\lceil\log_2(25)\rceil=5$ concatenations need to be made. **Slow down and consider constraints**.
 - B: Similarly, mathematical insight and just _playing with parameters_/quantifying the effects of operations is important. **Test your conjectures, they may be right/helpful** (ie. "I must maintain the shortest length thread").
 - C: implementation weak. Simplify, step back, simplify, continuously. I stopped considering altering the grid and used a pair of coordinates but deriving the others inline, _if you trust your mathematics_, is way simpler.
 - D: formalize your answer better. Understand prime factorization more. Improve/memorize asymptotic bounds of factoring and prime counting. Don't overcomplicate the problem—here, I erroneously thought it was asking for minimum operations, not possibility. In reality, all this problem asks is: "Are the total number of each factor greater than one divisible by $n$?"
@@ -19,7 +19,7 @@ I must heed the advice of Colin Galen. I rush trivial problems because they're b
 
 These problems are (mostly) easy but they help me prefer convenient implementation. It is time to be done with bronze.
 
-Implementation, loops, invariants. I still struggle to get a grasp.I struggled with [this problem](https://usaco.org/index.php?page=viewproblem2&cpid=592) just figuring out how to do the loops and invariants. I do a loop of "this works"$\rightarrow$ "let's simplify" $\rightarrow$ "that doesn't work" $\rightarrow ...$ over and over again... _even when the right solution comes across my mind_. In this case, choosing an invariant was just overwhelming. **The simplest correct solution is always the right one**.
+Implementation, loops, invariants. I still struggle to get a grasp. I struggled with [this problem](https://usaco.org/index.php?page=viewproblem2&cpid=592) just figuring out how to do the loops and invariants. I do a loop of "this works"$\rightarrow$ "let's simplify" $\rightarrow$ "that doesn't work" $\rightarrow ...$ over and over again... _even when the right solution comes across my mind_. In this case, choosing an invariant was just overwhelming. **The simplest correct solution is always the right one**.
 
 ## [usaco bronze: complete search](https://usaco.guide/bronze/intro-complete) 04/27/2025
 
@@ -43,21 +43,21 @@ I learned nothing. I didn't read problem statements nor prove my answers.
 
 ## [970 (div. 3)](https://codeforces.com/contest/2008) 21/04/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.
+~1450 performance. OK contest, not very exhilarating. 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 pressure).
 
 - Never report rating in these logs
 - Implement all dsa from scratch (modular arithmetic, data structures, etc.)
 
-- A: somehow got a wrong answer. unbelievable, brute forced it. math is poor. why reason/be ensure when you can brute force?
+- A: somehow got a wrong answer. unbelievable, brute forced it. math is poor. why reason/ensure when you can brute force?
 - B: didn't outline a simple strategy and got cooked. For example, I didn't check that the grid was a square after redoing my implementation for the third time.
 - C: trivial
 - D: tried a dsu approach before realizing the graph is not direction. DP + DFS + DSU weakness all combined to confuse me. In retrospect, just think about solving the problem in one way. Model it as a graph, do tortoise and hare, or do DP. **One approach at a time**. I tangibly need to improve my reasoning on harder problems when there are many moving parts. However, I'm unsure of how to move forward here because I'm fighting an uphill battle against a) my basic understanding of algorithms and b) my actual reasoning ability. I need to improve both the basics and my ability to think when facing _new_ problems/frameworks—that's the sign of a good problem-solver.
-- E: realized the greedy approach + pref/post-fix greedy on deletion but implementation absolutely annahilated me here. Further, **my exchange argument/greedy proofs are nightmarishly bad** and I resulted in just "trusting" the two-max greedy approach. This also harms my ability/intuition for dp/not doing dp. Work on this.
+- E: realized the greedy approach + pref/post-fix greedy on deletion but implementation absolutely annihilated me here. Further, **my exchange argument/greedy proofs are nightmarishly bad** and I resulted in just "trusting" the two-max greedy approach. This also harms my ability/intuition for dp/not doing dp. Work on this.
 - F: easy, counting pairs and modular arithmetic. However, I had to copy the modular arithmetic online. My grasp of this is still not good enough because I haven't practiced enough number theory.
 
-## [937 (div. 4)](https://codeforces.com/contest/2094) 16/04/16/2025
+## [937 (div. 4)](https://codeforces.com/contest/2094) 16/04/2025
 
 ~1300 performance. Consistently finishing E, getting F occasionally.
 
@@ -67,9 +67,9 @@ From now on, prioritize actually _learning_ and problem-solving in a pressurized
 
 - C: submitted without rigorously checking all edge cases.
 - D: misunderstood the problem statement twice. Polya and Zeitz both advise to fully understand exactly what the problem statement is asking, whether through direct analysis or examples. Then, I messed up the brute force. However, I did notice that raw recursion would not TLE based on the fact that each number can be divided in only a few ways.
-- E: I knew a number didn't have that many divisors but the implementation took me too long. **Pay closer attention to the constraints and just solve the problem.**. Spend a bit more time on implementation, _even if you know a way that works_. Here, I knew an approach to code but it was easily error-prone. Immediately came up with the idea but was unable to express it in code. This means I did not fully understand the problem, namely with some core mistakes:1. The tree it not necessarily binary
+- E: I knew a number didn't have that many divisors but the implementation took me too long. **Pay closer attention to the constraints and just solve the problem.**. Spend a bit more time on implementation, _even if you know a way that works_. Here, I knew an approach to code but it was easily error-prone. Immediately came up with the idea but was unable to express it in code. This means I did not fully understand the problem, namely with some core mistakes:1. The tree is not necessarily binary
 - C's cannot have children, so tracking depth/available nodes to fill per level is crucial
-  Coming up with the expression $a=c+1$ (and ensuring the input conforms to that) is a lot easier than cusotm coding logic to ensure levels are filled out properly. The core problem is that I lack the mathematical prowess to be certain of what exactly I need to check after I make that assertion and why. In this case, it means that the number of C's is appropriate, _so I never even need to check them_—I just need to make sure that the rest of the solution is valid.
+  Coming up with the expression $a=c+1$ (and ensuring the input conforms to that) is a lot easier than custom coding logic to ensure levels are filled out properly. The core problem is that I lack the mathematical prowess to be certain of what exactly I need to check after I make that assertion and why. In this case, it means that the number of C's is appropriate, _so I never even need to check them_—I just need to make sure that the rest of the solution is valid.
 
 ## [1017 (div. 4)](https://codeforces.com/contest/2094) 14/04/2025
 

src/content/posts/algorithms/extrema-circular-buffer.mdx

@@ -140,7 +140,7 @@ Thinking a bit deeper about the problem constraints, it is clear that:
 
 - If an extrema is pushed onto the data structure, all previously pushed elements are irrelevant to any further operations.
 
-Elements are processed in FIFO order, enabling this observation to be exploited. This is the foundationl idea of the [monotone priority queue](https://www.wikiwand.com/en/Monotone_priority_queue) data structure. So, for maintaining a minimum/maximum, the data structure will store a monotonically increasing/decreasing double-ended queue.
+Elements are processed in FIFO order, enabling this observation to be exploited. This is the foundational idea of the [monotone priority queue](https://www.wikiwand.com/en/Monotone_priority_queue) data structure. So, for maintaining a minimum/maximum, the data structure will store a monotonically increasing/decreasing double-ended queue.
 
 This solution does not satisfy a circular buffer inherently. If an arbitrary number of elements are removed from the data structure when an extrema is added, it is certainly not possible to maintain a window of fixed size.
 
@@ -219,6 +219,6 @@ private:
 
 The final implementation utilized in the TRB includes the following features:
 
-1.  A ringbuffer a statically-allocated `std::array`, as any fix-sized queue can be supplanted with one
+1.  A ringbuffer using a statically-allocated `std::array`, as any fix-sized queue can be supplanted with one
 2.  A templatized value type and comparator for flexibility
 3.  C++ specific optimizations (rule of 5, smart pointers, and an STL-compliant API)

src/content/posts/algorithms/leetcode-daily.mdx

@@ -164,7 +164,7 @@ Great. Now we need to find the item with the largest beauty. Naïvely considerin
 
 Consider alternative approaches to responding to our queries. It is clear that answering them in-order yields no benefit (i.e. we have to consider each item all over again, per query)—could we answer them in another order to save computations?
 
-Visualizing our items from left-to-right, we's interested in both increasing beauty and prices. If we can scan our items left to right, we can certainly “accumulate” a running maximal beauty. We can leverage sorting once again to answer our queries left-to-right, then re-order them appropriately before returning a final answer. Sorting both `queries` and `items` with a linear scan will take $O(nlg(n))$ time, meeting the constraints.
+Visualizing our items from left-to-right, we're interested in both increasing beauty and prices. If we can scan our items left to right, we can certainly “accumulate” a running maximal beauty. We can leverage sorting once again to answer our queries from left to right, then re-order them appropriately before returning a final answer. Sorting both `queries` and `items` with a linear scan will take $O(nlg(n))$ time, meeting the constraints.
 
 ## carrying out the plan
 
@@ -224,11 +224,11 @@ Another convoluted, uninspired bitwise-oriented daily.
 
 Anways, we're looking for a subarray that satisfies a condition. Considering all subarrays with `len(nums)`$\leq2\times10^5$ is impractical according to the common rule of $\approx10^8$ computations per second on modern CPUs.
 
-Say we's building some array `xs`. Adding another element `x` to this sequence can only increase or element-wise bitwise OR. Of course, it makes sense to do this. However, consider `xs` after—it is certainly possible that including `x` finally got us to at least `k`. However, not all of the elements in the array are useful now; we should remove some.
+Say we're building some array `xs`. Adding another element `x` to this sequence can only increase or element-wise bitwise OR. Of course, it makes sense to do this. However, consider `xs` after—it is certainly possible that including `x` finally got us to at least `k`. However, not all of the elements in the array are useful now; we should remove some.
 
 Which do we remove? Certainly not any from the middle—we'd no longer be considering a subarray. We can only remove from the beginning.
 
-Now, how many times do we remove? While the element-wise bitwise OR of `xs` is $\geq k$, we can naïvely remove from the start of `xs` to find the smallest subarray.Lastly, what' the state of `xs` after these removals? Now, we (may) have an answer and the element-wise bitwise OR of `xs` is guaranteed to be $\lt k$. Inductively, expand the array to search for a better answer.
+Now, how many times do we remove? While the element-wise bitwise OR of `xs` is $\geq k$, we can naïvely remove from the start of `xs` to find the smallest subarray.Lastly, what's the state of `xs` after these removals? Now, we (may) have an answer and the element-wise bitwise OR of `xs` is guaranteed to be $\lt k$. Inductively, expand the array to search for a better answer.
 
 This approach is generally called a variable-sized “sliding window”. Every element of `nums` is only added (considered in the element-wise bitwise OR) or removed (discard) one time, yielding an asymptotically linear time complexity. In other words, this is a realistic approach for our constraints.
 

src/content/posts/algorithms/models-of-production.mdx

@@ -12,7 +12,7 @@ This post offers a basic introduction to the Solow, Romer, and Romer-Solow econo
 
 ### introduction
 
-The Solow Model is an economic model of production that incorporates the incorporates the idea of capital accumulation. Based on the [Cobb-Douglas production function](https://en.wikipedia.org/wiki/Cobb%E2%80%93Douglas_production_function), the Solow Model describes production as follows:
+The Solow Model is an economic model of production that incorporates the idea of capital accumulation. Based on the [Cobb-Douglas production function](https://en.wikipedia.org/wiki/Cobb%E2%80%93Douglas_production_function), the Solow Model describes production as follows:
 
 $$Y_t=F(K_t,L_t)=\bar{A}K_t^\alpha L_t^{1-\alpha}$$
 
@@ -163,7 +163,7 @@ The Model divides the world into two parts:
 
 - <u>Objects</u>: finite resources, like capital and labor in the Solow Model
 - <u>Ideas</u>: infinite,
-  [non-rivalrous](https://en.wikipedia.org/wiki/Rivalry_$economics$) items
+  [non-rivalrous](https://en.wikipedia.org/wiki/Rivalry_(economics)) items
   leveraged in production (note that ideas may be [excludable](blank), though)
 
 The Romer Models' production function can be modelled as:

src/content/posts/autonomous-racing/multithreading-a-gui.mdx

@@ -98,7 +98,7 @@ std::thread ros_thread([this]() {
 });
 ```
 
-Data flows from a called subscription → queued signal → signal connected to a slot → slot runs the GUI]widget when scheduled.
+Data flows from a called subscription → queued signal → signal connected to a slot → slot runs the GUI widget when scheduled.
 
 ```cpp
 // 1. Subscribe to a topic

src/content/posts/meditations/suck-less-or-suck-more.mdx

@@ -9,7 +9,7 @@ Simplicity is always better and I love being able to understand why things are h
 
 Except when it doesn't work.
 
-After years of use, I've found that suckless software is not built to be compatible with other less-sucking software. It is not compatible with running 40 ROS nodes at a time, nor 3 chrome instances with a plethora of tabs and jobs open. I've had my st terminal go blank and my dwm crash on me consistently.
+After years of use, I've found that suckless software is not built to be compatible with other less-sucking software. It is not compatible with running 40 ROS nodes at a time, nor 3 Chrome instances with a plethora of tabs and jobs open. I've had my st terminal go blank and my dwm crash on me consistently.
 
 Maybe this is the point. But I can't avoid [foxglove](https://wiki.ros.org/FoxgloveStudio), I can't avoid bloat to work for school and research-related projects. Most importantly, after spending half of my day patching st and having it crash on me, I don't feel like fixing it any longer. **Sadly, suck-ful software is here to stay and I don't have time to fight it right now.**
 

src/content/posts/software/designing-this-website.mdx

@@ -5,13 +5,13 @@ date: "18/06/2024"
 
 # Update: Port to Astro (<span class="date">22/05/2025</span>)
 
-I'm expanding my website to included more detailed algorithms, implementations, write-ups, and low-level optimization case studies.
+I'm expanding my website to include more detailed algorithms, implementations, write-ups, and low-level optimization case studies.
 
 I thought about writing these posts in the raw HTML as I've been doing and physically cringed.
 
 Then I recalled the below post I made around one year ago and realized the following:
 
-- Sure, you can be efficient with raw HTML/CSS/JS. However, _no matter what you do_ snippets, hotkeys, etc, nothing is fast than writing markdown.
+- Sure, you can be efficient with raw HTML/CSS/JS. However, _no matter what you do_ snippets, hotkeys, etc, nothing is faster than writing markdown.
 - Overhead (i.e. the massive overhead of copying over content, writing the html) matters
 - I'll be needing more advanced features that, while possible to do in vanilla web, would just be painful to maintain.
 - Sure, frameworks come with bloat. At this point, I'd added web components and script finagling&mdash;I was on the path to reinventing React myself.