Eli Bendersky's website

Thoughts on starting new projects with LLM agents

2026-06-06T17:38:00-07:00

A few months ago I wrote about using LLM agents to help restructuring one of my Python projects. It's worth beginning by saying that the rewrite has been successful by all reasonable measures; I've been able to continue maintaining that project since then without an issue.

In this post, I want to discuss another project I've recently completed with significant help from agents: watgo. In this project many things are different; most notably, it's a from-scratch project rather than a rewrite, and it uses a different programming language (Go). This post describes my experience working on the project, and some lessons learned along the way.

The process

This is a new project, so it required extensive design. I began by iterating on the design with the agent, with a sketch of the API. For this purpose, I recommend using a Markdown file committed into the repository for future reference.

After that, I started asking the agent to write CLs [1] in a logical order that made sense to me, keeping them small and reviewable (more on this in the next section). Sometimes it's not easy to have a small CL, and multiple rounds of revision may confuse the agent; in this case, I commit the CL and then go back and ask the agent to modify or refactor the code, as much as needed, with separate CLs. In the worst case, the whole sequence can be reverted if I feel we've taken the wrong direction (branches could also be helpful here for more complicated scenarios).

This point is worth reiterating: sometimes a single CL is a huge step forward, but requires lots of review, cleanup and refactoring to be viable. I've had multiple instances where an agent produced several days of work in a single CL, but I then spent hours instructing it to clean up and refactor. Overall, it's still a productivity gain, just not as much as some pundits would like us to believe.

Keeping the human in the loop

Given the current state of agent capabilities, I think it's worth splitting projects into two categories:

Low importance / prototype / throw away projects where deep code understanding is unnecessary. These can be "vibe-coded" (submitting agent code without even reviewing it).
High importance projects that I actually want to maintain; here, vibe-coding is ill advised and I insist on reviewing and guiding all code the agent writes before it's submitted (or shortly after, as discussed above).

The watgo projects is a clear example of (2): I certainly intend to maintain this project in the long term, so I insist on code that I understand. With very few exceptions, no code gets in without full review and often multiple rounds of revisions.

Even if the cost for writing code went down, maintaining a project is so much more than that. It's triaging and fixing bugs, it's thinking through what needs to be done rather than how to do it, it's keeping the code healthy over time, and so on. As Brian Kernighan said:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

Maybe at some point agents will become good enough that projects in category (2) can be implemented and maintained completely autonomously. Maybe. But we're certainly not there yet. My hunch is that getting there will require crossing the AGI line [2], after which little in our world remains certain.

Practical workflow

If you're using an agent to send an actual PR and only review that, it's difficult to be disciplined enough to actually perform a thorough review. I find the following method to be more reliable:

I use a CLI agent running locally in my repository, and ask it to update the code there. In parallel, I have a VSCode window open in the same project, where I can:

Review the agent's changes using VSCode's diff view
Make my own tweaks and code changes if needed

Once I'm pleased with the change, I manually create a commit.

Keeping the CLs small

As mentioned above, it's imperative to keep making progress in small chunks, with small enough CLs that a human can fully understand in a single review. It's very tempting to sprint ahead submitting thousands of lines of code every day, but this temptation has to be avoided. Coding with an agent is like speed-reading; yes, you're making more progress, but comprehension suffers the faster you go.

Particularly for refactoring, agents still take the shortest route to destination. It's important to guide them to think about the "big picture" at all times, find all instances where X is better done as Y, not just a single place noticed during a review. This is why it's sometimes OK to have a CL submitted before you fully agree with everything, and go back to it later for several refactoring rounds. Source control works amazingly well when pair-coding with agents.

Testing strategy

It's a key point discussed in every "how to succeed with AI" article, but still critical enough to reiterate here: a solid testing strategy is absolutely crucial for success. Agents produce - by far - the best results when they have a solid test suite to test their code against.

With the pycparser rewrite, I had a large existing test suite. For watgo, the very first thing I did was think through how to adapt the test suites of the WASM spec and of the wabt project for my needs.

If your project doesn't have such tests to rely on, this should be your first order of business - finding one, or building one from scratch. Beware of self-reinforcing loops though; it's dangerous to trust agents for both the tests and the implementations tested against them.

Language choice - Go for agent-written projects

Go is a fantastic language for agents to write, because it's designed to be very readable by humans. The biggest strengths of Go are exactly what makes the experience of reviewing agent code so positive:

Go changes very infrequently, so you don't have to wonder "are we using the most modern / idiomatic approach" or "what the hell is this construct" as often as with other languages (looking at you, Python and TypeScript).
There are relatively few ways to accomplish the same thing in Go, further lowering the mental burden.
The standard library is rich and there's much less need to keep abreast of the package-everyone-uses du jour.
In general, Go is designed for readability, with a mild-but-still-strong type system, uniform formatting, explicit error propagation and opinionated choices already made for you.

Since most of the time spent by humans when using agents is reading rather than writing code, these effects compound and produce a great experience. Recall the discussion of how some languages are optimized for writability (Perl) while others are optimized for readability (Go)? Well, when working on a project with an agent we live in a world of 99% reading vs. 1% writing, so this really matters.

I find this aspect really crucial in light of the earlier points made in this post - namely, keeping the human in the loop by understanding and reviewing all of the agent's design choices and code.

Final thoughts

If you're working on a subject that's completely new to you, I would strongly recommend against the approach described in this post. To really learn something, you have to work through it from scratch, yourself, reading, designing, writing the code. Agents don't change this basic fact; even before agents, if you wanted to learn X, copying it from Stack Overflow or some other project clearly wasn't the right way to go. Similarly, while agents can be used as a prop for learning, they cannot learn for you.

As a corollary, junior engineers should exercise extreme caution when relying on LLMs. There's no replacement to hard-won experience and the sweat and tears of learning new, challenging topics. Learning is supposed to be hard; if it's too easy, you're probably not learning.

For senior engineers, agents are a boon; it's a great tool to increase productivity, avoid the boring stuff, and get unstuck from procrastination; but only when used judiciously.

[1]	CL stands for Changelist, also known as a "patch" or a "diff" - basically a standalone commit that touches one or more files. This term originates from the source control systems Perforce and Subversion.

[2]	Programming is the ultimate realization of thought; if machines can design, produce, maintain and understand code better than humans, it means they can start improving themselves, which is the definition of singularity.

Notes on Fourier series

2026-05-27T19:30:00-07:00

The trigonometric Fourier series is a beautiful mathematical theory that shows how to decompose a periodic function into an infinite sum of sinusoids. These are my notes on the subject, with some examples and the connection to linear algebra in Hilbert space.

Coefficients of Fourier series

Let’s assume that is a well-behaved 2L-periodic [1] function and that we can find coefficients a_n and b_n such that:

\[f(x)=\sum_{n=0}^{\infty}\left(a_n cos\frac{n\pi x}{L}+b_n sin\frac{n\pi x}{L}\right)\]

Then we say that the Fourier series on the right-hand side converges to . We’ll talk more about the assumptions mentioned above and convergence in the next section.

Note that when n=0, the sum becomes just ; therefore it’s customary to write the series starting with n=1, with a separate constant component (which is the function's average over one period). To make computations nicer, this constant is typically called a_0 / 2, so:

\[f(x)=\frac{a_0}{2}+\sum_{n=1}^{\infty}\left(a_n cos\frac{n\pi x}{L}+b_n sin\frac{n\pi x}{L}\right)\]

Our goal is to find the coefficients a_n and b_n that satisfy this equation. We’ll do this in three steps.

Step 1: Integrate both sides of the equation between -L and L [2].

\[\int_{-L}^{L}f(x)dx=\int_{-L}^{L}\frac{a_0}{2}dx+\sum_{n=1}^{\infty}\bigg (\int_{-L}^{L}a_n cos\frac{n\pi x}{L}dx+\int_{-L}^{L}b_n sin\frac{n\pi x}{L}dx\bigg )\]

Per Appendix A, all integrals within the sum are zero, so we’re left with:

\[\int_{-L}^{L}f(x)dx=\int_{-L}^{L}\frac{a_0}{2}dx=\bigg[\frac{x\cdot a_0}{2}\bigg]_{-L}^{L}=a_0\cdot L\]

And thus we find :

\[a_0=\frac{1}{L}\int_{-L}^{L}f(x)dx\]

Step 2: Multiply both sides by cos\frac{m\pi x}{L} (m is a positive integer constant) and integrate between -L and L.

\[\begin{aligned} \int_{-L}^{L}f(x)cos\frac{m\pi x}{L}dx&=\int_{-L}^{L}\frac{a_0}{2}cos\frac{m\pi x}{L}dx\\ &+\sum_{n=1}^{\infty}\bigg (\int_{-L}^{L}a_n cos\frac{n\pi x}{L}cos\frac{m\pi x}{L}dx+\int_{-L}^{L}b_n sin\frac{n\pi x}{L}cos\frac{m\pi x}{L}dx\bigg ) \end{aligned}\]

Looking at the right-hand side, the first integral is zero per Appendix A, and the last integral is zero per Appendix B. We’re left with:

\[\int_{-L}^{L}f(x)cos\frac{m\pi x}{L}dx=\sum_{n=1}^{\infty}\int_{-L}^{L}a_n cos\frac{n\pi x}{L}cos\frac{m\pi x}{L}dx\]

Per Appendix B, the integral on the right is zero for all n\neq m, and L for n=m. Therefore, we can write:

\[\int_{-L}^{L}f(x)cos\frac{m\pi x}{L}dx=a_m\cdot L\]

Recall that m is an arbitrary integer, just like ; for consistency, we’ll replace m by and isolate a_n:

\[a_n=\frac{1}{L}\int_{-L}^{L}f(x)cos\frac{n\pi x}{L}dx\]

Step 3: Hopefully it’s clear where this is going now; multiply both sides by sin\frac{m\pi x}{L} and integrate between -L and L. Using a very similar reasoning to step 2, we’ll end up with:

\[b_n=\frac{1}{L}\int_{-L}^{L}f(x)sin\frac{n\pi x}{L}dx\]

We’ve just found a way to calculate all the coefficients of our Fourier series for :

\[f(x)=\frac{a_0}{2}+\sum_{n=1}^{\infty}\left(a_n cos\frac{n\pi x}{L}+b_n sin\frac{n\pi x}{L}\right)\]

Where:

\[\begin{aligned} a_0&=\frac{1}{L}\int_{-L}^{L}f(x)dx\\ a_n&=\frac{1}{L}\int_{-L}^{L}f(x)cos\frac{n\pi x}{L}dx\\ b_n&=\frac{1}{L}\int_{-L}^{L}f(x)sin\frac{n\pi x}{L}dx \end{aligned}\]

Conditions on f and convergence of Fourier series

The previous section discusses Fourier series for a function that is well-behaved - but what does that mean? The full answer would lead us deep into analysis, which I’d like to avoid here. So I’ll keep it brief.

We typically assume that is square integrable, which is denoted as L^2. Moreover, we assume that the function is piecewise smooth: each segment of the function has continuous derivatives. A very simple example of a piecewise smooth function is f(x)=|x|. Another is the triangular wave function used in the example below.

These conditions hold for pretty much any reasonable function we want to approximate using Fourier series, so they aren’t a serious burden.

For a function that satisfies these conditions, it’s guaranteed to have a Fourier series that pointwise converges to it. This means that at every continuous point of , the Fourier series converges to it exactly; at every jump point, the Fourier series converges to the mid-point of the jump.

Cosine and Sine series

Sometimes, additional properties of the function can help us simplify the Fourier series for it. If f_e(x) is an even function, then we know that:

\[b_n=\frac{1}{L}\int_{-L}^{L}f(x)sin\frac{n\pi x}{L}dx=0\]

Because the function inside the integral is odd, and integrating an odd function over a symmetric interval results in 0.

Therefore, the Fourier series for such f_e(x) is a cosine series:

\[f_e(x)=\frac{a_0}{2}+\sum_{n=1}^{\infty}a_n cos\frac{n\pi x}{L}\]

With coefficients and a_n given as before.

Similarly if f_o(x) is an odd function, then its and a_n are 0, and its Fourier series is a sine series:

\[f_o(x)=\sum_{n=1}^{\infty}b_n sin\frac{n\pi x}{L}\]

Fourier series for a non-periodic function defined on an interval

So far we’ve been talking about 2L-periodic functions that can be faithfully represented by Fourier series. But what if we have a non-periodic function defined on a finite interval?

E.g. suppose we have f(x)=x on the interval [0,L]. Can we approximate it with a Fourier series?

Yes! First, we have to make a choice of how to extend the function to the negative interval [-L,0]. Then, we simply repeat the function every 2L - this is called a periodic extension. Note that the Fourier series calculation only cares about the range [-L,L]. The resulting series will approximate the generated periodic function in its entirety, and in particular will also converge to it in the [0,L] interval (except maybe the endpoints, depending on the mode of extension).

There are several natural ways to extend a function defined on [0,L] into the interval [-L,0] [3]:

Direct periodic repetition: we simply repeat every L: f(x+L)=f(x)\ \forall x.
Even extension: f(|x|)
Odd extension: when x\ge 0 and -f(-x) when x<0.

Here’s an example of extending our sample function f(x)=x onto the full interval [-L,L] and then repeating it periodically every 2L:

Note that the Fourier series for these extended functions will be different. However, they will all converge to in the interval [0,L]. Typically, even and odd extensions have the benefit of producing either cosine or sine series, correspondingly (as discussed in the previous section).

We’ve seen that Fourier series work well for periodic functions and also non-periodic functions defined on a finite domain (because we can extend these periodically). But what about aperiodic functions defined on the entire real line? This is where we’ll have to leave Fourier series behind and move on to their generalization - the Fourier transform; this will be a topic for a separate post.

Example

Let’s take the following triangular function t(x) [4]:

t(x) is periodic with period 4. We can define it by starting with a formula on the interval [0,2]:

\[t(x)= \begin{cases} x & 0 \leq x \leq 1 \\ 2-x & 1 < x \leq 2 \\ \end{cases}\]

Then making an odd extension into [-2,0] and repeating it periodically. Now we can go ahead to calculate its Fourier coefficients.

Since this function is odd, we know that we’ll get a sine series, as a_n are going to be 0 for all . Let’s calculate b_n; in our case L=2 (half the period).

\[b_n=\frac{1}{2}\int_{-2}^{2}t(x)sin\frac{n\pi x}{2}dx\]

Since t(x) is odd and so is the sine, we’re integrating an even function over a symmetric interval. Therefore, we only have to integrate on the positive half of the range and multiply the result by two:

\[b_n=\int_{0}^{2}t(x)sin\frac{n\pi x}{2}dx\]

Let’s set k=\frac{n\pi}{2}:

\[b_n=\int_{0}^{2}t(x)sin(kx)dx\]

And split up the integral for the different segments of t(x):

\[b_n=\int_{0}^{1}x\cdot sin(kx)dx+\int_{1}^{2}(2-x)sin(kx)dx\]

The first integral, by the method described in Appendix C:

\[I_1=\int_{0}^{1}x\cdot sin(kx)dx=\bigg[\frac{-x cos(kx)}{k}+\frac{sin(kx)}{k^2} \bigg]_{0}^{1}=\frac{sin(k)}{k^2}-\frac{cos(k)}{k}\]

The second integral can also be split into two:

\[I_2=\int_{1}^{2}2sin(kx)dx - \int_{1}^{2}x\cdot sin(kx)dx\]

The first of these is trivial to calculate; the second can once again use Appendix C. After some tedious but straightforward calculations [5] we’ll get:

\[I_2=\frac{cos(k)}{k}+\frac{sin(k)-sin(2k)}{k^2}\]

Adding I_1+I_2, we get:

\[\begin{aligned} b_n=I_1+I_2&=\frac{sin(k)}{k^2}-\frac{cos(k)}{k}+\frac{cos(k)}{k}+\frac{sin(k)-sin(2k)}{k^2}\\ &=\frac{2sin(k)-sin(2k)}{k^2} \end{aligned}\]

Now let’s substitute k=\frac{n\pi}{2} back. This makes sin(2k) zero because the sine of an integer multiple of \pi is always zero:

\[b_n=\frac{2sin \frac{n\pi}{2}}{\left (\frac{n\pi}{2}\right )^2}=\frac{8sin \frac{n\pi}{2}}{n^2\pi^2}\]

We have b_n, so the Fourier series for our t(x) is:

\[t(x)=\sum_{n=1}^{\infty}\frac{8}{n^2\pi^2}sin\frac{n\pi}{2}sin\frac{n\pi x}{2}\]

Note that for even values of , sin \frac{n\pi}{2} is zero, so only the odd terms remain:

\[t(x)=\frac{8}{\pi^2}\bigg[ sin\frac{\pi x}{2}-\frac{1}{3^2} sin\frac{3\pi x}{2}+\frac{1}{5^2}sin\frac{5\pi x}{2}-\cdots\bigg]\]

Here’s an interactive chart showing how the series t(x) converges to our triangular function. You can set the number of terms in the Fourier series and see the effect (red line). Note that all even coefficients are zero so it will look the same for as for n-1 when is odd.

n (terms in the Fourier series)

Compact formula using a single phase-shifted sinusoid

We’ve written the Fourier series for as follows so far:

\[f(x)=\frac{a_0}{2}+\sum_{n=1}^{\infty}\left(a_n cos\frac{n\pi x}{L}+b_n sin\frac{n\pi x}{L}\right)\]

We can rewrite this in a somewhat more compact form, using a single sinusoid with a configurable phase at each :

\[f(x)=\frac{a_0}{2}+\sum_{n=1}^{\infty}q_n\cdot cos\left(\frac{n\pi x}{L}+\theta_n\right)\]

Based on Appendix D, q_n and \theta_n can be computed as follows:

\[\begin{aligned} q_n&=\sqrt{a_n^2+b_n^2}\\ \theta_n&=\operatorname{atan2}(-b_n,a_n) \end{aligned}\]

When Fourier series are used in the context of signal processing, this formulation is easier to reason about because it represents the magnitude and phase shift of each harmonic of in the frequency domain [6]

Complex Fourier series

It should not come as a surprise that the Fourier series, being a combination of trigonometric functions, can also be represented with complex exponential functions.

Specifically, we’ll show that our can be approximated as follows:

\[f(x)=\sum_{n=-\infty}^{\infty}C_n\cdot e^{in\pi x/L}\]

Let’s calculate C_n. We proceed in a manner similar to before, by multiplying both sides of the equation by e^{-im\pi x/L} and taking an integral in the range [-L,L]:

\[\begin{aligned} \int_{-L}^{L}f(x)e^{-im\pi x/L}dx&=\sum_{n=-\infty}^{\infty}\int_{-L}^{L}C_n\cdot e^{in\pi x/L}e^{-im\pi x/L}dx\\ &=\sum_{n=-\infty}^{\infty}\int_{-L}^{L}C_n\cdot e^{i(n-m)\pi x/L}dx \end{aligned}\]

By Appendix A, the sum elements are all zero when n\neq m. When n=m, we get:

\[\int_{-L}^{L}f(x)e^{-im\pi x/L}dx=\int_{-L}^{L}C_m\cdot 1 \cdot dx=2LC_m\]

Therefore, renaming m to (since it’s just an arbitrary integer constant):

\[C_n=\frac{1}{2L}\int_{-L}^{L}f(x)e^{-in\pi x/L}dx\]

We’ve found an alternative formulation to Fourier series, using complex exponentials instead of trigonometric functions. While this was a direct derivation, another way to achieve the same result is to use the Euler Formula to derive:

\[\begin{aligned} cos\theta&=\frac{e^{i\theta}+e^{-i\theta}}{2}\\ sin\theta&=\frac{e^{i\theta}-e^{-i\theta}}{2i} \end{aligned}\]

And substitute these into the original Fourier series formula. I’ll leave this as an exercise for the diligent reader; eventually, the result will be the same. Moreover, it’s possible to show a direct correspondence between a_n, b_n and C_n, for n>0:

\[\begin{aligned} C_0&=\frac{a_0}{2}\\ C_n&=\frac{a_n-ib_n}{2}\\ C_{-n}&=\frac{a_n+ib_n}{2}\\ \end{aligned}\]

Note that C_{-n}=C_n^* when both a_n and b_n are real (which is the case for a real-valued ). This helps explain why the complex formulation has negative frequencies in the sum; when the function is actually real, each negative frequency is paired up with a positive frequency and the result is real [7]:

\[\begin{aligned} C_n e^{in\pi x/L}+C_{-n} e^{-in\pi x/L}&=C_n e^{in\pi x/L}+C_n^* e^{-in\pi x/L}\\ &=C_n e^{in\pi x/L}+\left(C_{n} e^{in\pi x/L}\right)^*\\ &=2\operatorname{Re}\bigg(C_{n} e^{in\pi x/L}\bigg) \end{aligned}\]

So, for a real function we only need to account for positive frequencies:

\[f(x)=C_0+\sum_{n=1}^{\infty}2\operatorname{Re}\bigg(C_{n} e^{in\pi x/L}\bigg)\]

We can take it further. C_n is a complex number, so let’s represent it in polar form as C_n=\frac{q_n}{2} e^{i\theta_n} (the factor of half will make sense soon). Then:

\[\begin{aligned} \operatorname{Re}\bigg(C_{n} e^{in\pi x/L}\bigg)&=\operatorname{Re}\bigg(\frac{q_n}{2} e^{i\theta_n}e^{in\pi x/L}\bigg)\\ &=\frac{q_n}{2}\operatorname{Re}\bigg(e^{i(n\pi x/L + \theta_n)}\bigg)\\ &=\frac{q_n}{2} cos\bigg(\frac{n\pi x}{L}+\theta_n\bigg) \end{aligned}\]

And substituting back into the sum:

\[f(x)=C_0+\sum_{n=1}^{\infty}q_n cos\bigg(\frac{n\pi x}{L}+\theta_n\bigg)\]

This is precisely the compact formulation from the previous section!

Fourier orthogonal basis in Hilbert space

The most beautiful aspect of Fourier theory is that it doesn’t just happen to work by chance, and is deeply connected to linear algebra. Please read my post on Hilbert space before proceeding.

The space of real-valued square integrable functions L^2 forms a Hilbert space, in which we can define the inner product (assuming real functions):

\[\langle f,g \rangle=\int_{-L}^{L}f(x)g(x) dx\]

We’ve demonstrated that the family of functions:

\[1,\qquad cos\frac{n\pi x}{L},\qquad sin\frac{n\pi x}{L}\]

Are all mutually orthogonal, because their pairwise inner products are zero! We’ve also shown that any function in L^2 can be represented as a weighted sum of these functions:

\[f(x)=\frac{a_0}{2}+\sum_{n=1}^{\infty}\left(a_n cos\frac{n\pi x}{L}+b_n sin\frac{n\pi x}{L}\right)\]

So these functions form a basis for L^2. When we think of these functions as vectors (in an infinite Hilbert space), much of what we did in this post starts feeling like "normal" linear algebra. For example, when we have a set of basis vectors and we want to know how to represent some vector in this basis, we usually find the coefficients by projecting it onto the basis. E.g. with a basis vector e_1, the coefficient of :

\[c=\frac{\langle v, e_1\rangle}{\langle e_1, e_1\rangle}\]

Similarly, when we calculate the coefficient b_n for some function , we project onto the basis vector sin\frac{n\pi x}{L} by calculating:

\[b_n=\frac{\langle f(x), sin\frac{n\pi x}{L}\rangle}{\langle sin\frac{n\pi x}{L}, sin\frac{n\pi x}{L}\rangle}\]

From Appendix B, we know that the denominator is L, and we’ve just denoted:

\[\langle f(x), sin\frac{n\pi x}{L}\rangle=\int_{-L}^{L}f(x)sin\frac{n\pi x}{L}dx\]

So we get:

\[b_n=\frac{1}{L}\int_{-L}^{L}f(x)sin\frac{n\pi x}{L}dx\]

Which should look familiar!

This is the core linear-algebra idea behind Fourier series: the functions 1, cos\frac{n\pi x}{L}, and sin\frac{n\pi x}{L} play the role of orthogonal basis vectors, while the Fourier coefficients are coordinates of in this basis. The integral formulas for a_n and b_n are not mysterious tricks; they are projections, just like dot products with basis vectors in ordinary Euclidean space.

Fourier series therefore let us decompose a function into independent orthogonal directions, much like decomposing a vector into its , , and z components.

Appendix A: Integrals of sinusoids

For any integer n\neq 0 and an arbitrary constant L, we have:

\[\begin{aligned} \int_{-L}^{L}cos\frac{n\pi x}{L}dx&=\bigg[\frac{L}{n\pi}sin\frac{n\pi x}{L}\bigg]_{-L}^{L}\\ &=\frac{L}{n\pi}(sin(n\pi)-sin(-n\pi))=0 \end{aligned}\]

Similarly:

\[\begin{aligned} \int_{-L}^{L}sin\frac{n\pi x}{L}dx&=\bigg[\frac{-L}{n\pi}cos\frac{n\pi x}{L}\bigg]_{-L}^{L}\\ &=\frac{-L}{n\pi}\left(cos(n\pi)-cos(-n\pi)\right)=0 \end{aligned}\]

Using these, we can calculate the integral of a complex exponential function for an integer n\neq 0:

\[\begin{aligned} \int_{-L}^{L}e^{in\pi x/L}dx=\int_{-L}^{L}\bigg[ cos\frac{n\pi x}{L} +i\cdot sin\frac{n\pi x}{L}\bigg] dx=0 \end{aligned}\]

Appendix B: Integrals of products of sinusoids

We’ll start with the product of two sines, for any positive integers m and :

\[ss=\int_{-L}^{L}sin\frac{m\pi x}{L}\cdot sin\frac{n\pi x}{L}dx\]

Using the trigonometric identity for a product of sines, we can write:

\[\begin{aligned} ss&=\frac{1}{2}\int_{-L}^{L}\bigg(cos\frac{(m-n)\pi x}{L}-cos\frac{(m+n)\pi x}{L}\bigg)dx\\ &=\frac{1}{2}\int_{-L}^{L}cos\frac{(m-n)\pi x}{L}dx-\frac{1}{2}\int_{-L}^{L}cos\frac{(m+n)\pi x}{L}dx \end{aligned}\]

Now let’s focus on two different scenarios, m\neq n and m=n.

If m\neq n, then each of the integrals constituting ss are 0 (see on Appendix A), so ss=0.

If m=n, then the second integral is still 0, but the first one isn’t:

\[\begin{aligned} ss&=\frac{1}{2}\int_{-L}^{L}cos\frac{0\pi x}{L}dx\\ &=\frac{1}{2}\int_{-L}^{L}1dx=L \end{aligned}\]

Therefore:

\[ss=\int_{-L}^{L}sin\frac{m\pi x}{L}\cdot sin\frac{n\pi x}{L}dx= \begin{cases} L & m = n \\ 0 & m \neq n \end{cases}\]

We can use exactly the same approach to show that:

\[cc=\int_{-L}^{L}cos\frac{m\pi x}{L}\cdot cos\frac{n\pi x}{L}dx= \begin{cases} L & m = n \\ 0 & m \neq n \end{cases}\]

One more variant to cover:

\[sc=\int_{-L}^{L}sin\frac{m\pi x}{L}\cdot cos\frac{n\pi x}{L}dx\]

Since sine is an odd function and cosine is an even function, their product is an odd function. And the integral of an odd function over a symmetric interval is 0 (see this post for more details).

Therefore:

\[sc=\int_{-L}^{L}sin\frac{m\pi x}{L}\cdot cos\frac{n\pi x}{L}dx=0\]

Appendix C: A useful integral

Let’s calculate the indefinite integral:

\[I=\int x\cdot sin(kx) dx\]

For some constant k. We’ll use integration by parts:

\[\int u\cdot dv =u\cdot v - \int v\cdot du\]

Here u=x, so du=dx. Also dv=sin(kx), so v=-\frac{cos(kx)}{k}.

Putting it together:

\[I=\frac{-x\cdot cos(kx)}{k}+\int \frac{cos(kx)}{k} dx=\frac{-x\cdot cos(kx)}{k}+\frac{sin(kx)}{k^2}\]

Appendix D: Sinusoid with phase as a sum of sin and cos

Let’s take a general sinusoid with magnitude q, frequency and phase :

\[s(x)=q\cdot cos(wx+\theta)\]

We’re going to show that s(x) can be represented as a sum of a sine and a cosine with no phase. This is related to my earlier post on the sum of same-frequency sinusoids.

Let’s start by expanding s(x) using a trigonometric identity:

\[s(x)=q\cdot cos(\theta)cos(wx)-q\cdot sin(\theta)sin(wx)\]

Now we’ll denote: a=q\cdot cos(\theta) and b=-q\cdot sin(\theta), so:

\[s(x)=a\cdot cos(wx)+b\cdot sin(wx)\]

We have a and b in terms of q and , but what about the other way around?

Let’s take the equations:

\[\begin{aligned} a&=q\cdot cos(\theta)\\ b&=-q\cdot sin(\theta) \end{aligned}\]

Square both of them and add together:

\[\begin{aligned} a^2+b^2&=q^2\cdot(cos^2(\theta)+sin^2(\theta))=q^2\\ &\Rightarrow q=\sqrt{a^2+b^2} \end{aligned}\]

Now we’ll take the equations for b and a and divide one by the other:

\[\begin{aligned} \frac{b}{a}&=\frac{-sin(\theta)}{cos(\theta)}\\ &\Rightarrow\theta=\operatorname{atan2}(-b,a) \end{aligned}\]

Where the atan2 function is careful to take into account the sign of both numerator and denominator. Also it’s worth mentioning that is determined up to additions of 2\pi.

To conclude, for any q, and :

\[q\cdot cos(wx+\theta)=a\cdot cos(wx)+b\cdot sin(wx)\]

With the aforementioned conversion formulas for a, b.

[1]	A function is called periodic if there exists some constant P>0 such that f(x+P)=f(x)\ \forall x. In our case, we denote the period as P=2L to make presentation and calculations neater.

[2]	Since f(x)\in L^2, we know that it’s integrable on a finite interval

[3]	There’s also an infinite number of less natural ways to extend the function; they will still work, but may make the calculation needlessly complicated

[4]	I chose this one because the more common ones like a square wave and a sawtooth wave have many derivations available online, including on Wikipedia.

[5]	Try it for yourself - it’s a good exercise.

[6]	When q_n=0 for some , the corresponding \theta_n can be chosen arbitrarily.

[7]	For a complex-valued , this conjugate symmetry no longer holds in general. a_n and b_n may be complex, so C_n and C_{-n} need not be conjugates.

Scaling, stretching and shifting sinusoids

2026-05-02T07:17:00-07:00

This is a brief and simple [1] explanation of how to adjust the standard sinusoid sin(x) to change its amplitude, frequency and phase shift. More precisely, given the general function:

\[s(x)=A\cdot sin(w\cdot x+\theta)\]

We’ll see how adjusting the parameters , and affect the shape of s(x). Each section below covers one of these aspects mathematically, and you can use the demo at the bottom to experiment with the topic visually.

Scaling

Scaling is conceptually the simplest change; we adjust to increase or decrease the amplitude (maximal height) of s(x). Setting A=2 will make the value twice as large (in both the positive and negative direction) as the original function.

Stretching

Stretching changes the frequency of sin(x), which is inverse proportional to its period. The baseline function sin(x) has a period of 2\pi, meaning it repeats every 2\pi. In other words, sin(x)=sin(x+2\pi) for any .

If we set w=2, we get sin(2x). This function repeats itself twice as fast as sin(x), because is multiplied by 2 before being fed into the sinusoid. If changes by \pi, the sinusoid’s input changes by 2\pi. Therefore, the period of sin(2x) is \pi, the period of sin(4x) is \frac{\pi}{2} and so on. [2]

More generally, the period of sin(wx) is \frac{2\pi}{w}. Play with the demo below to see this in action, by changing and observing how the waveform changes.

If we know the period p we want, we can easily calculate the that gives us this period:

\[p=\frac{2\pi}{w} \implies w=\frac{2\pi}{p}\]

Shifting

The final parameter we discuss is ; it’s called the phase of the sinusoid. In the baseline sin(x), . The sinusoid is 0 at x=0, achieves its positive peak at x=\frac{\pi}{2}, crosses 0 again at x=\pi, negative peak at x=\frac{3\pi}{2} and returns to its original position at x=2\pi where the repetition begins.

By adding a non-zero , we don’t affect the sinusoid’s amplitude or frequency, but we do shift it right or left along the axis. For example, suppose we use the function sin(x+\theta) with \theta=\frac{\pi}{2}. Then when x=0, we have sin(\frac{\pi}{2}), so the sinusoid is already at its positive peak; at x=\frac{\pi}{2}, the sinusoid crosses 0 into the negatives, etc. Everything happens earlier (by exactly the value of \theta=\frac{\pi}{2}) than in the baseline sinusoid. In other words, we’ve shifted the function left by \frac{\pi}{2}. Similarly, when is negative, everything happens later, and the function is shifted right.

Putting it all together

We’ve now gone over all the parameters for the function:

\[s(x)=A\cdot sin(w\cdot x+\theta)\]

controls the scaling factor (amplitude).
is the frequency and controls the repetition period
controls the phase - how much the sinusoid is shifted left or right

Use the demo below to adjust these parameters and observe their effect on the sinusoid:

A ω θ

[1]	The math level of this post is high-school, at best. My main goal here is to test how to integrate interactive demos into my blog posts.

[2]

This can be a bit counter-intuitive at first; we scale by 2, but the period scales by half. Why? The reason is that affects the sinusoid’s domain, while the period is a property of its range. Therefore, an inverse relation is reasonable, once we put more thought into it. In fact, is often called the angular frequency of the sinusoid, and frequency is inverse proportional to the period.

Thoughts on WebAssembly as a stack machine

2026-04-29T19:28:00-07:00

This week the article Wasm is not quite a stack machine has been making the rounds and has caught my eye. The post claims that WASM is not a pure stack machine because it has locals and is missing some stack manipulation operations like dup and swap.

While I don't necessarily disagree, IMHO it's a bit of a semantic discussion because - to the best of my knowledge - there is no formal definition of what is a stack machine. Wikipedia, for example, says:

[...], a stack machine is a computer processor or a process virtual machine in which the primary interaction is moving short-lived temporary values to and from a push-down stack.

WASM certainly fits this definition; the primary interaction is through the stack, though WASM is augmented with an infinite register file (locals). The more purist stack machines like Forth are only limited to the stack and a memory (pointers into which are managed on the stack); WASM has these too, plus the registers.

Speaking of Forth, the mention of dup reminded me of my own impressions of programming in that language, documented in my post about implementing Forth in Go and C. There, I highlighted the following essential library function for Forth; it adds an addend to a value stored in memory.

: +!        ( addend addr -- )
  tuck      ( addr addend addr )
  @         ( addr addend value-at-addr )
  +         ( addr updated-value )
  swap      ( updated-value addr )
  ! ;

And lamented how difficult it is to understand such code without the detailed stack view in comments alongside it.

I find it much simpler to reason about this WASM code:

(func (export "add_to_byte") (param $addr i32) (param $delta i32)
    (i32.store8
        (local.get $addr)
        (i32.add
            (i32.load8_u (local.get $addr))
            (local.get $delta)))
)

You may say this is cheating because folded WASM instructions help readability and they're just syntactic sugar; OK, here's the linear code:

local.get $addr
local.get $addr
i32.load8_u
local.get $delta
i32.add
i32.store8

It's still very readable, because - while the stack is used for all the calculations and actual commands - some of the data lives in named "registers" instead of on the stack. So we don't need all those tuck-swap contortions to get things into the right order.

One might worry about the duplicated local.get $addr; wouldn't a real dup be better? Well, not in terms of readability, as we've already discussed. How about performance? Since the stack VM is just an abstraction and the underlying CPUs executing this code are register machines anyway, the answer is no - it doesn't matter at all.

Modern compiler engineers were forged in the fires of C and its descendants; arbitrary control flow, arbitrary register and memory access, anything goes. Compilers are quite sophisticated. Let's see how wasmtime compiles our add_to_byte to native code (using wasmtime explore with its default opt-level=2); comments are added by me:

// Prologue
push rbp
mov rbp, rsp

// wasmtime's VM context pointer lives in rdi; 0x38 is likely its offset
// to the default linear memory. Therefore, r10 will hold the base address
// of the linear memory buffer
mov r10, qword ptr [rdi + 0x38]

// The first parameter ($addr) is in edx; since WASM values are i32, it's
// zero-extended into the 64-bit r11 by copying into r11d
mov r11d, edx

// r10+r11 is memory[$addr]; this loads the current value into rsi
// (zero-extending from 8 bits)
movzx rsi, byte ptr [r10 + r11]

// ecx is the first parameter ($delta); this adds the addend to the
// current value
add esi, ecx

// Store cur_value+addend back into memory[$addr]
mov byte ptr [r10 + r11], sil

// Epilogue
mov rsp, rbp
pop rbp
ret

This is pretty much the code we'd expect to be emitted for the C statement mem[addr] += addend, or if we were writing x86-64 assembly by hand. The compiler had no difficulty figuring out that two consecutive loads from the same WASM local produce the same value and do not - in fact - have to be duplicated. The WASM model makes it rather easy, because you can't alias locals; as long as there are no intervening writes into the same local, multiple reads are known to produce the same value (redundant load elimination).

Debugging WASM in Chrome DevTools

2026-04-22T19:23:00-07:00

When I was working on the WASM backend for my Scheme compiler, I ran into several tricky situations with debugging generated WASM code. It turned out that Chrome has a very capable WASM debugger in its DevTools, so in this brief post I want to share how it can be used.

The setup and harness

I'll be using an example from my wasm-wat-samples project for this post. In fact, everything is already in place in the gc-print-scheme-pairs sample. This sample shows how to construct Scheme-like s-exprs in WASM using gc references and print them out recursively. The sample supports nested pairs of integers, booleans and symbols.

To see this in action, we have to first compile the WAT file to WASM, for example using watgo:

$ cd gc-print-scheme-pairs
$ watgo parse gc-print-scheme-pairs.wat -o gc-print-scheme-pairs.wasm

The browser-loader.html file in that directory already expects to load gc-print-scheme-pairs.wasm. But we can't just open it directly from the file-system; since it loads WASM, this file needs to be served with a local HTTP server. I personally use static-server for this, but you can use anything else - like Python's built-in http.server:

$ static-server
2026/04/10 08:55:20.244096 Serving directory "." on http://127.0.0.1:8080
...

Now it can be opened in the browser by following the printed link and selecting the browser-loader.html file.

The debugging process

Open the Chrome DevTools, and in Sources, open the Page view on the left. It should have one entry under wasm, which will show the decompiled WAT code for our module. Note: this code is disassembled from the binary WASM, so it will lose some WAT syntactic sugar (like folded instructions):

You can set a breakpoint by clicking on the address column to the left of the code, and then refresh the page. The DevTools debugger will run the program again and stop at the breakpoint:

Here you can step over, into, see local values and call stack, etc - a real debugger!

Debugging unexpected exceptions

The most important use case for me while developing the compiler was debugging unexpected exceptions (coming from instructions like ref.cast). Notice the checkboxes saying "Pause on ... exceptions" on the right-hand side of the previous screenshot. With these selected, the DevTools debugger will automatically stop on an exception and show where it is coming from. Let's modify the gc-print-scheme-pairs.wat sample to see this in action. The $emit_value function performs a set of ref.test checks to see which kind of reference it's dealing with before casting; let's add this line at the very start:

(call $emit_bool (ref.cast (ref $Bool) (local.get $v)))

It's clearly wrong to assume that $v is a bool reference without first testing it; this is just for demonstration purposes.

Without setting any breakpoints, recompiling this code with watgo and reloading the page, we get:

The debugger stopped at the instruction causing the exception; moreover, in the Scope pane on the right we can see that the actual type of $v is (ref $Pair), so it's immediately clear what's going on.

I've found this capability extremely valuable when writing (or emitting from a compiler) non-trivial chunks of WASM code using gc types and instructions.

Debugger vs. printfs in wasm

"Should I use a debugger or just printfs" is a common topic of debate among programmers. While I'm usually in the "printf debugging" camp, I'm not dogmatic, and will certainly reach for a debugger when the situation calls for it.

Specifically, when investigating reference exceptions in WASM, two strong factors tilt the decision towards using a debugger:

In general, WASM's printf capabilities aren't great. We can import print-like functions from the host (and - in fact - our sample does just that), but they're not very flexible and dealing with strings in WASM is painful in general. This is compounded even more when working with gc types, because these aren't even visible to the host (they're opaque references). If we want to do printf debugging of gc values, we have to build a lot of scaffolding first.
Exception debugging - in general - is much easier with a supportive debugger in hand. Our ref.cast exception from the example above could have happened anywhere in the code. Imagine having to debug a very large WASM program (emitted by a compiler) to find the source of a failed ref.cast; the debugger takes you right to the spot!

In fact, even for C programming, I've always found gdb most useful for pinpointing the source of segmentation faults and similar crashes.