asb's corner

Understanding Whole Program Paths and Path Profiling

2026-02-18T00:00:00+00:00

As a part of Georgia Tech’s Compiler Design course, the last sliver of HW1 was to implement part of the trace and compression algorithm from James Larus’ “Whole Program Paths”</a> paper. I wanted to take some time today to go through the paper’s ideas, my implementation, and some realizations/jumps I had to make along the way, partly because it’s interesting and partly because I had fun thinking about some of the problems and techniques introduced to me in this paper. Before this, I had never really conceptualized what actual profiling infrastructure would look like, and in ~2.5 weeks, I’d only gone and written code to do it myself! I will say, this post will probably not deal with the LLVM-isms as much as my thought process and algorithm design, save a few details.

What is path profiling?</h2>
Before we begin learning how to path profile, we must begin by understanding what it is. I’m trying and failing not to sound like a wise old sensei.
Anyway.
From one of Larus’ other papers, “Efficient Path Profiling”</a>, we get the following succinct definition:

A path profile determines how many times each acyclic path in a routine executes </blockquote>
Simple enough, and the abstract of the EPP paper goes on to say that this is better than basic block or edge profiling because those are “mere approximations of path frequencies” (sarcasm added). It makes sense - one surely has a better understanding of the dynamic behavior of a program if they have a full trace of the program at their fingertips, rather than frequency data on a per-{block, edge} basis.
ho(W) do we (P)rofile (P)aths, then? (WPP)</h2>
The idea of Whole Program Paths begins with the humble acyclic path itself. The procedure itself works in two phases (from §1.1):

Produce a trace of acyclic paths executed by a program (at runtime)</li>
Convert the trace into a more compact and usable form by finding its inherent regularity (i.e. repeated code).</li> </ol>
The result of this procedure is a lossless, compressed DAG representation of the original CFG (control flow graph), that also lends itself nicely to analysis. All in all, this is a really fantastic deal, and even at the outset is a very cool idea that piqued my interest.
Part 1, the acyclic path trace generation, is largely handled by the EPP paper, with some crucial hurdles to overcome that we’ll discuss soon. Part 2 relies on the SEQUITUR compression algorithm</a>, which is a similarly fascinating algorithm that I didn’t have time to implement from scratch. The high level idea of this algorithm is to take the whole program path trace and convert it into a Context Free Grammar (the other CFG), from whence we can create our DAG.
While actually doing this project, our concrete goal was just to return the final compression ratio $$\frac{\text{old # of symbols in original trace}}{\text{new # of symbols in context free grammar}}$$ and so we didn’t actually need to implement the DAG-ification procedure, instead using the SEQUITUR website’s implementation largely wholesale to get our final results. This, of course, means that Part 1 of our problem is really all we have to focus on, so let’s get crackin’.
Efficient Path Profiling (suboptimal is bad)</h3>
In §2 of the WPP paper, “Producing an Acyclic Path Trace”, we learn how to produce an acyclic path trace. Except, we really don’t, because they say “hey just instrument the code like the EPP paper, with some slight modifications”, while making no attempt to delineate what modifcations those are.
Ironically my first thought was not realizing that they had never actually specified the procedure for generating the path traces in the paper (or its inevitable modifications), but also that they hadn’t defined instrumenting. To instrument a program is to insert code at certain points at compile time in a pass (such as an LLVM Analysis), such that at runtime the code runs correctly and also stores the trace data in a buffer of sorts, either in memory, by printing it out, or in some secret other way.
All that being said, lettuce now dive into the EPP paper, where our joys begin.

The Efficient Path Profiling paper works in a few key stages, and works on a function’s CFG:

Convert your function’s CFG into a DAG</li>
Assign each acyclic path in the function to a unique natural number via path sums</li>
Use a Max-Weight Spanning Tree to identify chords in the graph, then compute chord increments to maintain path sums when only chords are incremented</li>
Do the actual code instrumentation!</li> </ol>
We leave step 4 for later and focus on the first three steps, explicitly as written in the EPP paper.
(1) $\text{CFG} \rightarrow \text{DAG} = \text{joy}$</h4>
Blissfully unawares of any looming complications, we dive headfirst into the CFG to DAG conversion. The paper is largely clear about this, and for that we all say “thank you”.

For each vertex v that is the target of one or more backedges, add a dummy edge $ENTRY \rightarrow v$. For each vertex $w$ that is the source of one (or more) backedges, add a dummy edge $w \rightarrow EXIT$. If one of these edges is not in the spanning tree, it will be instrumented, which is efficient as the edge’s increment can be combined with the code always added to a loop backedge to record a path. </blockquote>
So yeah, split the backedge $(u, v)$ into $ENTRY \to v$ and $u \to EXIT$, which un-loops our CFG and makes it a DAG. Problem solved!
If this is all we were doing, we could use a `FunctionAnalysisManager</code> to get a DominatorTree</code> from LLVM’s DominatorTreeAnalysis</code>. From here, finding a backedge is as simple as checking if $B$ dominates $A$ for edge $(A, B)$. HOWEVER. Because of unforseen circumstances (foreshadowing</del>), we instead can also do this with a simple DFS traversal, to see if we encounter a block we’ve already seen on our path at a certain point.`
`Also add a backedge $ENTRY \to EXIT$, which is useful for step 3. Yeah, we’ll see this later. </blockquote>`(2) Mapping paths to UIDs via path sums</h4> This is one of the cooler parts of the paper, and I may take a stab at formally verifying it with Lean soon. The core idea is that given some $NumPaths(r)$ paths in a given DAG rooted at $r$, each unique acyclic path is given a path identifier in $[0, NumPaths(r) - 1]$, and all we have to do is assign each edge to an inicrement value such that, at $EXIT$, we get the correct results! When I first saw this and walked through the algorithm, I was pretty excited, because it’s such an elegant idea. Here’s an example we can walk through from the paper, Fig 6 from EPP. This is currently in its “final state”, with the path increments applied to each edge - check for yourself that there are indeed 6 paths with numberings in $[0, 5]$. The algorithm, given in Fig 5, is as follows: foreach vertex v in reverse topological order { if v is a leaf vertex { NumPaths(v) = 1; } else { NumPaths(v) = 0; for each edge e = v->w { Val(e) = NumPaths(v); NumPaths(v) = NumPaths(v) + NumPaths(w); } } } </code></pre> If we first convert the given CFG to a DAG, then find the reverse topological order (perhaps using Kahn’s Algorithm, see my Advent of Code blog</a> for an example), we get the node list F, E, D, C, B, A</code>. Running the algorithm, we do the following: For F</code>, since it is a leaf, let $NumPaths(F) = 1$.</li> E</code> is not a leaf, so let $Numpaths(E) = 0$ to start; there is only one edge ($E \to F$), thus $Numpaths(E) = 1$ and $Val(E \to F) = 0$.</li> D</code> is the first interesting case, with two edges coming out of it. We initialize $NumPaths(D) = 0$ as usual, then notice that depending on which order we iterate over the edges ${D \to E, ~D \to F}$, the edges can have different valuations. To stay consistent with the figure, we first handle $D \to F$, setting $Val(D \to F) = 0$, then updating $NumPaths$ and setting $Val(D \to E) = 1$. After this, $NumPaths(D) = 2$ as desired, and we’re done.</li> </ol> It may be helpful to manually follow through with the last three basic blocks, but the above should be sufficient to understand the path sum algorithm. (3) Reducing instrumentation via Spanning Trees and Chords</h4> After we have our DAG with paths weighted according to the increment along them (such that each acyclic path has a unique path sum) (repetition!), we come to the perhaps obvious realization that if we instrmented (read: added extra profiling code) to each edge in the DAG, we would bloat the crap out of our program. This has been widely regarded as a bad move, so can we do better? Duh, you say, having read the title of this section, to which I respond that you, stand-in reader, are a figment of my imagination and this is unhelpful for pedagogical purposes. Onward we go. Our goal here is to go from “every edge is instrumented” to “only a few are instrumented”, and one way we can do that is with spanning trees. A spanning tree of a graph $G$ is a subgraph of $G$ that contains every vertex in $G$ and is a tree. It guarantees connectivity, acyclicity, and minimality (using the fewest # of edges to satisfy the previous two conditions, namely $n-1$ edges). All the edges that are in the DAG but not in the spanning tree are called chords. Chords have a very key property that, when you add any chord to the spanning tree, it creates a unique fundamental cycle; this is a property that we will exploit later to get chordal increment values. For now, we want to get a Max-Weight Spanning Tree (perhaps with a Modified Kruskal’s algorithm that biases for larger weights rather than the typical min-weight formulation), such that we have min-weight chord edges. We are creating this spanning tree on an undirected version of the DAG. This will be important in approximately one minute. From there, for any chord $c, ~Inc(c)$ is presented as the sum of the edges in the fundamental cycle in Fig 7 of the EPP paper (linked again</a> for convenience), but there is a little more nuance than that. In writing this, I have realized that my attempts at implementing this were wrong, and while my hack works, it is not as elegant as the actual solution so I’ll try to do it justice below. Let’s take the simple diamond graph $A \to B, ~A \to C, ~B \to D, ~C \to D$ with backedge $D \to A$. This backedge is akin to our algorithm’s $ENTRY \to EXIT$ backedge. Then, say our original path sum algorithm assigns weights of 0 to every edge except $A\to C$, for which the weight is 1. This is a perfectly valid edge valuation; the two acyclic paths are uniquely identified as 0 and 1. From here, let’s say our spanning tree is the following edges: ${A\to C, ~B\to D, ~C\to D}$. Then our chords are ${A \to B, ~D \to A}$. The algorithm for finding the increment of chord with spanning tree is as follows: Find the (undirected) fundamental cycle in the graph induced by the spanning tree and the chord</li> Sum the edges in the fundamental cycle, taking care to invert the sign when we are going against the direction of the flow.</li> Bob’s your uncle. Well, probably, for some of you. I have a few nice friends named Bob, no uncles though.</li> </ol> For our diamond-graph-with-backedge, let’s concretely check both cases: For $D\to A$, $Inc(D\to A) = Val(D\to A)+Val(A\to C)+Val(C\to D) = 0 + 1 + 0 = 1$</li> For $A\to B$, the cycle in the graph is actually $A \to B \to D \to C \to A$, where the $D \to C$ and $C \to A$ edges are backwards. Thus, $Inc(A\to B) = Val(A\to B)+Val(B\to D)-Val(D\to C)-Val(C \to A) = 0+0-0-1 = -1$.</li> </ul> We can treat the increment on the backedge as “always happening at $EXIT$”, i.e. there’s a constant +1 at the end before storing the path identifier into the trace. Thus, we have increments for each chord, and we can set the increments for all other paths to 0, i.e. we can leave them uninstrumented! Hooray! For additional reference, the paper cited in the EPP paper is “Efficiently Counting Program Events with Support for On-Line Queries”</a>. Some problems with naively using the EPP algorithm</h3> When using the LLVM framework, and working with an LLVM CFG, one needs to be careful to handle the overall control flow with care. As such, instead of directly converting the CFG into a DAG (which can ruin the control flow unless you use an IRBuilder</code> to change the branching logic directly), we just create our own DAGNode</code> and DAG</code> structs to build and modify our DAG. We then use that DAG for steps 2 and 3 of the EPP paper, before applying our instrumentation logic “from the DAG to the CFG”, as we’ll discuss later.</li> The EPP paper describes instrumentation for counting the frequency with which each path is encountered (with something like count[r]++</code>, where r</code> represents the path identifier. We need to modify this to instead create a trace buffer, aka a huge array of ints that stores the path identifiers as they arrive in sequence. Paired with this trace buffer will be a trace index that needs to be incremented correctly at the $EXIT$ node so we keep track accurately.</li> In order to convert the path traces generated by the EPP algorithm on a per function basis into one unified Whole Program Path, you need to somehow distinguish each function’s path identifiers. The way I chose to do this was by using a “base + offset” idea; the first function’s base is 0, and its offset is the path identifier itself. Then, the second function’s base is $0 + NumPaths(\text{first function})$, and the offset is the same idea. You can see where we’re going with this - in general, since every path identifier is in the range $[0, ~NumPaths(\text{entry of func}) - 1]$, each range is cordoned off correctly. If function A has 2 paths, its paths are ${0, ~1} $. Then, if function B has 3 paths, its paths will end up saved as ${2, ~3, ~4} $. The base will be the sum of all of the previous functions.</li> Finally, we have the main disconnect between the paper and implementation. In the WPP paper §2, they mention the following:</li> </ol> Whole program profiling requires a slight redefinition of a path, so edges leading into a basic block containing a procedure call terminate acyclic paths </blockquote> As it turns out, they never really quite say how they did this. Dang. Terminating acyclic paths at calls</h3> I spent a couple days of my free time drawing flowgraphs in contrived scenarios before a conversation with my TA initiated a eureka moment of sorts. At that point, I had been working on a very specific test case (Fig 2 in the WPP paper): int bar(int j) { if (j < 5) return j; else return 0; } int main(void) { for (int i = 0; i < 9; i++) { bar(i); } return 0; } </code></pre> which admits the above original CFG for main</code>, where block C</code> has the call. The CFG for bar</code> is simple, just a diamond graph to start. As such, we’ll focus on main</code>’s CFG for the call handling. Before we discuss how to do the call handling, let’s first discuss our output expectations. For main</code>’s CFG, we expect the following 3 paths to be output by the trace: $ENTRY\to A \to B\to C\to EXIT$ for the initial call to bar</code> (somehow)</li> $ENTRY\to B\to C\to EXIT$ for the loop</li> $ENTRY\to B\to E\to EXIT$ for when we break out of the loop</li> </ol> The first key realization was that we had to handle calls before handling backedges, as this made the resulting acyclic paths easier to handle while also removing some backedges from the equation during call handling. The second (and more important) realization was that if we wanted a call to terminate an acyclic path, we needed a way to go from a block ending in a call directly to the $EXIT$ node. From a block ending in a call… ah. The idea is simply to split blocks, such that you have an ordered list of blocks that corresponds to the original block, except each block either ends in a call or (in the case of the last one) may not have a call at all. In the above case, we can split block $C$ into the sequence $C_1;C_2$, where $C_1$ contains the call and $C_2$ contains the branching/bookkeeping, as well as the for loop’s increment. Then, we can apply this algorithm of mine. Given an ordered list of blocks $[C_{1}, C_{2}, \ldots , C_{n}]$, as well as $preds(C)$ and $succs(C)$: For all $i \in [0, n-2]$, add the edge $C_i \to EXIT$ and $ENTRY\to C_{i+1}$. This terminates the path at callsite $C_i$ while allowing the new path to be handled with “fresh” instrumentation from $ENTRY$ to the post-call code at $C_{i+1}$.</li> For $C_{n-1}$ (the last block), there are two cases: If last block also ends in a call, then add $C_{n-1} \to EXIT$ and $ENTRY \to S ~\forall S \in succs(C)$. This connects the last block to $EXIT$ (as it has a call, so the path needs to be terminated) and connects all of $C$’s original successors to $ENTRY$ so the instrumentation works correctly.</li> If the last block doesn’t have a call, then add $ENTRY\to C_{n-1}$ and $C_{n-1} \to S ~\forall S \in succs(C)$. The last block is now a clean successor of the previous block with call. Itdoesn’t need to go to an $EXIT$, so it flows from $ENTRY$. Then, as before, all of the successors of the original block $C$ are connected to it, and we are done!</li> </ol> </li> </ol> To the right, you can see what the final DAG looks like. The call handling takes care of the backedge that was present originally! Just as a quick sanity check, let’s also list out the paths we expect to see, and check if they line up with your hopes and dreams from before. $ENTRY\to A\to B\to C_{1}\to EXIT$ (the initial)</li> $ENTRY\to C_{2}\to B\to C_{1}\to EXIT$ (the loop)</li> $ENTRY\to C_{2}\to B\to E\to EXIT$ (the end condition)</li> </ol> It seems like we’ve done a good job, give yourself a POTB. It’s also important to remember that this complicates the backedge calculation in the DAG; now we can’t make use of the original CFG’s flow relationships, and need to traverse manually to find our pesky backedges. Instrumenting our CFG (injecting stuff to trace stuff)</h2> The last step in the arduous process of procuring but one trace of a silly little program is to write the code that actually, y’know, stores the trace. After figuring all the previous stuff out, this was way less fun, but here’s generally how the instrumentation procedure works: As a precursor to the actual instrumentation, create module level global variables for the trace buffer, trace index (a pointer into the buffer), and the path identifier.</li> $ENTRY$ Instrumentation: For each successor to the $ENTRY$ node, add a store to the PathId</code> global variable, (re)initializing it at 0.</li> Chord Instrumentation: For every chord edge $(u, v)$, add a basic block in between with llvm::SplitEdge</code> to get something like $(u, new), ~(new, v)$. In the $new$ block, load in the PathId</code> then add the chord’s increment to it.</li> $EXIT$ Instrumentation and overflow handling and printing at the end: For this, check if the trace index has reached the length you set your buffer. If not, store the PathId</code> in the trace buffer with a GEP</a>, then increment your trace index and (optionally) reset your PathId</code> after storing (although it will likely be done by $ENTRY$ handling anyway).</li> </ol> Heading to the $EXIT$</h2> And that’s pretty much it! We learned about the Whole Program Paths paper, Efficient Path Profiling, and some ideas necessary to jump from one to the other. I’m planning on trying to verify the path sum stuff, but beyond that I’m just glad I was exposed to this cool new idea and had the chance to think about it deeply. Thank you for reading!

Proving bounds for the Randomized MaxCut Approximation algorithm in Lean4 2025-12-19T00:00:00+00:00 For a given graph G = (V, E)</code>, a cut C</code> is a set of edges such that there is a partition V = (A, B)</code> where all edges e ∈ C</code> have one vertex in A</code> and the other in B</code>. MaxCut is a very famous combinatorial optimization problem wherein we want to find the largest such cut. This is useful in scheduling, partitioning, financial portfolio optimization, and more! While the problem itself is NP-Complete, there exist a host of approximation algorithms that allow us to do “pretty good” in practice. To see a careful treatment of deterministic MaxCut algorithms, check out these two</a> lecture</a> notes. Some quick nomenclature: an α-approximation for a (maximization/minimization) problem is when we: (max) Do as good as 1/α * OPT</li> (min) Do as good as α * OPT</li> </ol> For our purposes, lets say we don’t even care about doing good right now, just that we care about doing good in expectation. That is, while there exists a 1/2-approximation for MaxCut, we want to create an algorithm such that the expected size of our output cut satisfies the 1/2 approximation ratio. Our simple algorithm</h3> For every vertex v ∈ V = (A, B)</code>, choose with 50% probability whether it is in A</code> or B</code>. That’s it, that creates the cut. Good job! Take a well-deserved break now. Proving it informally</h3> Now that you’re back from break, let’s get to proving this with words! For any edge e = (u, v) ∈ E</code>, we have Pr[(u, v) ∈ C] = 1/2</code>. For each edge e</code>, create a random variable Xₑ</code> such that Xₑ = 1 if e ∈ C else 0</code>. Notice now that the size of the cut, |C| = ∑ Xₑ</code>. The overall proof is then E[|C|] = ∑ E[Xₑ] = ∑ Pr[e ∈ C] = |E|/2 ≥ |C*|/2</code>, for some optimal cut C*</code>. Just throw linearity of expectation and use our previous facts - this, plus the fact that the size of the largest possible cut is bounded by the number of edges (that is, |E| ≥ |C*|</code>), and we get the result we want. |E| = |C*|</code> only when the graph G</code> is bipartite; this follows basically by definition. Proving it with Lean</h2> Having encountered this simple and elegant algorithm + proof in my algorithms course, I wanted to see if I could formalize it in Lean. I’ve been getting more interested in formal verification, so this seemed like a fun challenge, especially w.r.t the randomization aspect of it! For the uninitiated, Lean is a programming language and proof assistant similar to Rocq. There has been a big movement in recent times to formalize mathematics and CS concepts within the Lean MathLib and CSLib, and I’m eager to see where it goes :) Structures</h3> The first step is always representing our key structures. Lean already has a SimpleGraph</code>, so all we need to do is design a structure to store our Cut</code>: -- Given some graph G = (V, E) -- a cut is defined as a set of edges C ⊆ E such that for each edge c = (u, v) ∈ C, -- we have that u ∈ V₁ and v ∈ V₂, for V₁ ⊕ V₂ (disjoint union) = V structure Cut (V : Type*) (G : SimpleGraph V) [DecidableEq V] [Fintype V] where A : Finset V B : Finset V -- below are proof obligations -- propositions are types, proofs are values of those types! partition : A ∪ B = Finset.univ disjoint : Disjoint A B </code></pre> We also create some helper functions, namely for: Creating cuts from an assignment, a mapping from vertices to booleans (true in A, false in B)</li> size</code> of the cut</li> Whether a given edge is in the cut at all.</li> </ol> -- determine whether an edge is in the cut def edgeInCut {V : Type*} [DecidableEq V] [Fintype V] {G : SimpleGraph V} (C : Cut V G) (e : Sym2 V) : Bool := e.lift ⟨fun u v => (u ∈ C.A ∧ v ∈ C.B) ∨ (u ∈ C.B ∧ v ∈ C.A), by simp [or_comm, and_comm]⟩ def size {V : Type*} [DecidableEq V] [Fintype V] {G : SimpleGraph V} [DecidableRel G.Adj] (C : Cut V G) : ℕ := (G.edgeFinset.filter (fun e => C.edgeInCut e)).card -- given some characteristic function, use char func to determine A, B def ofAssignment {V : Type*} [DecidableEq V] [Fintype V] {G : SimpleGraph V} (f : V -> Bool) : Cut V G where A := Finset.univ.filter (fun e => f e) B := Finset.univ.filter (fun v => !f v) partition := by grind disjoint := by simp only [Finset.disjoint_iff_inter_eq_empty, Bool.not_eq_eq_eq_not, Bool.not_true] ext v simp </code></pre> Some notable things: The backbone of our Cut</code> is the Finset</code>, which is a type representing a finite set of elements of some type α. Since graphs are finite structures, we get a lot of free convenient properties from leveraging Finset</code> here. We also use typeclass declarations for Fintype</code> and DecidableEq</code>. Fintype α</code> lets our function know that α is finite, and DecidableEq</code> knows that propositional equality is decidable for all elements of type α. Generally, we also use the idea of an assignment function quite a bit, i.e. some mapping from V -> Bool</code> that defines our cut. From here on out, I’ll skimp on some of the proof details and go over more of the overarching approaches for some of my lemmas, since that seems like a more economical use of time and article space. First, we finalize our randomized cut instances and the edge containment indicator function, which basically represents our random variable Χₑ</code> from the proof. def randomizedMaxCut {V : Type*} [DecidableEq V] [Fintype V] {G : SimpleGraph V} : (V → Bool) → Cut V G := fun assignment => Cut.ofAssignment (G := G) assignment -- use edgeInCut to create a characteristic function returning in {0, 1} def edgeIndicator {V : Type*} [DecidableEq V] [Fintype V] {G : SimpleGraph V} (C : Cut V G) (e : Sym2 V) : ℕ := if Cut.edgeInCut C e then 1 else 0 </code></pre> Proofs</h3> Finally, in the order I proved them, here are the lemmas and theorems! cut_size_eq_sum_indicators</code>: |C| = ∑ χₑ ∀ e ∈ E</code></li> </ol> lemma cut_size_eq_sum_indicators {V : Type*} [DecidableEq V] [Fintype V] (G : SimpleGraph V) [DecidableRel G.Adj] (assignment : V -> Bool) : (Cut.ofAssignment (G := G) assignment).size = ∑ e ∈ G.edgeFinset, edgeIndicator (Cut.ofAssignment (G := G) assignment) e := by ... </code></pre> Here, we first unfold our relevant definitions. Then, we convert to using summation for both sides, and finally we simplify and show that our sets are equal; if the sets are equal, their cardinalities must be equal as well! count_diff_assignments</code>: half of the 2^N possible assignments have f u ≠ f v</code></li> </ol> lemma count_diff_assignments {V : Type*} [Fintype V] [DecidableEq V] (u v : V) (huv : u ≠ v) : 2 * (Finset.univ.filter (fun f : V -> Bool => f u ≠ f v)).card = Fintype.card (V -> Bool) := by ... </code></pre> This proof is a behemoth of sorts, unexpectedly. The key thread here is to codify the fact that f u ≠ f v</code> is half the space by creating a bijection and showing it is an involution (its own inverse). Then, if we know that the sets f u ≠ f v</code> and f u = f v</code> have the same cardinality, and that they equal 2^|V|</code>, we get our result. prob_edge_in_cut</code>: Pr[e ∈ C] = 1/2</code></li> </ol> lemma prob_edge_in_cut {V : Type*} [DecidableEq V] [Fintype V] (G : SimpleGraph V) (e : Sym2 V) (h : ¬e.IsDiag) : (∑ assignment : V -> Bool, (edgeIndicator (G := G) (randomizedMaxCut assignment) e : ℝ)) / (Fintype.card (V -> Bool)) = 1/2 := by ... </code></pre> For this proof we use induction on the edges to extract the vertices, then claim that the sum of the indicators when u ≠ v</code> is equal to the cardinality of the Finset</code> when f u ≠ f v</code> (the count of “good” assignments, when not in same vertex set of partition). This, plus our result from the count_diff_assignments</code> (counting lemma) plus some tiny polishing steps gives us our result. expected_cut_size</code>: E[|C|] = |E|/2</code> (the important one!)</li> </ol> theorem expected_cut_size {V : Type*} [DecidableEq V] [Fintype V] (G : SimpleGraph V) [DecidableRel G.Adj] : (∑ assignment : V -> Bool, ((randomizedMaxCut (G := G) assignment).size : ℝ)) / (Fintype.card (V -> Bool)) = (G.edgeFinset.card : ℝ) / 2 := by ... </code></pre> This proof begins with our original expectation statement and chains together our previous proofs to give us our major result. First, we leverage cut_size_eq_sum_indicators</code> to get our size in terms of the indicators. Next, we simulate our linearity of expectation via Finset.sum_comm</code> and Finset.sum_div</code> to move things around. Finally, we use the calc</code> tactic to sequentially show equivalences with the prob_edge_in_cut</code> lemma and summation results to give us our answer! A brief interlude: finding the Max Cut</h4> In order to wrap this up and prove things with respect to the actual maximum cut, we need to find a way to represent this. Today I learned about the Finset.univ.sup</code>, meaning “supremum”. A supremum is the smallest quantity greater than or equal to each element of a given (sub)set. In effect, we iterate over all Finset</code>s, create Cut</code>s based off of each possible assignment, and pick the best/max one! def maxCutValue {V : Type*} [DecidableEq V] [Fintype V] (G : SimpleGraph V) [DecidableRel G.Adj] : ℕ := Finset.univ.sup (fun f : V -> Bool => (Cut.ofAssignment (G := G) f).size) </code></pre> Back to the proofs. maxCut_le_edges</code>: Maximum cut is at most |E|</code>. This proof is short enough to include in its entirety:</li> </ol> lemma maxCut_le_edges {V : Type*} [Fintype V] [DecidableEq V] (G : SimpleGraph V) [DecidableRel G.Adj] : maxCutValue G ≤ G.edgeFinset.card := by -- notice that finset S's max size is |E| -- a Cut can contain at most |E| edges anyway unfold maxCutValue -- sup cut sizes <= num edges apply Finset.sup_le intro S _ -- unfold to get finset and card unfold Cut.ofAssignment Cut.size -- filtered subset of edges, so cardinality must be less exact Finset.card_filter_le _ _ </code></pre> rand_approx_guarantee</code>: E[|C|] >= |maxCut|/2</code>. This proof is also short, because it stands tall on the backs of giants (the others).</li> </ol> theorem rand_approx_guarantee {V : Type*} [DecidableEq V] [Fintype V] (G : SimpleGraph V) [DecidableRel G.Adj] : (∑ assignment : V -> Bool, ((randomizedMaxCut (G := G) assignment).size : ℝ)) / (Fintype.card (V -> Bool)) >= (maxCutValue G : ℝ) / 2 := by rw [expected_cut_size] field_simp norm_cast exact maxCut_le_edges (G := G) </code></pre> We basically just use the expected_cut_size</code> and then simplify the division by two on either side, then use our inequality. Note that the expression (∑ assignment : V -> Bool, ((randomizedMaxCut (G := G) assignment).size : ℝ)) / (Fintype.card (V -> Bool))</code> accurately represents E[|C|]</code>, because it is the cut size divided by the total number of possible assignments. Learnings</h3> Lean is hard. Also, I have to learn to better speak the language; it was pretty challenging to learn how some tactics worked even with the reference (quite mathematically heavy, as is to be expected) and AI tools (more hand-wavy, imprecise at times), but this was a great learning experience and I’m happy I took the time to prove this! My original goal was to try proving something similar about randomized Quicksort, but that felt like too hard a challenge for a Lean novice. The rest of my code (i.e. the full proofs and my silly comments) can be found at this Github repo: verif-randomized-maxcut</a>. Thank you for reading! talking 2025-08-06T00:00:00+00:00 Art is a conversation. It is weird to say without some faux-profundity that I think the goal of art is twofold; for an artist to express their emotions, ideas, reactions to something, and to create an opportunity for dialogue. It seems to me that the most successful artists, or at least the ones we know or perceive the strongest/most/best, tend to be successful at creating opportunities to discuss art. At the end of Sarah Thornton’s Seven Days in the Art World, she says, “After looking at art, you ask yourself: Is this intriguing? Deeply amusing? Do I want to spend time with it? Does it become more compelling the more I think about it?” In mulling those words over, I don’t think I’ve felt very strongly about art before, and that is an interesting thing to verbalize because it feels so antithetical to how fascinating I believe it is. I went to the MoMA with my girlfriend recently, and I finally got to see van Gogh’s Starry Nights, as well as Monet’s Water Lilies. They were beautiful, and as an untrained non-artist myself, I can only imagine the sheer depth of technique that made their paintings amazing, both pedagogically and emotionally. And yet, while I enjoyed the aesthetics of these works, I don’t think I managed to feel strongly enough about them. Perhaps I am not conversing with art, not asking the right questions, approaching the canvas as an investigative reporter would, and not as a traveler on the subway asking about your day. Part of me wants to examine an artist’s technique, understand the how, the color theory, the pressure, the composition, the scale. The other, seemingly smaller part of me maybe wants to ask what I’d do if I was there, or ask why I liked it. Perhaps if I was alone in the room, I could think about the water lilies again, think about the sounds there – water lapping at the lilies’ lips, a light breeze rippling across the pearly water and foiling around my ears, the soft ‘plip’ of a fish or frog breaking the surface – and the touch, and the taste of the air, and the water moving and the sun shining, reflecting, refracting, gently through the surface. That sounds nice. I could have been there, then. The silence of an empty room with a swathe of canvas would have given way to a new world, or rather a lens into an old one. Perhaps I will go again. – When I talk with slightly more modern art, I think the conversation is harder for me, and perhaps for everyone, as it presumes context, which is a fickle thing. Each piece reflects its creator, and as such we first turn to them. As I write this I think about a shirt I have with an abstract, geometric, apparently constructivist piece called Composition of Circles and Overlapping Angles by Sophie Taeuber-Arp, a Swiss Dadaist. Sophie Taeuber-Arp, Composition of Circles and Overlapping Angles, 1930. The Museum of Modern Art, New York. The Riklis Collection of McCrory Corporation/The Museum of Modern Art, Department of Imaging and Visual Resources/©2019 Artists Rights Society (ARS), New York/VG Bild-Kunst, Bonn “I enjoy the contrast between the muted blue-grey background and the rest of the colors; in particular, the juxtaposition of the white with the deep orange-red (#FF2F08) and prussian blue (#023E99).” “I’m drawn to the sandpaper-like texture in the top left, especially how it juts out in the intersections of various other colors” “The three dots on the left, and three dots on the bottom, have interesting notions of symmetry” “Why did you paint this? What did it make you feel when painting, and what did you feel while painting it?” “What sort of techniques did you use to get even geometric shapes, and the sandpaper-esque texture of the brown-gold sections?” “What do you think is the purpose of art? Is it to enjoy for beauty’s sake, is there any value in that? Should all art be beholden to some orthogonal perspective behind a veil, especially one that acts more as a steep step for many?” “What is Dadaism? Did you know you were one of the pioneers of the movement, and foundational in the field of concrete art and geometric abstraction?” “What made you choose the title you chose for this piece?” “Why?” – The “intrinsic decorative urge should not be eradicated,” she wrote, “It is one of humankind’s deep-rooted, primordial urges.”1</a> – Thank you, Ms. Tauber-Arp; I’m glad to have spoken to you. I carry you with me when I walk around, pretending to be sophisticated, trying my hardest to prove my love for things I don’t understand. Perhaps I will go again, and then I’ll get it. After all, it did look cool. ^1ARTNews on Sophie Taeuber-Arp</a> </div> Are photos even real? 2025-05-13T00:00:00+00:00 Word Count: 1427 I’ve been wondering about this for a fair few months now, ever since I heard it mentioned in a Vergecast episode, or perhaps a video before that on computational photography, or perhaps even before that, when I was writing that joyous exposé into my thoughts on memory. Because that’s what it is for, isn’t it? We take photos largely to remember. Of course, there are those that take photos for art, to edit and beautify to evoke a nice mixture of emotions like Remy’s visualization of taste from Ratatouille, but even that style of photography bears its roots in the idea of remembrance, of giving someone a long-lasting feeling of a place they saw, or never saw but felt like they did because of you and your photo. granularity.</h2> A photograph (colloquially referred to by everyone as a photo) has a few definitions, depending on the granularity; here is where the journey of the impostor photo begins. I’ll begin by stating some examples from reputable dictionaries, and will try to order them by pedantry or some other silly metric. Also, I feel it prudent to mention that this all sounds like the beginning of a cheesy wedding vow (“Merriam-Webster’s dictionary says that ‘love’ is defined as…”), but I hope that you, dear reader, will kindly ignore that point. Anywho. some definitions.</h2> Cambridge Dictionary defines a photograph as a picture produced by a camera, and says that a camera is a device for taking photographs. Brilliant. The Collins dictionary shares this exact definition. Merriam-Webster defines a photograph as a picture or likeness obtained by photography, which is immediately unhelpful because now we have to chase through several more definitions. We’ll skip picture, and likeness is relatively similar in nature, so the main one is photography, which they cite as being “the art or process of producing images by the action of radiant energy and especially light on a sensitive surface (such as film or an optical sensor)”. This! This is the good stuff, getting to the heart of the matter! The Oxford English Dictionary does the most precise job, in my opinion, referring to a photograph as “A picture or image obtained by photography; (originally) a picture made using a camera in which an image is focused on to sensitive material and then made visible and permanent by chemical treatment; (later also) a picture made by focusing an image and then storing it digitally.” As an aside, it was insane that I had to use my Georgia Tech email to access a definition, otherwise I’d have had to use a subscription. Shocking, OED. history.</h2> Now that we’ve nicely sorted our definitions into the spectrum of insane to sane, we can begin discerning what we think a photo is, with a bit of history! The first known instance of development in this space is with the camera obscura, which leverages the property of light wherein it travels in a straight line to project an inverted image onto a wall after passing through a small hole. People later used mirrors to re-invert the image back to the correct orientation for viewing; it’s important to note that this is not technically a photo yet, as there was no way to “save” the state of this light image, it was simply a projection onto a surface. Next there were early photographs, which used the chemical properties of some materials (such as silver salts), notably that they reacted with sunlight. Scientists began devising methods to imprint images using the prior camera obscura work combined with this “storage” mechanism, creating the first rudimentary cameras and photographs! After this came a long series of developments in not only storage medium, but lens design, etc., all of which were chiefly analog in nature, at least by our standards today. Photographic film was the penultimate addition to the lineage of photographic development, and spurred by the modern age, took a life of its own. While the principle is the same, film is much more flexible as a medium and has much better precision in some ways, compared to the methods of yore. The ultimate development (finally, good riddance), is that of the digital camera, which takes the sensor data that was received and encodes it into data that is written onto a storage drive of some sort. Specialized semiconductor image sensors needed to be developed in order to do this, the two main types being Charge-Coupled Device (CCD) and active-pixel (CMOS) sensors, which translate the electromagnetic waves and their attenuation (variability through media) into signals (currents which encode information in circuitry). All that to say I have no real idea how they work, so please don’t ask. This is the type of technology being used in not just larger digital cameras, but also phone cameras. A sort of honorable mention, technological development wise, is the advent of computational photography, which we’ll surely get back to later. using our foundations.</h2> With all our expository rambling out of the way, we can begin examining some of our definitions and examples of photography. I think my qualms with photography are more modern than not, so let’s agree to safely call daguerreotypes, calotypes, and other pre 1900s photographs just that, photographs. I also see no reason why film cameras don’t count, as they still work on the same principles, using light based imaging onto a reactive surface to encode visual information at a specific time. Thusly, we have wandered into the den of the beasts, digital cameras and computational photography. Here, I think we get into the pedantry and semantics more than anything. By all good definitions, the journey of a photograph ends with the digital camera. One could probably better define a digital camera’s action as capturing and storing an image (by translating the light waves to data through specially designed sensors), rather than “capturing a photograph”, because no photograph is taken. So yeah, that’s one faux-photo down, on to the next. In contrast with digital cameras as a development, which still require precious sensing and direct translation to data that’s stored, computational photography introduces an intermediary processing pipeline into the mix, which takes sensor data and “improves” it according to algorithms and usually to some particular end. For example, Google’s Pixel phones have a mode called “Night Sight” which uses certain computational techniques to drastically improve picture visibility and quality in low-light photography settings (well, as much as one can call it photography, I guess). I regularly watch videos from the MKBHD channel, which does tech reviews and has, in the past, conducted blind smartphone camera tests, which are always quite telling. In referencing this interview, Samsung EVP Patrick Chomet says this in a very nice Verge article</a>: There was a very nice video by Marques Brownlee last year on the moon picture. Everyone was like, ‘Is it fake? Is it not fake?’ There was a debate around what constitutes a real picture. And actually, there is no such thing as a real picture. As soon as you have sensors to capture something, you reproduce [what you’re seeing], and it doesn’t mean anything. There is no real picture. You can try to define a real picture by saying, ‘I took that picture’, but if you used AI to optimize the zoom, the autofocus, the scene – is it real? Or is it all filters? There is no real picture, full stop. </blockquote> In addition to techniques to auto-balance exposure, saturation, ISO, aperture, etc., we also have techniques that automatically stitch images from multiple cameras for more information, for example. In many ways, what the one, two, or even three cameras on the back of our phone see is never what we see on the screen in front of us. Just like daguerreotypes and calotypes, which were two different types of early image storing mechanisms (i.e. photographs) when cameras were first being invented, nowadays different smartphones have their own camera styles, pros and cons, and features, almost entirely dependent on the computational photography techniques and algorithms used. It’s this insane level of preprocessing that makes me annoyed; more often than not, different phones taking comically different pictures frustrates me. Inane exposure makes photos more aesthetic at times, as do sharper photos on average, but this tends to over accentuate features of pictures, making them somehow less accurate than before. All photos aren’t real, let’s just revel in the memories and the smiles we capture. Maybe I should buy a nice SLR camera and revel in my cool, hip back to the future analog resurgence. That sounds rather fun, honestly. tuesday 2025-05-06T00:00:00+00:00 Today was interesting, an unassuming sort of day which walks past you on the trail, chirping up with a short “Hi” and a modest wave of the digits, ambling about at an average pace, not a care. He has places to be, to be sure, a being of righteous purpose and poise most days, but on this day his work is largely done, and he moves with the calm of the mid-afternoon lull that befits a job reasonably well done. This day carries notes of petrichor, of just enough of God’s own blood blessing us, as it is wont to do. The week has barely begun, and yet instead of a brusque and baleful bout of problems that tends to sink the ship, the bow of this week bursts brightly… with a light breeze and the sun peeking out gently from the clouds. This day wears well-worn jeans, of a slightly darker hue, but still well within the norm, and a nice clean black short-sleeves polo, wrinkles smarting the sides, perhaps a stain near the lower back. All in all, this is a fine day, certainly not Monday, or, God forbid, that horrid timeless moment at the end of Sunday where you realize you have work to contend with. No, today, like many before and many after, is a good, plain day. It keeps you company on the park bench, lets you take a brief moment of respite from the incessant houndings of the world, and then prods you awake when it’s time to return, waving its hand twice as goodbye as it saunters away, shoes thump thump thumping softly against the trail. Attention 2025-02-26T00:00:00+00:00 …is all you need, all you want, all you can eat, oh wait now there’s a discount, it’s cheap, and suddenly you’re transported into a world where you have it, a future image where you enjoy this thing, where its presence envelops you and comforts you and then the moment is lost and you’re back. back to where you were before, thumbs up and down on the screen, eyes glazed over, and you continue; those brief moments of respite are for the weak and decrepit, you don’t need a break, you need to FOCUS but the neurons in your brain disagree, complex chemical calculations crumbling your resolve and careening your consciousness to the Next Big Thing That Happened Just Now; es en todos los redes sociales grandes, you feel? someone died, someone’s alive, stocks up, rates down, hand up, in a roman salute they say, all these moments blending together in a dizzying crescendo they say, but what is really cacophonous and cantankerous and criminal and horrifying and all i want to do is BREATHE but it’s so hard, all these tendrils jutting out from screens, tearing my eyes away from my passions, my joys, my reasons to be alive, and honing in on the Next Big Thing – new show just dropped, seems like everything and everyone is recommending it, making me want to watch it, and then i’m forced to, locked into the ecosystem, the cycle, reminded of that one phineas and ferb episode where they’re locked up and re-educated, coerced into clearing their mind, no clamming up just clearing the mind and focusing on the Next Big Thing and then i blink and the video plays and i blink and the video keeps playing and i blink a little harder and my hand moves, largely of my own volition and the video stops. well. that’s nice. a good sound. SILENCE. Untitled 1 2025-02-05T00:00:00+00:00 Word Count: 194 It’s there, barely, but it’s there. A maple seed, drifting through the air, floating aimlessly as it swirls by my eyes. In that moment, I see what it could become; a tree with strong roots, quintessentially unique leaves, a beautiful rouge come fall. Brilliant, bountiful branches, each with their own special stories to tell, holding their own weight, an ecosystem of thought supported. And it floats by. There are more seeds. They, too, float by, going beside me, soaring above me, streaking past me. Some land in my hair as I look up, and a bright light shines. As I look down to focus, pencil scratching on paper (or keys clacking on keyboard), a lossy transfer occurs. And then the seed falls off my head, and I stop. I feel rooted, sometimes, arms out wide. I continually write my own story as I grow, and my arms support the weight of my dreams, but I only have two. Ten fingers, more granularity, a greater surface area. And the seeds float by. One day, I will take a step, creak my branches definitively across my body, and catch a seed. Maybe today is that day. Doing things because they are hard 2025-02-04T00:00:00+00:00 Word Count: 1000 In another instance of joyous self-therapizing, and because I am too busy to properly nerd out about a paper review or a fun, bite-sized project or topic, today I will be talking about doing things because they are hard. (I think I started the last foray into my psyche in medias res, but sometimes it’s fun to switch it up; maybe one day I’ll write creatively, and you’ll see my propensity for it..) Anyway, it all started in 2019, when I really started playing video games. (Anyway is correct, anyone who says “anyways“ should be taken out back for a stern talking to; colloquialisms are for the weak and imperiled, which you will be if you say “anyways”.) Technically, one could argue it really started when I began playing Phantom Forces on Roblox in middle school, but for sake of image, I’m going to ask you, dear reader, to ignore that particular fact. Here, we take a brief detour into a fun segment I call Why do people play video games?</h2> For some (including me, at times), it can feel like an escape from reality, a way to space out and enjoy mindless activity. You can rest other parts of your brain and relax, truly let go with the right game, whether that be clicking heads in the latest CoD, wandering an unfamiliar wilderness in Firewatch, or grinding through levels in Celeste. It gives you something to occupy the hands and the mind. Another great reason to play games is to stay connected with friends who are far away; multiplayer games are released by the hundreds each year, and provide a space to spend time doing the above mindless (or, in some cases, intense) activities with a cadre of capable cadets (that was fun alliteration)! But really, even though these reasons are true enough, I find myself enjoying games for one particular reason more than the rest; mechanical mastery. Sometimes this may translate into winning games, sometimes not, but the truth of it all is that getting a combo in, or mentally outplaying an opponent, or out-duelling someone, is the peak of fun. The natural addendum to this, then, is to prove to myself that by mastering the most mechanically challenging characters in a game, I’m sick as hell. In Overwatch, this meant learning Genji one-shot combos, ghost dashes, etc., blink pulse’s with Tracer, how to juggle properly with Winston, in addition to all the regular gamesense considerations that make the game even more fun. In THE FINALS, it meant learning how to master sword dash combos on the Light class. In Marvel Rivals, it means getting pummeled while I try to learn Spiderman and Black Panther. It’s brutal, but an exhilarating experience when it works! Aside: I think I use the rule of three too much. Note to self: revisit writing style. And thus ends the fun segment</h2> For whatever reason, learning hard things has been enjoyable in some ways. Another good example from my personal life has been learning Vim, which I started because I thought it would be tough and cool, and now has turned into a sort of immutable mainstay in my life, mostly because now my muscle memory tends towards my Vim binds and it is highly embarrassing when I “hjkl” in textboxes. I have additionally read “Your problem with Vim is that you don’t grok vi” several times, which if you haven’t, you seriously should. It’s a fantastic read about the depth and breadth of stuff that stock Vim supports, and it inspired me to try stock Vim for a while. But like, why? Do you have problems?</h2> Yes. Probably. Next question. Care to elaborate?</h2> No.</del> If you insist! There’s a sense of pride and accomplishment that comes with doing the hard thing; with going the distance to reach a height most people don’t get to. To separate yourself. A part of it likely stems from one’s self worth; I, for one, recognize that I measure my self worth frequently relative to those I deem similar to myself in demographic and intellectual capabilities. This is also where it goes wrong. Obviously. I once tried reading “War and Peace” just to say I’d read it – to be clear, probably a great book, but so incredibly dense and just not for me. It was something I’d deemed “hard”, something that I thought would make me seem cultured and cool, saying I’d read Tolstoy’s work. Phooey. (Is that how you spell that? I’m not sure how much I care about its phoneticization.) “Comparison is the thief of joy” is something that gets thrown around a lot. I’d argue that based on personal experience, it’s largely true, but not without its nuance. I find myself particularly motivated at times when I see others succeeding, as I’d imagine many others are. Toeing that line is probably the most challenging thing I do on a regular basis, because it forms the foundation for the rest of my day. But really, in its most pure form, I think I have just approached it wrong. If we strive to do things because they are hard, don’t do it for the destination, do it for the journey. The struggle of learning, the grit and sweat spent in the process, is what makes it worth your while. If you do the hard thing to say you did it, what did you gain except another item on a list, at least in your mind? The recontextualization is tough, but I think it is a valuable journey in and of itself. Hopefully. Where do we go from here?</h2> When I was doing things because they were hard for the achievement, I felt as though I’d lost the part of myself that enjoyed learning. It was performative. Assuming this ends up on my website, clearly that hasn’t changed too much, but I’m finally more cognizant of my approaches to self motivation, and I hope to continue learning new things not for others, but for myself. Take care, dear reader, and I’ll see you on Marvel Rivals playing Spiderman. My relationship with memory 2024-12-31T00:00:00+00:00 Word Count: 2607 Section 1: Impermanence</h3> A couple days ago, I was in Dallas with my family, visiting family friends for a series of birthdays and Christmas celebrations. At the end of this day, my cousin’s grandmother wanted to play the Saraswati veena</a> for us all, a stringed instrument typically used in Carnatic Indian classical music. She started playing when she was nine years old, and when she played for us three days ago, she was 77. For thirty minutes, I was reminded of my 6th grade trip to South India, eating with my hands off a banana leaf plate with my classmates, revelling in the humid heat of Kerala. Her eyes were closed, but her worn hands were true and for that half hour, I was mesmerised. And yet, three days later, I remember her face, her eyes, her hands, her posture, but precious little of the music itself. It’s interesting; the one thing that I cared about the most in that moment was what I remembered the least. Over the summer, I went to Jazz at Lincoln Center Orchestra in New York to watch Wynton Marsalis and his band play with traditional Indian instrumentalists from both Hindustani and Carnatic backgrounds, in a performance called “The Rhythms of India”. What I remember was that it was fantastic, and I felt moved. Clearly, live music tends to have that effect on me. There was one particular drum solo that I recall being ingrained in my memory for a month after the performance, but as it stands, it’s disappeared, replaced by what feels like a cheap imitation conjured by the mind, even if the memory of the emotions I felt at the performance remain intact. As an aside, if you can, try your best to watch Wynton Marsalis; he’s a fantastic performer and cultivator of the jazz arts, and his “Big Band Holidays” albums are fantastic. In the seventh grade, I was on a bit of a tear with reading; I had gotten through most of Agatha Christie’s works, and was moving on to sci-fi. My young mind got through a couple books of Frank Herbert’s “Dune”, “Brave New World”, and some of Asimov’s seminal works, like “Foundation” and “I, Robot”. Last week, I went to Barnes and Noble with my friend and stumbled upon “Foundation” again, and picked it up. Now, given my fantastic use of the rule of three here, I’m sure you can see where I’m going with this. But what good is it to say I’ve read “Foundation” if I can’t recall it? Is there any pride, any sense of accomplishment, to be had with saying, “I’ve read all of Poirot!”, if one has a scant recollection regardless? Or is it the emotions we carry on after the fact, the sensations that linger in the mind and perhaps the body, that are of value or import? As a further extension of that idea, and a brief detour from the overall point, I feel as though this discussion lends itself nicely to tackling the idea of impermanence. Take jazz, for example; I can go to a jazz bar and listen to a wholly unique rendition of a standard, by virtue of improvisation and a skilled band. I can play with my friends, and feel alive as we enable and push each other to grow as musicians. But in the same vein, I can listen to the great Miles Davis’ solo on So What</a> again and again, replaying what was, to him, a single moment in 1959. Does this permanence dull its impact on us? Does experiencing something live, but having to deal with the fallibility of memory change its effect on us? To be sure, I prefer live music, and I’d be remiss in saying it doesn’t have its own special way of brightening my day, but I can just as easily get a vinyl of an album I love, and have the sound pour through good speakers, close my eyes, and teleport myself. Glenn Stallcop says on his blog</a>: “Ideas are only pure in their abstract form. In reality, they are fleeting and fragile events. Plato thought that Concepts were the only true reality, and life was just an imperfect reflection or shadow. But actually, it is the reverse which is true. Reality is messy and in constant flux. It is Concepts which are the simple approximations of fleeting moments.” </blockquote> It’s a sobering thought, that everything is technically destined for decay. Some day, there will come a time when Miles Davis’ So What recording from 1959 is played for the last time. Some day, the last page of Tintin will be turned. Some day, someone will watch Grey’s Anatomy for the last time (thank god). My evidently muddled thoughts on (im)permanence have informed a fair few aspects of how I approach the world, and these thoughts are intimately tied to how I approach memory, or the art of remembering things with intentionality. Section 2: Memory, Loving, and Knowing</h3> My memory is interesting. I tend to remember vivid flashes of memory from various points in my life – I can, for example, recall when I dropped a die-cast model Discovery Space Shuttle on my foot when I was four years old, at our old house a couple miles from where I’m writing this. I can remember my first (and I believe only) goal in my high school soccer career, running into the box and sliding into the ball, watching it sail past the keeper into the mid left of the net. Being shocked, happy, pumping my fist. I can remember deciding whether or not to take a nap during my APUSH exam (I ended up napping for 10 minutes and then taking the exam anyway). But on the flipside, my short term memory sucks. I forget what I did a couple hours ago, yesterday, last week. It takes an insane amount of effort to remember if I took a shower, or I ate, or I did a task. I have a calendar which I rely on for almost everything, and I mean everything. It has the usual – classes, birthdays (we will come back to this later), tasks, but it also has things like “Call Parents”, “eat”, “go to bed, dumbass”, “check in with friends”, etc. This calendar acts as a storage for some of my mental load, for better or worse. Whether a function of my brain or other factors, I seem to thrive off of regularity, and my calendar is a vehicle for that. I guess in some ways, regularity can make each day seem less meaningful? If the same thing happens each day, the days may blend together. Alternatively, having regularity can make the bright interjections even brighter; going for lunch with my friends, having a nice dinner with my family, visiting Dallas to see my cousins. A related thought I had, which has come up with my family and partner before, is the idea of memory specifically as it relates to spontaneity. To me, spontaneity is formulaic. You begin by remembering someone or something, and from there you can plan out how to act on it. Some studies do show that spontaneity can be triggered by the reactivation of stored memories, so at least in some sense, my approach isn’t unfounded, but this sort of naturally begs the question: if I offset the mental load of tasks to a calendar, does that make them less meaningful to others? This is something I continue to struggle with, and not something I have the answer to, although it helps to verbalize it here. “To be loved is to be known” is a quote that resonates quite a bit with me. I don’t really know why, but there’s something warm and sweet in being able to coexist around others, knowing they understand you fundamentally, and it’s changed how I love and show love, in some ways. Interestingly enough, the way I first realized this about myself was through my love of NBC sitcoms. At the time of writing, I’ve watched The Office around 3 or 4 times all the way through, and the first 4 seasons even more. I’ve watched Parks and Recreation at least twice, and I could, at one point, give you the season and episode number of any episode of the first three seasons of Community if you gave me a plot point or two. These shows have shaped who I am in some way, and taught me pop culture, made me appreciate certain styles of humor, and made me glean more about myself in many ways. I will always love them. As it does, however, time passes, and I find it harder to remember the shows’ intimate details, even though I retain the emotions of watching them, and the vibes and enjoyment I had. As an aside, a point of pride for me is feeling as though I know the characters, even if I forget the content. I am almost always able to get into the frame of mind of characters I care about. These shows have clearly impacted me permanently (I make far too many references to count, these days), but it scares me. Should love be constant and uniform, then? What do we say about the friend we talk to every day, compared to the friend we reach out to once a year and pick up immediately where we left off? Another thing with shows, and media more generally, is the preservation of the image in my mind. As I mentioned earlier, sometimes all I remember of a piece of media is the emotion it brought to me, some memories of the feelings naturally stronger than others (whether by virtue of recency or otherwise). There occasionally exists this tension between my desire to re-up my memory of the content, and my fear of tarnishing the memory of the feeling. Take Avatar: The Last Airbender, for example. I first watched Avatar my sophomore year of high school, and I loved it. Truly; the plot and characters were moving, and I still follow along with the Darkhorse comics and other content that’s released (original movie notwithstanding). That was 5 years ago, though. I’ve grown and hopefully matured as a person, my perspectives have changed, and my humor has changed as well. Watching Avatar now could very well taint my enjoyment of it, past, present, and future. This idea has stopped me from (re)watching a handful of shows that I know I loved, but couldn’t bear the thought of losing the feelings for. Something to work on, or maybe let be. Continuing with the maxim of loving as knowing, we turn back to interpersonal relationships (oh joy)! This is something I have a curious relationship with (heh), and it stems from an unintentionally strict application of our aforementioned maxim. Similar to characters, I love people by knowing them. Their hobbies, their strengths, their character (for lack of a better word), but also the facts. Their birthdays, their addresses, their families, their accomplishments. I take some pride in being able to wish someone a Happy Birthday early in the day, because I knew it was their birthday! In a very “treat others as you’d like to be treated” way, I imagine that others appreciate being remembered and known just as I would, which is a slight misconception. Sometimes, birthdays feel sad for this reason; it feels as though the people that matter most seem to forget, but I try my best to remind myself that even though I treat this as a maxim, it’s local to me. I don’t really think “love language” categorizations are fair or really accurate, but it’s certainly the case that the act of love is unique to each individual. In any case, I’ve thought about how I love and how it ties in to remembering for quite a bit, and once again it’s nice to put an idea to paper (GDocs). Section 3: Permanence</h3> Pictures and I go way back. I used to want to be a photographer, actually; I got pretty good at Photoshop and Lightroom (as well as a middle schooler could be, at least), and took lots of photographs of landscapes, animals, et cetera. Crucially, I feel the need to point out here that I pirated both, and I vehemently despise Adobe for their subscription model and insane AI practices over the last few years. End minirant. The other side of photography was actually being photographed. For whatever reason, being photographed and thereby being perceived is, or at least was, kind of terrifying to me. A possible reason for this is that by immortalizing a part of me that I didn’t want you to know or see, I feel worse. I do distinctly remember feeling worse about my figure and face growing up; I didn’t like how skinny I was and I didn’t like my smile. This seems to have translated in some way to an aversion to being photographed. It’s gotten a bit better recently, as has my smile (at least I seem to think so, which is what really matters), but the foundations of the fear were quite curious in my opinion. Of course, the other perspective that arises with photographs ties back to our discussion of permanence. There will inevitably be a time when your loved ones leave you – it could even be you first. What do you do when they’re gone? Will you remember them faithfully, and how can you guarantee that? More pointedly, will the memory of the feelings they incited and the emotions surrounding your cumulative interactions be valuable enough to offset the inevitable decay of memory? I don’t remember my Dadu’s voice or face, because I wasn’t really conscious then. We have precious few pictures of him, and he exists primarily in the consciousness of my father and my Dadi. It’s sobering. For all the reasons above, having pictures, videos, and other means of permanence make for a safe back-up of one’s memory. In the vein of permanence, another thing to think about is sentimentality and one’s legacy; the ways in which we’re remembered, either in the minds of others, through actions making their mark, or objects of significance. For example, I recently had a conversation with my father about watches. He wears an Apple watch most days, but has a few assorted watches that are particularly important to him, including a few gifts from my Nanu, which he cherishes. Through this watch, the memory of my Nanu is shared long after he’s gone (although we hope that isn’t soon), and in it is a special reminder of the relationship between my Nanu and my father as well. As for legacy, that’s a little more involved. What goal do I want when it comes to my legacy? Do I want to be remembered as a good worker, a visionary, a great family man? How consciously should I think about the image of me in others’ minds, and how to form and shape that image? I suppose realistically, only time will tell, and hopefully I can remember to check in on this treatise of sorts and reflect on it. The end and beginning</h3> All this started because I asked the question, “If I say I like(d) something, but I don’t remember the content, did I ever really”? I still don’t really know. I think maturing will be realizing eventually that although the decay and fallibility of the mind is inevitable, we can respect that, enjoy the emotions as they pass and linger, and move on. I’m not sure if that’s currently satisfying to me, but it’s what I’ve landed on and I’ve also been typing for about 4 hours, give or take, so there. I hope you enjoyed, – Arjun Rewriting Rust's zip (poorly) 2024-12-15T00:00:00+00:00 Betwixt all of the Marvel Rivals and drumming I’ve been doing since I finished my fall semester, I thought it’d be a good idea to try rewriting std::iter::zip</code>; in the past, I’ve followed along with Jon Gjengset’s Crust of Rust on Iterators</a> (to make Flatten</code>) and tried my hand at FlatMap</code> as well (see Elton Pinto’s blog</a> as a nice insight). This article is inspired by his, although will probably less involved as I found zip</code> to be easier to implement, largely because FlatMap</code>, for example, involves nested iterators and FnMut</code> and other such fancy traits, while Zip</code> is a more intuitive operation. There were only a few hiccups along the way. As an aside, did you know that hiccough is a valid spelling, and hiccup is the more modernized version? English is dumb. What the hell is a zip?</h3> Rust’s std::iter::zip</code> has one simple goal; when calling zip</code> on two items that can be turned into iterators, we want zip</code> to return pairs of each subsequent entry in each input! That’s a mouthful, but a simple example from the docs will likely help: let xs = [1, 2, 3]; let ys = [4, 5, 6]; let mut iter = zip(xs, ys); assert_eq!(iter.next().unwrap(), (1, 4)); assert_eq!(iter.next().unwrap(), (2, 5)); assert_eq!(iter.next().unwrap(), (3, 6)); assert!(iter.next().is_none()); </code></pre> Now that you hopefully understand what’s happening a bit better, the next step is Figuring out how to make this shit</h3> Most things in the standard library are designed as follows: Have a function to do a thing (zip</code>), and create a struct that represents the thing you want the result to be Zip</code>.</li> Use traits, associated types, and generics to implement functionality on top of said resulting thing impl Iterator for ...</code></li> Profit</li> </ol> So, let’s get started with all of this, beginning with our zip</code> function: fn zip<A, B>(a: A, b: B) -> Zip<A::IntoIter, B::IntoIter> where A: IntoIterator, B: IntoIterator, { Zip::new(a, b) } </code></pre> We haven’t quite implemented the Zip</code> struct yet, but we will soon. For now, notice that intuitively we need both a</code> and b</code> to be able to be converted to Iterators; thus, we can place the IntoIterator</code> trait bound on them. Having the bound be Iterator</code> would be “too strict”, in a sense, and would functionally require us to call .into_iter()</code> on everything we’d pass in to zip</code>. Also, while IntoIterator</code> is a trait, IntoIter</code> is an associated type! Associated types are type aliases associated with another type/trait. You may be thinking, this sounds a lot like generics, and yeah they’re kind of similar, but the crucial difference is that associated types are specific to an implementation (i.e. in the impl</code> block) of a trait, while generics allow multiple implementations. This thread</a> has a good explanation, which I’ll attempt to summarize. pub trait IntoIterator { type Item; type IntoIter: Iterator<Item = Self::Item>; // Required method fn into_iter(self) -> Self::IntoIter; } </code></pre> This is the definition of the IntoIterator</code> trait, with the subsequent definition of the IntoIter</code> type as well. Notice here that the type IntoIter</code> resolves to a concrete type, as IntoIterator is implemented on a specific type. For example, if we call into_iter()</code> on an object of type Vec<u32></code>, then the Item</code> is of type u32</code>, and thus we create an Iterator<Item = u32></code>, which is exactly as desired. Clearly, for each implementation of a given trait for a given type, we have a unique resolution for the associated type, which makes intuitive sense. On the flipside, something like Add<Rhs></code> can be implemented multiple times for a variety of types of Rhs</code>, i.e. parametric polymorphism (generics). Now that that’s out of the way, let’s get back to Zipping it! Time for structs</h3> Our zip</code> function wants an output of type Zip<A::IntoIter, B::IntoIter></code>, so let’s do that. pub struct Zip<A, B> where A: IntoIterator, B: IntoIterator, { a: A::IntoIter, b: B::IntoIter, } </code></pre> Well. That was easy. The only thing we’re missing is the new</code> function that we used in zip</code>, but that shouldn’t be too hard: impl<A, B> Zip<A, B> where A: IntoIterator, B: IntoIterator, { fn new(a: A, b: B) -> Zip<A::IntoIter, B::IntoIter> { Zip { a: a.into_iter(), b: b.into_iter(), } } } </code></pre> Notice how the return type matches our zip</code> function signature; the rest is pretty reasonable. Implementing Iterators Interestingly (not)</h3> The last thing we need to do is to make our Zip</code> struct actually somewhat useful, so we need to implement the Iterator</code> trait for it, which will get us all sorts of goodies for free (please do consult the standard library</a> if you forget). The only thing we really need to implement for iterators is next</code> (it’s the “required method” they mention in the docs); here’s the code: impl<A, B> Iterator for Zip<A, B> where A: Iterator, B: Iterator, { type Item = (A::Item, B::Item); fn next(&mut self) -> Option<Self::Item> { let x = self.a.next()?; let y = self.b.next()?; Some((x, y)) } } </code></pre> Here, we notice that Item</code> is an associated type for Iterator</code>; crucially, it’s not predefined, and so we can set it to whatever we need. Here, since our goal is to get tuples of items from our two iterators, we simply do as described. The function implementation itself is also largely trivial – just get the next values of both iterators, and return a tuple of them. If either is None</code>, the ?</code> operator will gracefully handle this and return None</code> for the overall iterator as desired. We’re done??</h3> Yes. Have a happy holidays and see you next time! Advent of Code Day 5: Topological Sort! 2024-12-05T00:00:00+00:00 As before with Day 3</a>, I won’t be redescribing the puzzles in full; please check out Advent of Code</a> for more. This problem was fun to solve, and allows me to do a quick explainer on topological sorting (see part 2), hope you enjoy! Part 1: OSHA would be very mad</h3> The pages of the safety manuals are out of order, oh fie! Whatever shall we do to verify their validity??? (Tragic, I know.) Histrionics aside, the basis of this problem is simple; we have lines that give us a before|after</code> relation between pages, and then we have lines of pages as a list, and we have to verify that they work. A sample input is as follows: 47|53 97|13 97|61 97|47 75|29 61|13 75|53 29|13 97|29 53|29 61|53 97|53 61|29 47|13 75|47 97|75 47|61 75|61 47|29 75|13 53|13 75,47,61,53,29 97,61,53,29,13 75,29,13 75,97,47,61,53 61,13,29 97,13,75,29,47 </code></pre> Our end goal for part 1 is to sum up the middle pages of all of the “correctly ordered” lines, but I will mostly be focusing on how we can check for that, rather than the overall solution. To begin, I create a rule_map</code> that contains, for every before</code> page, a HashSet</code> of all of the pages that must come after it! For example, in the above input, notice that 13</code> must come after 29</code>, so that gets placed in our rule_map</code>. This is populated as follows: rule_map.entry(before) .and_modify(|after_pages| { after_pages.insert(after); }).or_insert(HashSet::from([after])); rule_map.entry(after).or_insert(HashSet::new()); </code></pre> We add an entry for after to make it easier to handle cases later. Then, the real checking begins when we encounter the lines, and the logic here is that since we have a mapping (for a given page number) of all of the pages that should come after it, if we have seen a page that should come after our current page, we know we’ve found an incorrect list. 'outer: for line in read_to_string(file).unwrap().lines() { // Do some stuff here that isn't relevant to this code block // ... let mut seen = HashSet::<u32>::with_capacity(nums.len()); for num in &nums { let after_pages = rule_map.get(&num).unwrap(); // checks for the bad thing let found = after_pages.iter().any(|val| seen.contains(val)); if found { continue 'outer // skip this entire line, basically } seen.insert(*num); } } </code></pre> A small nifty thing here is the continue 'outer</code> syntax; if we are in a for loop that is nested, but we want to break out of the outer for loop, we can tag the outer for loop with 'outer: for ... in ...</code>, and then use the continue 'outer</code> syntax! This also works with break</code> as well. After this, if we haven’t found an error, then we just add the middle page values up with sum += nums[nums.len()/2]</code> (simple as). Part 2: Topo-sort is inevitable</h3> There are 100% other ways to do part 2. However. I could not find them. It was 2 AM again. Anywho. So the basis of this problem is that for all of the incorrect rows we marked previously, we now want to fix them and find the sum of their middle pages, a la part 1. Originally I was thinking of some sort of bubble sort esque swapping solution, but I couldn’t intuit it nicely, so I went with topological sorting instead since it felt somewhat natural. As a brief aside, it felt natural primarily because we’ve been dealing with what is essentially a dependency graph this entire time, and it’d be a shame not to leverage that structure with a nicely made DAG just sitting there, yknow? So the rest of this section is going to basically just be an introduction to topological sorting because you can probably fill in the gaps as to how the rest of part 2 is done. Topological Sorting, for dummies</h4> Simply put, given a directed acyclic graph (DAG), a topological sort</a> is a linear ordering of vertices such that for all edges from u to v, u is “before” v in the linear ordering. A good example is in this image which is for this original list [97,13,75,29,47]</code> (thank you to Ved</a> for the graph). There are a few ways to implement toposort, but the most intuitive to me is Kahn’s Algorithm</a>, which goes as follows: (Prior to doing much of anything) For the list you are trying to sort, calculate the “in degree” of each vertex; this is just the number of nodes that have edges flowing into the current node.</li> </ol> let mut in_degree: HashMap<u32, u32> = HashMap::new(); for &node in &input { in_degree.insert(node, 0); } for from in &input { if let Some(neighbors) = rule_map.get(&from) { for &to in neighbors { if input.contains(&to) { *in_degree.entry(to).or_insert(0) += 1; } } } } </code></pre> Note that we have to be careful to do our in degree calculation locally, and not over the whole list, since the whole list may not have a valid topological sort (may not be an acyclic graph). Now that we have our in degree calculated for all relevant nodes, we can create a queue of zero in degree nodes. Intuitively, we want to start at the nodes that have no other nodes as dependencies. This can be done easily with:</li> </ol> let mut zero_in_degree: VecDeque<u32> = in_degree .iter() .filter(|&(_, &deg)| deg == 0) .map(|(&node, _)| node) .collect(); </code></pre> Do the actual topological sort. This is arguably best explained with the code itself, so take a look below and I’ll explain in bits and pieces after:</li> </ol> let mut sorted = Vec::new(); while let Some(node) = zero_in_degree.pop_front() { sorted.push(node); if let Some(neighbors) = rule_map.get(&node) { for neighbor in neighbors { if let Some(count) = in_degree.get_mut(neighbor) { *count -= 1; if *count == 0 { zero_in_degree.push_back(*neighbor); } } } } } </code></pre> First, we take a node from the zero in degree queue and add it to the sorted list.</li> Then, for all of the neighbors of the popped node, decrement their in degree. You can think of this as deleting a node that feeds into the neighbors, so decrementing is natural.</li> If the new in degree of any of the neighbors is 0, they get added to the zero in degree queue, and we repeat until done!</li> </ul> Life’s sorted again</h3> And there you have it, done with day 5! This was a pretty fun problem to solve, and I’m somewhat happy with how my solution turned out. See you next time :D Advent of Code Day 3: Overengineering 2024-12-03T00:00:00+00:00 So I’m doing Advent of Code this year, and hopefully we can stick through all 25 days. Day 3’s problem was particularly interesting to me, and I did some silly (and hopefully somewhat clever) stuff that I think would be fun to write about. Here we are. I likely won’t redescribe the puzzles in full - for that, just head over to Advent of Code</a> - but I will summarize the parts briefly. Part 1: This is where the fun begins</h3> So the main goal of this problem is to, within a single line/string, find matches of mul(num1, num2)</code> and sum up all of the multiplication operations, giving you your answer. The sample text they provide for this is: xmul(2,4)%&mul[3,7]!@^do_not_mul(5,5)+mul(32,64]then(mul(11,8)mul(8,5)) </code></pre> which will eventually output (2*4 + 5*5 + 11*8 + 8*5) = 161</code> Initially, I thought I could do it with Regex, and you certainly could, but that didn’t feel like a satisfying enough solution to me. One of my friends also challenged me to use just Rust’s standard library and nothing else, so that removed the regex</code> crate from contention entirely. My next idea, which is what I ended up going with, was to basically handwrite a lexer and do some nifty sliding window magic. Step 1: Defining Tokens</h4> First thing’s first, we have to define the tokens we’re going to be using. With a little bit of inspiration from the fantastic Crafting Interpreters</a>, I ended up with the following: enum Token { LPAREN, RPAREN, COMMA, NUMBER(u32), MUL, OTHER, // throwaway } </code></pre> (To be clear, Crafting Interpreters also helped elsewhere) Clearly, the only tokens that make up something like mul(num1, num2)</code> are mul</code>, (</code>, ,</code>, )</code>, and numbers. Anything else is captured as OTHER</code> and thrown away (handled, admittedly, in quite a disgraceful way. I wonder what my future employers would think). Step 2: Lexing the damn thing</h4> Warning: there’s gonna be a shitload of code below. I will explain it in a moment First, we set up the file reading and the iterator over our characters: let line = read_to_string(file).unwrap(); let mut iter = line.chars().peekable(); let mut tokens: Vec<Token> = Vec::new(); </code></pre> We call peekable()</code> on our iterator because the Peekable</code> struct provides us the peek</code> method, which allows us to look at the next character without consuming it. This is particularly advantageous when we want to look ahead just once or twice in a controlled manner. Now, here’s where the magic happens! while let Some(ch) = iter.next() { match ch { '(' => tokens.push(Token::LPAREN), ')' => tokens.push(Token::RPAREN), ',' => tokens.push(Token::COMMA), '1'..='9' => { let n: u32 = once(ch) .chain(from_fn(|| iter.by_ref() .next_if(|s| s.is_ascii_digit()))) .collect::<String>() .parse() .unwrap(); tokens.push(Token::NUMBER(n)); } 'm' => { let rest = next_chunk(&mut iter, 2); if rest == vec!['u', 'l'] { tokens.push(Token::MUL); } } _ => tokens.push(Token::OTHER), } } </code></pre> This is a lot, so I’ll break it down for the relevant chunks. We’ve also removed the part 2 code from here as well (and it will return soon). Naturally, we start by iterating until there are no more characters to yield. In each match arm, we handle a specific character case. The parentheses and the comma are pretty self-explanatory - just add the corresponding token variant to the vector - but the number and mul</code> keyword handling are slightly more involved. '1'..='9' => { let n: u32 = once(ch) .chain(from_fn(|| iter.by_ref() .next_if(|s| s.is_ascii_digit()))) .collect::<String>() .parse() .unwrap(); tokens.push(Token::NUMBER(n)); } </code></pre> This seems like a bit of word vomit, but is nicer with a few choice words explaining it, I hope. It’s also largely lifted from this post</a> by Bruno Calza, so thank you Bruno. Here, we essentially chain together iter::once(ch)</code> (i.e., a single repetition of the first/matched character, to make sure it’s included in the resulting String), followed by all of the following characters that are digits, using Peekable</code>’s next_if</code> function, which takes in a function that returns a boolean and allows us to continue based on a condition. I won’t go into much more depth, but this is an interesting construction that I did not entirely come up with. Finally, there’s the mul</code> keyword match. The idea is simple, if we see an m</code>, let’s check the two following characters and see if they are u and l! I don’t think this is a safe assumption to make all the time, but this design choice was selected in order to optimize developer implementation efficiency (it was 2 AM). 'm' => { let rest = next_chunk(&mut iter, 2); if rest == vec!['u', 'l'] { tokens.push(Token::MUL); } } </code></pre> The Rust standard library has a next_chunk</code> function in nightly, and when I was originally implementing this, I used many a iter.peek()</code>, is_some()</code>, next_if_eq()</code>, and other nested gems. However, after Ved</a> correctly pointed out that nothing was stopping me from writing my own wannabe replacement, I got to work. It’s quite simple (with a more complicated extension), and I’ll talk about them more towards the end. Step 3: Whatever shall we do with this token stream?? (parse it [kinda])</h4> The last major piece of the puzzle is as follows; now that we have our very cool token stream, how the hell do we make it useful? The fun way I thought of doing this was by using a sliding window over the tokens; since we know the structure of the mul</code> operation quite well, we can just pass a window of the necessary size and check if it contains the necessary elements! For each slice, if there’s a match, we add the product of the values contained within, otherwise just add 0. let sum:u32 = tokens[..].windows(6).map(|slice| { if let [ Token::MUL, Token::LPAREN, Token::NUMBER(a), Token::COMMA, Token::NUMBER(b), Token::RPAREN ] = slice { a * b } else { 0 } }).sum(); println!("{sum}"); </code></pre> This was quite fun to solve, and for all its flaws and overengineering, it was an enjoyable experience. Part 2: To Multiply or Not to Multiply</h3> (it’s a toss-up, who knows)</h4> (we know, see below)</h5> The second problem centers around do()</code> and don't()</code> within a code fragment: xmul(2,4)&mul[3,7]!^don't()_mul(5,5)+mul(32,64](mul(11,8)undo()?mul(8,5)) </code></pre> When a don't()</code> is encountered, until a do()</code> is encountered after, all multiplications in between are invalidated. In order to support this, we make 3 major additions: Add DO</code> and DONT</code> as variants to the Token</code> enum</li> Add lexing support for DO</code> and DONT</code></li> Find out a way to remove the correct mul</code>s from consideration before using our sliding window technique</li> </ol> (1) is trivial, so let’s look at (2) just a bit closer. 'd' => { let next = iter.by_ref().next_if_eq(&'o'); if next.is_some() { iter.peek(); let next = iter.by_ref().next_if_eq(&'n'); if next.is_some() { let rest = next_chunk(&mut iter, 4); if rest == vec!['\'', 't', '(', ')'] { tokens.push(Token::DONT); } } else { let rest = next_chunk(&mut iter, 2); if rest == vec!['(', ')'] { tokens.push(Token::DO); } } } } </code></pre> We add this to the match</code> statement from before, and it follows the same principle as mul</code>. If we see a d, then we check if we have an o. After that, we branch based on whether or not the next value is n or not, and Bob’s your uncle or something. Before we explain next_chunk</code> (finally), let’s look at (3), which was also cool. // Goal: Remove all entries "between" a Token::DONT and a Token::DO let mut delete = false; tokens.retain(|token| { match token { Token::DONT => { delete = true; false // don't want to retain }, // Check if we have encountered a DONT before Token::DO if delete => { delete = false; false // don't want to retain } _ => !delete, // keep elts if not in delete mode } }); </code></pre> I hadn’t really used retain</code> before, but it’s conceptually quite simple; we pass in a function on an iterator, and it will retain all elements that return true</code>. The way this relates to our construction is as follows: if we hit a DONT</code>, we want to begin deleting, and we also want to delete DONT</code> so we return false</code>. If we hit DO</code>, we want to set delete to false</code>, but we want to clear away the DO</code> as well. For any other elements, keep them if not in delete</code> mode. This action allows us to maintain the invariant of not having DO</code> or DONT</code> at sliding window matching time (see part 1 step 3). I found this quite elegant, and the whole thing works as well. next_chunk</code> :D</h3> Now it’s finally time to showcase my darling boy; next_chunk</code>: fn next_chunk(iter: &mut Peekable, num: usize) -> Vec<I::Item> where I: Iterator { let mut chunk = Vec::with_capacity(num); for _ in 0..num { if let Some(item) = iter.next() { chunk.push(item); } else { break } } chunk } </code></pre> Pretty self-explanatory, but the real kicker is when we try to use const generics and return something with type [I::Item; N]</code>: fn next_chunk<I, const N:usize>(iter: &mut Peekable) -> Option<[I::Item; N]> where I: Iterator, ::Item: Copy, { // SAFETY: We are initializing an N elt length array, using MaybeUninit // for now let mut chunk = unsafe { [MaybeUninit::uninit().assume_init();N] }; for i in 0..N { if let Some(item) = iter.next() { chunk[i] = MaybeUninit::new(item); } else { return None } } // SAFETY: Convert uninit array to regular with transmute, // since they are the same size let chunk = unsafe { std::mem::transmute_copy::<_, [I::Item;N]>(&chunk) }; Some(chunk) } </code></pre> This bad boy right here is a bit crazier, although after digesting it, it becomes much more manageable. We use const generic const N: usize</code> for our sizing, and return an array</li> Because we can’t initialize an empty array, we use std::mem::MaybeUninit</code></li> We populate said array</li> We can now “safely” convert the array of MaybeUninit</code>s to an array of I::Item</code>s instead, with std::mem::transmute</code> (see this article</a> for a great discussion on transmute)</li> We can rest easy knowing we can now call the function like</li> </ol> next_chunk::<_, some_num>(&mut iter) </code></pre> instead of next_chunk(&mut iter, 2) </code></pre> (nice work buddy, the array comparison is more space efficient than the vector equivalence check, at least :D) That’s all, folks!</h3> I hope you guys enjoyed my first real blog and this assault on the English language. Thanks for reading! Other Blogs I like! 2024-11-30T00:00:00+00:00 I guess I can’t call this a brief detour from our regularly scheduled programming, since I have yet to establish what regularly scheduled programming looks like, but I wanted to have a blogpost that I update on occasion to store some of my favorite other blogs, and people who I know! This list will forever be incomplete. People I know:</h3> Ved Thiru</a></li> </ol> Blogs I Like:</h3> matklad</a></li> Ved Thiru</a></li> Max Bernstein</a>, particularly his PL Resources</a> page (and his great articles)</li> Scattered Thoughts</a></li> </ol> Why do we blog? 2024-11-18T00:00:00+00:00 Word Count: 279 As my first actual blog post, I feel like it’s fitting to discuss why I want to write a blog at all, as well as some expectations for content going forward (if I ever get around to it, that is). I think what initially inspired me was joining GT’s programming languages and compilers club, dependently-typed. The first few talks I attended were fascinating, and the club chairs pointed me to lobste.rs</a> as a great resource for tech blogs. Through that, I’ve spent much more time reading and learning about some of my favorite technical topics! I’ve since had the motivation to begin organizing my learning about some of these topics, particularly ones that I believe I’m either not well versed in, or those that I would like to master. The core idea here is that starting off, my blog is for me. It will be a place for me to document my journey through programming language theory, language design and implementation, and quantum computing. As I begin to get more and more confident, it may yet become a place for me to broaden my horizons or, perhaps, try my hand at teaching/explaining things. Time and time again, I’ve found myself collating several sources into a patchwork of knowledge in my mind, and this amalgamation of unique perspectives makes my understanding deeper; it would be awesome to one day see some of my work help another in a similar vein. That’s basically it for this blog (article?) I think. For future posts, I have no real expectation of min/max length, and I may also intersperse the technical talk with some more personal drabbles as well. I hope you enjoyed, Arjun</li> </ul>

`We’re done??</h3> Yes. Have a happy holidays and see you next time!</p>`

Life’s sorted again</h3>
And there you have it, done with day 5! This was a pretty fun problem to solve, and I’m somewhat happy with how my solution turned out. See you next time :D</p>

Part 2: To Multiply or Not to Multiply</h3>

(it’s a toss-up, who knows)</h4>

That’s all, folks!</h3>
I hope you guys enjoyed my first real blog and this assault on the English language. Thanks for reading!</p>

People I know:</h3>

Ved Thiru</a></li> </ol>
Blogs I Like:</h3>

matklad</a></li>
Ved Thiru</a></li>
Max Bernstein</a>, particularly his PL Resources</a> page (and his great articles)</li>
Scattered Thoughts</a></li> </ol>

Blogs I Like:</h3>

matklad</a></li>
Ved Thiru</a></li>
Max Bernstein</a>, particularly his PL Resources</a> page (and his great articles)</li>
Scattered Thoughts</a></li> </ol>

asb's corner

Understanding Whole Program Paths and Path Profiling

Proving bounds for the Randomized MaxCut Approximation algorithm in Lean4

talking

Are photos even real?

tuesday

Attention

Untitled 1

Doing things because they are hard

But like, why? Do you have problems?</h2>
Yes. Probably. Next question.</p>

My relationship with memory

Rewriting Rust's zip (poorly)

Advent of Code Day 5: Topological Sort!

Advent of Code Day 3: Overengineering

Other Blogs I like!

Why do we blog?

asb's corner

Understanding Whole Program Paths and Path Profiling

ho(W) do we (P)rofile (P)aths, then? (WPP)</h2> The idea of Whole Program Paths begins with the humble acyclic path itself. The procedure itself works in two phases (from §1.1):</p>

(1) $\text{CFG} \rightarrow \text{DAG} = \text{joy}$</h4> Blissfully unawares of any looming complications, we dive headfirst into the CFG to DAG conversion. The paper is largely clear about this, and for that we all say “thank you”.</p>

Terminating acyclic paths at calls</h3> I spent a couple days of my free time drawing flowgraphs in contrived scenarios before a conversation with my TA initiated a eureka moment of sorts. At that point, I had been working on a very specific test case (Fig 2 in the WPP paper): </p>

Proving bounds for the Randomized MaxCut Approximation algorithm in Lean4

Structures</h3> The first step is always representing our key structures. Lean already has a SimpleGraph</code>, so all we need to do is design a structure to store our Cut</code>:</p>

talking

Are photos even real?

tuesday

Attention

Untitled 1

Doing things because they are hard

But like, why? Do you have problems?</h2> Yes. Probably. Next question.</p>

My relationship with memory

Rewriting Rust's zip (poorly)

Figuring out how to make this shit</h3> Most things in the standard library are designed as follows:</p>

We’re done??</h3> Yes. Have a happy holidays and see you next time!</p>

Advent of Code Day 5: Topological Sort!

Life’s sorted again</h3> And there you have it, done with day 5! This was a pretty fun problem to solve, and I’m somewhat happy with how my solution turned out. See you next time :D</p>

Advent of Code Day 3: Overengineering

Part 2: To Multiply or Not to Multiply</h3>

(it’s a toss-up, who knows)</h4>

(we know, see below)</h5> The second problem centers around do()</code> and don't()</code> within a code fragment:</p>

That’s all, folks!</h3> I hope you guys enjoyed my first real blog and this assault on the English language. Thanks for reading!</p>

Other Blogs I like!

Why do we blog?

But like, why? Do you have problems?</h2>
Yes. Probably. Next question.</p>

`We’re done??</h3> Yes. Have a happy holidays and see you next time!</p>`

Life’s sorted again</h3>
And there you have it, done with day 5! This was a pretty fun problem to solve, and I’m somewhat happy with how my solution turned out. See you next time :D</p>

That’s all, folks!</h3>
I hope you guys enjoyed my first real blog and this assault on the English language. Thanks for reading!</p>