Joel Holder

The Staircase and the Slide

2026-07-21T05:10:00+00:00

A staircase and a ramp can connect the same two floors. Stand at the bottom of each and they look like different ideas entirely — one moves in flat steps and sudden jumps, the other in one continuous rise. Digital and analog. Pixels and ink. A number line marked only at the integers, versus a number line with no gaps in it anywhere.

Discreteness counts. Continuity flows. They feel like two different worlds.

This post is about a place where those two worlds turn out to be the same picture, seen at two different resolutions. We won’t name where we’re headed just yet — better to let it arrive on its own.

Quick recap: the staircase we already built

Last time, we stacked blocks in rows — 1 block, then 2, then 3, and so on — and asked how many blocks were in the whole triangular stack.

Let’s fix the names we’ll reuse throughout this post:

$n$ is how many rows we stack — how far we count up to.
$T(n)$ is the total number of blocks once we’ve stacked all $n$ rows.

We found $T(n)$ by copying the stack, flipping the copy upside down, and fitting the two together into a plain rectangle:

The triangular numbers, one more time: a stack of blocks is exactly half of a rectangle.

A rectangle is easy: it’s just rows times columns, cut in half to undo the copy:

\[T(n) = \dfrac{n(n + 1)}{2}\]

That’s where we left off. Now we’re going to take that same staircase and start shrinking its steps.

A series is just a sum, one term at a time

Let’s slow down and name a couple of things carefully before we go further.

A sequence is nothing more than a list of numbers, in order: $1, 2, 3, 4, 5, \dots$ That’s it. No trick to it.

A series takes a sequence and starts adding its terms together, one at a time. If you stop after some number of terms, what you get is called a partial sum — the running total up to that point.

That’s exactly what $T(n)$ has been the whole time, we just didn’t use these words for it yet. $T(n)$ is the partial sum of the sequence of counting numbers, stopped after $n$ terms:

\[T(n) = 1 + 2 + 3 + \cdots + n\]

Nothing new has happened here. We’re only putting a name on something we’ve already been doing since the last post.

Watching the sum grow, one step at a time

Now let’s watch what happens to that running total as one more term joins it. Two concrete partial sums, side by side:

\[T(4) = 1+2+3+4 = 10 \qquad\qquad T(5) = 1+2+3+4+5 = 15\]

Compare them:

\[T(5) - T(4) = 15 - 10 = 5\]

That’s not a coincidence, and it’s not special to 4 and 5. $T(5)$ is just $T(4)$ with one new term tacked on — the term $5$ itself. Of course the difference is $5$. In general, going from $n-1$ terms to $n$ terms adds exactly one new term, and that new term is $n$:

\[T(n) - T(n-1) = n\]

Hang on to that. Every time $n$ goes up by one, $T(n)$ goes up by exactly $n$.

Difference quotients, and a staircase where h = 1

We just found something true specifically about $T$: it grows by exactly $n$ every time $n$ increases by 1. Before we go further, it’s worth learning the general version of what we just did — the version that works for any function, not just $T$ — because we’re about to reuse it on shapes and areas, too.

Here’s the general setup, with no staircase in it yet. Take any function $f$. Pick some input to start from, and call it $a$ — just a placeholder name for “wherever we happen to be starting.” Now take a step: move the input away from $a$ by some amount, and call the size of that step $h$. Moving the input by $h$ takes us from $a$ to $a+h$, and the function’s output moves too — from $f(a)$ to $f(a+h)$.

Two new letters, both doing simple jobs: $a$ names the starting point, and $h$ names how big a step we took away from it. Neither one is tied to any particular function or number yet — they’re placeholders that work the same way no matter what $f$ happens to be.

With that fully in view, here’s the definition. The quantity

\[\dfrac{f(a+h) - f(a)}{h}\]

is called a difference quotient. Read the pieces separately: $f(a+h)$ is the function’s value after the step, $f(a)$ is its value before the step, so $f(a+h) - f(a)$ is how much $f$ changed. Dividing by $h$ turns that change into a rate — change per unit of input, over a step of size $h$.

Now let’s connect this back to the staircase. Our function is $T$. A moment ago, we moved from $T(n-1)$ to $T(n)$ — in the language we just built, that’s starting point $a = n-1$, and step size $h = 1$, since the input moved from $n-1$ to $n$, a jump of exactly one unit. That’s the only step size we’ll use for most of this post: $h=1$, always, because we’re only ever moving from one whole number to the very next one. Later on, we’ll deliberately let $h$ shrink smaller than 1 — but not yet.

Apply the difference quotient to $T$, with $a = n-1$ and $h=1$:

\[\dfrac{T(n) - T(n-1)}{h} = \dfrac{T(n)-T(n-1)}{1} = T(n) - T(n-1)\]

Dividing by $h=1$ doesn’t change anything — so the difference quotient of $T$ is just the plain difference we already found by hand a moment ago: $n$. Rearranged, that’s the relationship we’ll lean on for the rest of this post:

\[T(n) = T(n-1) + n\]

The staircase is a rough sketch of a line

Picture the blocks again, but as bars: a bar of height 1, then height 2, then 3, up to height $n$. We just showed that each bar adds exactly the next counting number to the running total — a difference quotient of $n$, with $h=1$.

That “$+n$” is worth sitting with. The bars aren’t growing by some rule bolted on from outside. They grow by exactly the next whole number, because whole numbers are spaced exactly 1 apart. The staircase has no choice but to look like this — it’s the number line, stood up in blocks.

Now draw the line $y = x$ underneath the bars.

Each bar overshoots the line by a small triangular sliver — always the same size.

The bars hug that line closely, but not perfectly. Each bar sits a little taller than the line beneath it, everywhere except at its top-right corner, where the two touch.

The gap between a bar’s flat top and the line rising underneath it is a little right triangle. Every one of those triangles has legs of length 1 — the width of a bar, and the amount the line climbs across that width. Legs of 1 and 1 mean area $\dfrac{1}{2}$, every time, no matter how tall the bar is.

Where the line was hiding

So the staircase is really two things stacked together: the region under the line, plus $n$ identical leftover slivers of area $\dfrac{1}{2}$.

Why talk about area at all, though? Last time, we counted blocks by stacking them, and since each block has area 1, counting blocks was computing area, in block-units. Nothing about that has changed. Each bar has width $h$, and right now $h=1$, so a bar of height $k$ still covers exactly $k$ square units — the same $k$ we were always adding. Summing bar areas is just another way of writing $T(n)$. It always was.

Let’s find those two areas, step by step, without skipping anything.

The region under the line. It’s a right triangle with base $n$ and height $n$, since the line runs from $(0,0)$ to $(n,n)$.

The rectangle around it

$n \times n = n^2$

The triangle is half that rectangle

$\dfrac{n^2}{2}$

Same halving move as the two-triangles-make-a-rectangle picture from last time — just applied to a slope instead of a stack of blocks.

The leftover slivers. Each one is a right triangle whose legs both equal $h$, and $h=1$ here.

One sliver’s legs

$h = 1, \quad h = 1$

One sliver’s area

$\dfrac{h \times h}{2} = \dfrac{1 \times 1}{2} = \dfrac{1}{2}$

All $n$ slivers together

$n \times \dfrac{1}{2} = \dfrac{n}{2}$

Now watch what happens when we split the formula we already had:

Start from what we proved last time

$T(n) = \dfrac{n(n+1)}{2}$

Expand the numerator

$T(n) = \dfrac{n^2 + n}{2}$

Split the fraction

$T(n) = \dfrac{n^2}{2} + \dfrac{n}{2}$

That split isn’t a trick of algebra. It’s the picture, in symbols. $\dfrac{n^2}{2}$ is the smooth triangle under the line — the one we just found by halving a rectangle. $\dfrac{n}{2}$ is the pile of leftover slivers — the one we just found by adding up $n$ little half-square triangles. Same two areas, twice now: once from the picture, once from the algebra.

Let’s slow down and check that against actual numbers — the same five bars pictured above, where $n = 5$.

First, the formula from last time, plugged in directly:

\[T(5) = \dfrac{5 \cdot 6}{2} = \dfrac{30}{2} = 15\]

Now split that 15 the same way we just split $T(n)$ in general:

\[T(5) = \dfrac{5^2}{2} + \dfrac{5}{2} = \dfrac{25}{2} + \dfrac{5}{2} = 12.5 + 2.5\]

$12.5$ is the smooth triangle — five columns wide, five tall, cut in half. $2.5$ is the five little slivers, $\dfrac{1}{2}$ each, one riding on top of every bar. Add the two pieces back together and we’re at 15 again, exactly where we started:

\[12.5 + 2.5 = 15\]

Shrinking the grain

Natural next question: what if the steps were narrower?

Use bars of width $h$ instead of width 1 — a half, a quarter, anything smaller. Rebuild the same staircase over the same line, out of finer steps.

Each sliver is still a little right triangle between a flat step and the rising line. But now both legs have length $h$, so each sliver has area $\dfrac{h^2}{2}$. There are $\dfrac{n}{h}$ of them needed to reach all the way to $n$:

\[\text{leftover} = \dfrac{n}{h} \cdot \dfrac{h^2}{2} = \dfrac{nh}{2}\]

When $h = 1$, that’s our familiar $\dfrac{n}{2}$. When $h = \dfrac{1}{2}$, the leftover is exactly half that. Halve $h$ again, and it halves again.

Narrower steps, same line, a leftover that shrinks in exact proportion to the step size.

The staircase never jumps to being the line. It just hugs it more closely, and the leftover shrinks in lock step with the width of the steps. Shrink the grain by half, the leftover shrinks by half. Nothing surprising happens along the way — it just keeps going.

Zooming in on one corner

Let’s watch this happen up close. Instead of the whole staircase, zoom in on just one unit of it — the square from $x=0$ to $x=1$ — and keep refining the steps inside that same little window.

Same square, same line, four times finer each panel. The amber sliver never disappears — it just gets thinner than we can see.

By the last panel, the staircase looks like a straight line. It isn’t one. Zoom the image itself in far enough on that last panel and you’d still find flat treads and square corners — 64 of them, packed into one unit. No amount of shrinking $h$ ever turns a staircase into an actual, corner-free line. It’s always built from flat steps and right angles, at every size.

So here’s a precise way to say what is true: the staircase itself never becomes smooth. What shrinks to nothing is the gap between the staircase and the line — the amber sliver. And once that gap is gone completely, in the limit, what’s left standing is smooth — not because the staircase gradually earned smoothness, step by step, but because smoothness was a property of the line all along, and the last trace of the staircase’s roughness has been squeezed out from around it.

It’s a bit like a photo made of large, visible pixels. Refine the resolution, and the pixels don’t personally get rounder or softer — they just get smaller, and smaller, until you can no longer tell they’re there. The photograph you’re approximating was smooth the entire time. The blockiness was never a rival to that smoothness. It was just the resolution you happened to be looking at it with.

What’s left when the grain is gone

Let’s name what we’ve actually been computing, because the notation is about to change and it should change for a reason we can see.

Every bar’s area is height times width: $k \cdot h$. Adding up all of those bar areas is a sum:

\[\text{staircase area} = \sum_{k=1}^{n/h} (kh)\cdot h\]

A sum of thin rectangle areas like this, approximating the area under a line, has a name: a Riemann sum. It’s the exact thing we’ve been computing this whole time — we just didn’t have the word for it yet. $T(n)$ itself is a Riemann sum, the special case where $h=1$.

We already know what this particular sum equals, because we found it by hand with the sliver picture:

\[\text{staircase area} = \dfrac{n^2}{2} + \dfrac{nh}{2}\]

Now send $h$ toward 0. Nothing about the sum stops being a sum — it just ends up with more and more terms, each one thinner than the last. Take the limit of both sides:

\[\lim_{h \to 0} \left( \dfrac{n^2}{2} + \dfrac{nh}{2} \right) = \dfrac{n^2}{2}\]

since we already showed $\dfrac{nh}{2} \to 0$. That limiting value — the one left standing once the grain is gone — has its own name too: the definite integral of $f(x) = x$, from 0 to $n$:

\[\int_0^n x\,dx = \dfrac{n^2}{2}\]

The notation isn’t a coincidence. $\sum$ is the Greek letter sigma, for sum. $\int$ is a stretched-out $S$ — Leibniz’s own shorthand for summa, Latin for sum. Both symbols mean the same word. The only difference is what’s being summed: $\sum$ adds up finitely many rectangles of a fixed width $h$; $\int$ is what’s left in the limit, once that width has shrunk to 0. That’s exactly what “$dx$” means, too — it isn’t a new, mysterious infinitesimal object. It’s just the name calculus gives to $h$, once $h$ has been sent to its limit. Same quantity, different alphabet.

So summation and integration were never two separate operations that happen to look alike. $\int$ is $\sum$, at the exact moment its rectangles become infinitely thin. Every triangular number we’ve ever computed was a Riemann sum — one with a step size fixed at exactly 1, instead of a step size carried all the way to the limit.

Let’s slow down and look at two concrete examples, side by side, so this isn’t just a claim — we can watch it happen with real numbers.

First, $n=5$ — the case we’ve been picturing the whole time. The sum is one we already know by heart:

\[\sum_{k=1}^{5} k = 1+2+3+4+5 = 15\]

And we’ve already found the integral, too, even though we didn’t call it that yet. Back when we split $T(5)$ into its two pieces, the $12.5$ we found was this integral all along:

\[\int_0^5 x\,dx = \dfrac{5^2}{2} = 12.5\]

Subtract the integral from the sum:

\[15 - 12.5 = 2.5\]

That $2.5$ is exactly $\dfrac{n}{2}$ for $n=5$ — the same leftover we’ve been tracking this entire post.

Now let’s check a different $n$, so we’re sure this wasn’t a coincidence. Take $n=10$. The sum:

\[\sum_{k=1}^{10} k = 1+2+\cdots+10 = 55\]

The integral:

\[\int_0^{10} x\,dx = \dfrac{10^2}{2} = 50\]

Subtract again:

\[55 - 50 = 5\]

And $5$ is exactly $\dfrac{n}{2}$ for $n=10$. Different $n$, same relationship, right on schedule.

Both times, the sum comes out a little bigger than the integral — by exactly $\dfrac{n}{2}$, never more, never less. The sum was never wrong. It’s the integral, plus one small and completely predictable extra piece, owed entirely to the fact that we counted in whole steps of $h=1$ instead of sweeping continuously.

And now we can finally answer the question from earlier properly. Is the “$1$” in $\dfrac{n(n+1)}{2}$ there because the counting numbers are one apart? Yes — and now we know exactly how much of the answer that fact is responsible for. It contributes precisely $\dfrac{n}{2}$, and that whole term is the fossil of a step size of 1. Shrink the step, and the fossil shrinks with it, right on schedule, until nothing is left of it at all.

Zero was never a destination

It’s tempting to describe all this as “shrinking $h$ until it becomes infinitesimal” — some final, smallest possible step, just barely above zero.

But there’s no such thing to land on. However small a step you pick, half of it is smaller still, and just as valid a step. There is no smallest positive number waiting at the bottom of that halving process.

So what is actually being approached? Zero itself. And zero, we already established, isn’t a quantity at all. It’s the additive identity — the point on the line with no parts left to subdivide.

That’s exactly why it makes a safe target for this kind of shrinking. $h$ never has to arrive at some smallest surviving crumb of size, because it was never heading toward a quantity in the first place. It’s heading toward the one point that was never a quantity to begin with. The grain doesn’t bottom out — it just keeps finding room to get closer to a target with no size for it to bump into.

The tolerance game

So mathematicians don’t ask “how small can $h$ get?” They ask a sharper question instead: can the leftover be forced below any tolerance you name, no matter how demanding?

Name a tolerance — call it $\varepsilon$. It can be as stingy as you like: a thousandth, a trillionth, anything positive. We need $\dfrac{nh}{2}$ to come in under it. Solve for $h$:

\[\dfrac{nh}{2} < \varepsilon \quad\Longleftrightarrow\quad h < \dfrac{2\varepsilon}{n}\]

For any $\varepsilon > 0$, choosing $h$ smaller than $\dfrac{2\varepsilon}{n}$ guarantees the leftover is smaller than $\varepsilon$. Whatever tolerance gets demanded, a step size exists that satisfies it.

That, in full, is the epsilon-delta idea. Not a smallest number — a guarantee that closeness can be forced past any bar you set, on demand, forever. It replaces “there exists an infinitesimal” with something needing no controversial number at all: “for every tolerance, a response exists.” The bars in our figures were an $\varepsilon$–$\delta$ argument, drawn in color before it was ever written in symbols.

The slide was always there

We started by asking what happens when a staircase shrinks down to nothing. The honest answer: the staircase was never the fundamental object. The slide was.

The smooth line $y=x$ and its triangular area $\dfrac{n^2}{2}$ were there from the start. The staircase was just a particular, coarse way of measuring that same area — one unit-wide sliver of overcounting at a time. Discreteness wasn’t a rival to continuity. It was a grain laid on top of it, precise enough to name exactly ($\dfrac{nh}{2}$), and finable down to nothing.

It’s the same reason a square’s growth and a triangle’s growth turn out to be relatives, not coincidences: $n^2$ is the sum of the first $n$ odd numbers, and $T(n-1) + T(n) = n^2$ splits that same square straight down its diagonal into two staircases. Every one of these formulas is a continuous curve, caught mid-pixelation, still recognizably itself underneath the grain.

The two triangles that made a rectangle, back at the start of all this, and the triangle under a line, at the end of it, are the same shape, doing the same job, at two different resolutions.

Looking Deeper at the Meaning of Zero

2026-07-19T19:00:00+00:00

Every number is defined by where it sits in the continuum relative to one fixed point. That point is zero. It can be thought of the beginning of addition.

Zero is the Unit of addition, giving us back the identity of a thing when we add zero to that thing.

It turns out to have two descriptions that are really the same fact:

Algebra - the operation that changes nothing

Geometry - that which has no parts

Zero cannot be subdivided. It cannot be scaled. It cannot be denominated.

The additive identity: the operation that changes nothing

\[a + 0 = a\]

Adding $0$ never changes $a$. That’s the whole definition: $0$ isn’t a quantity. Adding it to a number does nothing. Every other number does something when added to $a$.

Zero = Euclid’s point: the geometric construct of nothingness

A point is that which has no part — no length, nothing to divide.

A segment can always be cut somewhere. Zero has no dimension to put a cut in.

The operational symmetry of $+a$ and $-a$

Think of $+a$ not as a number but as a move: take whatever you have, apply $+a$ to it. It has a mirror move, $-a$, defined by one property:

\[a + (-a) = 0\]

Apply $+a$, then $-a$. Or apply $-a$, then $+a$. Either order, the two moves compose into the do-nothing move. Neither one is “more basic” than the other — that’s the symmetry. Each is exactly what the other one requires to return you to identity, and that requirement is the entire definition of an inverse. Nothing physical about it; it’s a statement about how two operations compose.

Does the symmetry survive combining numbers?

Apply $+a$, then $+b$. Then $-a$, then $-b$. Does the whole chain still compose to the identity?

Yes — it is necessarily so, by two rules you already know and trust:

reorder freely (commutativity)
regroup freely (associativity)

\[\begin{aligned} (a+b) + (-a+-b) &= a + b + (-a) + (-b) &&\text{(associativity)} \\ &= a + (-a) + b + (-b) &&\text{(commutativity)} \\ &= \big(a + (-a)\big) + \big(b + (-b)\big) &&\text{(associativity)} \\ &= 0 + 0 = 0 \end{aligned}\]

$-a$ composing with $a$ to give $0$ isn’t a discovered fact about the world.

It’s what the words mean: an inverse is, by definition, the move that composes with the original move to produce the identity.

Remote C++ Development Over SSH: No GUI Required

2026-07-17T23:30:00+00:00

A full IDE running inside nothing but an SSH session. No GUI. No lag. No lock-in.

Config, MIT licensed: github.com/jclosure/vscode-flavored-emacs-2026

The case for terminal-only development

Here’s the thing nobody tells you: the IDE you’ve been dragging across the network — the file tree, the extension marketplace, the remote-desktop handshake — none of it was ever the point. The point was always completion, navigation, refactoring, and debugging. Everything else is just weight.

Strip it down to a terminal, an SSH connection, and Emacs, and you get all four, running natively on the machine that actually has your code, your compiler, your build. Zero latency between you and it, because there’s no picture being pushed across the wire — just keystrokes and text, the two things a network connection has always been good at.

This isn’t old tech because it’s outdated. It’s old tech because it’s proven, and it turns out the fastest, most portable interface between a human and a remote machine was never a rendered window. It was text. This just points that idea at a modern problem.

Simple

One program. One set of keybindings that works the same whether you’re on your laptop or SSH’d three hops deep into a box you don’t even own. No juggling a local editor, a remote-desktop client, and a file-sync tool at the same time. You open a terminal, type ssh, and you’re already inside your actual development environment — not a shadow of it, waiting to sync.

Powerful

This isn’t a stripped-down, “good enough for a text editor” version of a real IDE. Autocomplete knows your types. Errors surface as you type them. Jump-to-definition takes you into the real standard library source, not a stub. Rename a function and every call site updates, project-wide. Set a breakpoint, step through it, inspect a variable live — all inside the same terminal window you started in.

You could be on a train with spotty wifi, or SSH’d into a machine on the other side of the planet, and it behaves identically either way. That’s not a compromise you’re making. That’s the actual advantage.

You don’t need to already be an Emacs wizard

This isn’t a “prove yourself first” tool. It’s a config — pre-built, documented, and free to just clone and point at your own project. The IDE part works immediately. Whatever else you want to do with the forty years of Emacs sitting underneath it is entirely optional, and entirely up to you, whenever you’re ready for it.

Try it: github.com/jclosure/vscode-flavored-emacs-2026 — MIT licensed, no strings attached.

Gauss, Pascal, and Triangular Numbers

2026-07-13T04:06:00+00:00

Before we talk about formulas, start with a picture.

If we stack blocks in rows of 1, then 2, then 3, and keep going, we get a triangle. Let $n$ be the number we count up to. In the picture below, $n = 5$, so the triangle has 5 rows.

\[1 + 2 + 3 + 4 + 5\]

The running totals show how the count grows. The dot picture shows the same thing as rows of blocks:

Running totals

$1 = 1$

$1 + 2 = 3$

$1 + 2 + 3 = 6$

$1 + 2 + 3 + 4 = 10$

$1 + 2 + 3 + 4 + 5 = 15$

15 = running total

Dot picture

•

• •

• • •

• • • •

• • • • •

15 dots = area $T$

Let $T$ be the number of blocks in that triangle. Our goal is to find $T$ without counting every block one at a time.

Now make a copy of the same triangle, flip it, and put the two pieces together. The two triangles form a rectangle.

A triangular stack is half of a rectangle.

Each small block has area 1 block-unit. So counting blocks is the same as computing area in block-units.

For the example with $n = 5$, the calculation is:

Rectangle area

$5 \cdot 6 = 30$

Half the rectangle

$T = 30 / 2 = 15$

The picture suggests the general rule. If the triangle has $n$ rows, the doubled rectangle has $n$ rows and $n + 1$ columns. Its area is $n(n + 1)$ block-units. The triangle is half the rectangle, so:

\[T = \frac{n(n + 1)}{2}\]

But a picture is not quite a proof. It gives us the idea. Now we want to prove the idea with algebra.

That is where Gauss’s trick comes in.

Suppose we want to add the numbers from 1 to 100. Here $n = 100$, and $T$ is the total we are trying to find:

\[1 + 2 + 3 + \dots + 98 + 99 + 100\]

Gauss’s trick is to write the same total twice: once forward, and once backward.

\[\begin{array}{rrrrrrrr} T = & 1 & + 2 & + 3 & + \dots & + 98 & + 99 & + 100 \\ T = & 100 & + 99 & + 98 & + \dots & + 3 & + 2 & + 1 \end{array}\]

Now add the two rows together. Associativity lets us group the sum by columns: first with first, second with second, third with third, and so on.

Pair the columns

$2T = (1 + 100) + (2 + 99) + \dots + (100 + 1)$

Notice the repeated sum

$2T = 101 + 101 + \dots + 101$

Count the pairs

$2T = 100 \cdot 101$

Each column-pair adds to 101, and there are 100 pairs. This is the same idea as the block picture: 100 rows, 101 columns, and twice the triangle.

Since $2T$ is twice the original total, divide by 2:

\[T = \frac{100 \cdot 101}{2} = 5050\]

The important step is not the number 5050. The important step is the pairing.

The same proof works for any $n$. Write the total forward and backward:

\[\begin{array}{rrrrrr} T(n) = & 1 & + 2 & + 3 & + \dots & + n \\ T(n) = & n & + (n - 1) & + (n - 2) & + \dots & + 1 \end{array}\]

Then use associativity to group the columns into pairs:

Pair the columns

$2T(n) = (1 + n) + (2 + (n - 1)) + \dots + (n + 1)$

Notice the repeated sum

$2T(n) = (n + 1) + (n + 1) + \dots + (n + 1)$

Count the pairs

$2T(n) = n(n + 1)$

Every pair adds to $n + 1$, and there are $n$ pairs. Divide by 2 and we get:

\[T(n) = \frac{n(n + 1)}{2}\]

That proves the formula behind the rectangle picture. The algebra and the geometry are saying the same thing.

Now we can connect this to Pascal’s triangle.

Pascal’s triangle is built by addition. Every inside number is the sum of the two numbers above it:

\[\begin{array}{ccccccccccc} &&&&&1&&&&&\\ &&&&1&&1&&&&\\ &&&1&&2&&1&&&\\ &&1&&3&&3&&1&&\\ &1&&4&&6&&4&&1&\\ 1&&5&&10&&10&&5&&1 \end{array}\]

For example, the 6 is made from the two 3s above it:

\[\begin{array}{ccccc} & 3 && 3 &\\ & \searrow && \swarrow &\\ && 3 + 3 = 6 && \end{array}\]

The edge numbers stay 1. The inside numbers are where the adding happens.

The counting numbers appear along one diagonal:

\[1,\ 2,\ 3,\ 4,\ 5,\ \dots\]

The next diagonal keeps a running total of those counting numbers:

\[1,\quad 1 + 2,\quad 1 + 2 + 3,\quad 1 + 2 + 3 + 4,\quad \dots\]

That gives:

\[1,\ 3,\ 6,\ 10,\ 15,\ \dots\]

Those are the same triangular totals we just proved.

The triangular numbers appear as a diagonal in Pascal's triangle.

So the same idea appears in three forms:

\[1 + 2 + 3 + 4 + 5 + 6 + \dots + n = \frac{n(n + 1)}{2}\]

The block picture shows why the triangle is half of a rectangle. Gauss’s pairing turns that picture into a proof. Pascal’s triangle shows the same repeated addition hiding inside a larger pattern.

A Tiny Proof From First Principles

2026-07-11T05:43:00+00:00

One of the pleasures of pure math is how far you can travel with very small tools.

Before the symbols become intimidating, before the machinery becomes elaborate, there are laws so simple they almost disappear into common sense. Two of the most important are associativity and commutativity.

Commutativity says that order does not matter for addition:

\[x + y = y + x\]

Associativity says that grouping does not matter for addition:

\[(x + y) + z = x + (y + z)\]

These are tiny statements. But they give us permission to reorganize a sum without changing its value. That permission is powerful.

Consider this identity:

\[(a + b) + (c + d) = (a + d) + (b + c)\]

At first glance, the right side looks like a rearrangement by instinct. But a proof should not rely on instinct. It should show exactly which moves are allowed.

Starting on the left:

\[\begin{aligned} (a + b) + (c + d) &= a + \bigl(b + (c + d)\bigr) && \text{associativity} \\ &= a + \bigl((b + c) + d\bigr) && \text{associativity} \\ &= a + \bigl(d + (b + c)\bigr) && \text{commutativity} \\ &= (a + d) + (b + c) && \text{associativity} \end{aligned}\]

That is the whole proof.

The lovely thing is that nothing fancy happened. We did not calculate. We did not expand into a more complicated system. We simply used two first principles to move parentheses and reorder terms.

This is what makes proof feel different from arithmetic. Arithmetic often asks, “What is the answer?” Proof asks, “What transformations are legitimate?” Once the rules are clear, the path becomes visible.

In this small identity, associativity lets us change the shape of the expression. Commutativity lets us change the order. Together, they turn a rigid-looking formula into something flexible:

\[(a + b) + (c + d) \quad \longrightarrow \quad (a + d) + (b + c)\]

That flexibility is not a trick. It is structure. And much of mathematics is the art of noticing which structures give us freedom, then learning how to move beautifully inside them.

Automata Arcade Is Becoming an Instrument

2026-05-20T06:38:03+00:00

Automata Arcade now has selection transforms, lenses, zones, and manifold-mapped regions. The project is shifting from a cellular automata sandbox into a small workbench for building, inspecting, and reusing emergent systems.

Automata Arcade started as a simple cellular automata canvas: paint cells, run the simulation, watch the pattern evolve.

That loop is still there, but the tool now supports the operations needed for serious iteration: select, transform, inspect, isolate, map, and reuse.

Try it here: Automata Arcade live demo · GitHub repository

The board is editable

Selection mode turns a region of cells into an object you can operate on. You can draw a rectangular selection, translate it, rotate it 90 degrees, flip it, copy it, cut it, paste it, and save the result as a prefab.

For cellular automata, that matters. A glider stream, oscillator, eater, failed collision, or partial circuit is no longer just transient state on the board. It becomes material.

The workflow changes from redrawing patterns by hand to editing mechanisms directly:

observe a behavior
select the active region
transform or duplicate it
test the new geometry
save the useful result

That is the basic interaction model for an automata workbench.

Lenses keep local behavior readable

Lenses are circular magnifiers placed directly on the canvas. They enlarge a local region without zooming the whole board.

A short capture of lenses and zones while the automaton evolves

Automata are multiscale. You often need neighbor-level detail and board-level context at the same time: births, deaths, phase offsets, collision fronts, stream timing, boundaries, and population waves.

A normal zoom makes you choose between those views. Lenses let you keep both.

You can place one lens over a generator, another over a collision site, and compare cause and effect while the simulation runs.

Zones make rules spatial

Zones are rectangular regions with rule overrides. A cell can move from classic Life into HighLife, Seeds, Day & Night, or a custom B/S rule without leaving the board.

That makes the plane heterogeneous. A zone can act as a reaction chamber, protected basin, hostile boundary, rule-gradient experiment, or computational component.

The question becomes more precise: what happens when a structure crosses from one local physics into another?

That is useful for design, debugging, and play. It also gives rule changes a spatial form instead of treating them as global configuration.

Manifold regions make topology local

Manifold Regions map a rectangular patch of the flat board onto a topology such as a sphere, torus, Möbius strip, or Klein bottle.

A short capture of automata evolving across manifold-mapped regions

The whole board does not need to become a torus. A local patch can have toroidal adjacency while the surrounding workspace stays flat. Another patch can contain a Möbius seam.

This makes topology an editable part of the system. The same rule and seed can behave differently because the neighborhood graph changed.

For cellular automata, the rule is not the whole machine. Initial condition, observation, tools, and geometry all matter. Manifold Regions make the geometry explicit.

The IDE shape

Several systems are now converging:

canvas tools: paint, select, transform, stamp
analysis tools: period detection, population tracking, heatmaps
rule tools: presets, B/S editing, kernel radius, Lenia controls
spatial tools: zones, force fields, lenses
topology tools: manifold regions and curvature visualization
journal/script tools: documented, replayable experiments

The next useful step is persistence. Experiments should capture board state, rule configuration, selected regions, camera and lens positions, script cells, manifold mappings, and replayable timelines.

Prefabs should also become structured objects instead of screenshots: period, bounding box, velocity, input/output lanes, required phase, compatible rules, and known failure modes.

After that, topology can become a programming surface. Region seams, wraps, and local adjacency changes could be used as parts of spatial circuits.

The longer-term direction is an interactive atlas: scenes, rules, mechanisms, manifolds, and experiments that can be inspected, forked, mutated, and republished.

Automata Arcade is still an arcade. The play matters. But the current direction is clear: it is becoming an instrument for composing and studying cellular automata.

Automata Arcade: Building a Playable Lab for Conway’s Game of Life

2026-03-08T05:21:02+00:00

Automata Arcade turns Conway’s Game of Life into a live engineering arena. You do not just observe emergence, you shape it in real time.

Live demo: automata-arcade.vercel.app
GitHub: github.com/jclosure/automata-arcade

The core idea: computation through conflict

Game of Life is deceptively simple. Tiny local rules create global behavior that feels alive. In Automata Arcade, that behavior is not just visual, it is playable. You drop mechanisms, route moving signals, and watch tiny decisions scale into system-level outcomes.

You are not placing pixels. You are placing possibility.

Changing the game while it is being played

The board never freezes for you. Mid-simulation, you can rotate a structure into a stream, place an eater to terminate flow, or inject a fresh emitter into a crowded lane. That shifts your role from “builder” to “operator”, making architecture decisions under motion.

The palette is your machine language

Gliders as mobile information packets
LWSS for directional traffic experiments
Gosper glider guns as persistent emitters
Eater-1 as selective termination and routing control
Seeds and oscillators for timing, cadence, and pressure

The moment these pieces start interacting, the system becomes legible in a new way. You stop asking “what pattern is this?” and start asking “what behavior does this enforce?”

Battles, timing, and emergent strategy

Two glider streams can annihilate, reinforce, or generate surprising downstream structures depending on phase and offset. A tiny timing shift can flip a design from stable to catastrophic. That is where the battles happen, not cosmetic combat, but true dynamical conflict between interacting rule systems.

Because the world is deterministic, every surprise is still explainable after the fact. That tension between surprise and explainability is what makes the learning loop addictive.

Implementation, deliberately lightweight

Vanilla HTML/CSS/JS front end
Large-grid simulation with pan/zoom and variable stepping
Draggable prefab placement with rotate/flip transforms
Arcade wrapper with objectives, scoring, combo, and fail states
Static-friendly deploy and self-hosted media on Vercel

The goal was not maximal complexity. The goal was maximal agency: every control should help you reason about emergence without flattening it.

Watch it in motion

Automata Arcade demo animation

" data-large-file="https://i0.wp.com/joelholder.com/wp-content/uploads/2026/03/automata-arcade-demo.gif?fit=960%2C540&ssl=1" src="/assets/wp/automata-arcade-building-a-playable-lab-for-conways-game-of-life/automata-arcade-demo.gif" alt="Automata Arcade demo animation" class="wp-image-1934" />

Automata Arcade demo animation

Why this matters

Automata Arcade is a reminder that complex behavior can emerge from minimal rules, and that interactive systems can teach hard ideas quickly. Computation, resilience, failure modes, and control become tactile when you can build and intervene in real time.

We are still early. There is far more power to unlock here.

Evo Lumen Life, creating a living ecosystem in the browser

2026-03-02T07:49:46+00:00

Evo Lumen Life started as a shader experiment and became a living artificial-life sandbox where organisms swim, feed, reproduce, struggle, and evolve in a shared ecosystem.

Project repo: https://github.com/jclosure/evo-lumen-life

What it is

Evo Lumen Life is a browser-based simulation of emergent behavior. Instead of static entities, the world is populated by evolving forms (worms, flagellates, protozoa, and virus-like agents) whose movement and survival are shaped by local interaction rules, resource pressure, and reproduction strategies.

Why?

I wanted something more alive than classic cellular automata: not just a pattern engine, but a watchable ecology. The design intent was to create a system that felt continuous and organic—something you could tune and observe like a tiny synthetic biosphere.

Continuous lifecycle instead of abrupt generation resets
Predator/prey pressure and resource competition
Egg-based worm reproduction and juvenile growth
Interactive controls for time, evolution speed, drift, and species-level behavior

Goals

Make emergence visible: behavior should unfold over time, not be hidden in static metrics.
Keep it playful: enough complexity to surprise, enough controls to steer.
Stay portable: run on Mac, Linux, and Windows in a browser.
Favor flow: births, deaths, and adaptation drive the simulation

What we learned

The strongest improvements came from treating the system as a controlled dynamical model and validating behavior under parameter sweeps.

State integration quality dominates perceived realism. We update organism state in small timesteps (position, velocity, energy, age), which reduces aliasing and prevents visual/mechanical discontinuities from coarse step changes.
Bounded nonlinear terms are mandatory. Core drivers (aggression, drift, growth, resource intake) are clamped to stable ranges. Without bounds, positive feedback causes blow-up modes (population spikes, lock-step clumping, or immediate collapse).
Energy economics creates meaningful behavior. A simple budget model (intake – metabolic cost – reproduction cost) produced emergent strategy differences more reliably than hand-scripted behavior trees.
Asymmetry produces richer phase space. Predator-prey and forager-resource interactions are intentionally asymmetric; this increases attractor diversity versus symmetric pairwise rules.
Fitness is multi-objective. Useful scoring required balancing persistence, exploration, locomotion efficiency, and survivability. Single-objective optimization collapsed diversity too quickly.
Continuity constraints matter to observers. Interpolated hatch/growth curves and decay on death states improved interpretability and made causal chains easier to track.
Live controls function as instrumentation. Real-time sliders effectively became online experiments: we could locate bifurcation-like regime shifts quickly and tune toward stable-but-interesting dynamics.

Bottom line: better outcomes came from numerical stability, bounded feedback, and measurable objective tradeoffs—not from adding more visual entities alone.

Where this could go next

Speciation tracking with lineage trees and trait inheritance maps
Courtship and mate selection behaviors before egg-laying
Objective-driven environments (seasonality, gradients, hazards)
Replay/annotation mode for interesting events
Networked multiplayer ecosystem tournaments
Hybrid mode: AI ecology + human strategic interventions

Wrapping C and C++ APIs in Python

2019-12-16T23:24:10+00:00

Python is usually where I want to orchestrate work: load data, shape inputs, run experiments, and glue systems together. C and C++ are where I want hot loops, existing native libraries, SIMD-heavy routines, mature systems code, and APIs that already exist outside the Python ecosystem.

The useful question is not whether Python or C is better. The useful question is where the boundary should be. If the native side has a small stable ABI, ctypes is often enough. If the boundary needs C++ types, exceptions, RAII, overloaded functions, or a clean Python-facing module, reach for pybind11.

Start with the ABI

For a C API, the minimum viable path is:

build a shared library for the target platform
load it with ctypes.CDLL
declare each function’s argument types and return type
be explicit about memory ownership and error behavior

Using libgeohash as an example, a simple Linux build might look like this:

gcc -O3 -fPIC -shared -o libgeohash.so geohash.c

On macOS that output would usually be a .dylib; on Windows, a .dll. The Python code should not assume the extension unless you control deployment.

A small ctypes wrapper

The important part of ctypes is not the load call. It is declaring the ABI accurately. Without argtypes and restype, Python will guess, and those guesses are not a contract you want in production.

from ctypes import CDLL, c_char_p, c_double, c_int
from pathlib import Path

lib = CDLL(str(Path(__file__).with_name("libgeohash.so")))

def bind(name, restype, *argtypes):
    fn = getattr(lib, name)
    fn.restype = restype
    fn.argtypes = list(argtypes)
    return fn

geohash_encode = bind(
    "geohash_encode",
    c_char_p,
    c_double,
    c_double,
    c_int,
)

raw = geohash_encode(41.41845703125, 2.17529296875, 5)
hash_value = raw.decode("ascii")
print(hash_value)  # sp3e9

That wrapper is intentionally boring. A Python call crosses into native code, the C function receives two doubles and an int, and the returned char * is exposed as bytes. The Python layer decodes it because the C ABI does not know about Python strings.

Structs map cleanly when layout is simple

For plain C structs, define a matching ctypes.Structure. The order and C types must match the header. If the C side has packing pragmas, bitfields, platform-dependent integer sizes, or nested ownership, slow down and verify layout with tests.

typedef struct GeoBoxDimensionStruct {
    double height;
    double width;
} GeoBoxDimension;

extern GeoBoxDimension geohash_dimensions_for_precision(int precision);

from ctypes import Structure, c_double, c_int

class GeoBoxDimension(Structure):
    _fields_ = [
        ("height", c_double),
        ("width", c_double),
    ]

geohash_dimensions_for_precision = bind(
    "geohash_dimensions_for_precision",
    GeoBoxDimension,
    c_int,
)

dims = geohash_dimensions_for_precision(6)
print(dims.height, dims.width)

This is a good shape for ctypes: value types cross the boundary, Python receives a small struct, and there is no lifecycle problem to solve.

Out parameters and buffers

Many C APIs return status codes and write results through pointers. Model that directly. Do not pretend every C function is a Python function that returns one object.

int geohash_decode_bbox(
    const char *hash,
    double *lat_min,
    double *lat_max,
    double *lng_min,
    double *lng_max
);

from ctypes import POINTER, byref, c_char_p, c_double, c_int

geohash_decode_bbox = bind(
    "geohash_decode_bbox",
    c_int,
    c_char_p,
    POINTER(c_double),
    POINTER(c_double),
    POINTER(c_double),
    POINTER(c_double),
)

def decode_bbox(hash_value: str):
    lat_min = c_double()
    lat_max = c_double()
    lng_min = c_double()
    lng_max = c_double()

    rc = geohash_decode_bbox(
        hash_value.encode("ascii"),
        byref(lat_min),
        byref(lat_max),
        byref(lng_min),
        byref(lng_max),
    )
    if rc != 0:
        raise ValueError(f"geohash_decode_bbox failed: {rc}")

    return lat_min.value, lat_max.value, lng_min.value, lng_max.value

The wrapper converts the C style into a Python style at the edge: allocate output slots, call the native function, check the return code, and return a tuple. That keeps the rest of the Python application free of pointer management.

Use pybind11 when the boundary wants to be a module

ctypes works best against a C ABI. Once the native side is C++, or once you want a polished Python module instead of a thin ABI wrapper, pybind11 is usually cleaner. You write a small C++ binding layer, compile it as a Python extension, and expose Python-native functions/classes.

// bindings.cpp
#include 
#include 
#include 
#include 

namespace py = pybind11;

extern "C" char *geohash_encode(double lat, double lng, int precision);

struct Box {
    double height;
    double width;
};

Box dimensions_for_precision(int precision) {
    // In real code this would call the native library.
    return Box{0.0054931640625, 0.010986328125};
}

std::string encode(double lat, double lng, int precision) {
    char *raw = geohash_encode(lat, lng, precision);
    if (raw == nullptr) {
        throw std::runtime_error("geohash_encode returned null");
    }
    return std::string(raw);
}

PYBIND11_MODULE(geohash_native, m) {
    m.doc() = "Native geohash bindings";

    py::class_<Box>(m, "Box")
        .def_readonly("height", &Box::height)
        .def_readonly("width", &Box::width);

    m.def("encode", &encode,
        py::arg("lat"),
        py::arg("lng"),
        py::arg("precision") = 12);

    m.def("dimensions_for_precision", &dimensions_for_precision);
}

A minimal build using setuptools can stay small:

# setup.py
from pybind11.setup_helpers import Pybind11Extension, build_ext
from setuptools import setup

ext_modules = [
    Pybind11Extension(
        "geohash_native",
        ["bindings.cpp", "geohash.c"],
        cxx_std=17,
    ),
]

setup(
    name="geohash_native",
    ext_modules=ext_modules,
    cmdclass={"build_ext": build_ext},
)

python -m pip install pybind11 setuptools wheel
python -m pip install -e .

import geohash_native

print(geohash_native.encode(41.41845703125, 2.17529296875, precision=5))

box = geohash_native.dimensions_for_precision(6)
print(box.height, box.width)

The tradeoff is build complexity. With ctypes, Python loads an existing shared object. With pybind11, you ship a compiled Python extension for each supported Python/platform/architecture combination. The upside is a nicer API, better C++ interop, and fewer pointer-shaped details leaking into application code.

Rules of thumb

Use ctypes when the native library already exposes a stable C ABI and the surface area is small.
Use pybind11 when you own the native code, need C++ types, or want a Pythonic module.
Keep allocation and freeing on the same side of the boundary unless the API explicitly documents otherwise.
Turn C status codes into Python exceptions at the wrapper edge.
Write tests for struct layout, null pointers, invalid inputs, and at least one known-good result from the native library.
Benchmark the boundary. Crossing into native code is cheap enough for coarse operations, but not something to do once per scalar in a Python loop.

The clean version is simple: keep Python in charge of orchestration, keep native code responsible for the expensive or already-existing work, and make the boundary explicit. A thin wrapper is often enough, but the moment the boundary becomes part of your product API, give it the same design attention as any other public interface.

EventBusBridges for Great Good

2016-06-19T07:09:22+00:00

The SockJS protocol provides a fast and reliable mechanism for providing duplex communication via Websockets. Vertx has a particularly nice implementation of this in the form of EventBusBridges, which make it easy to create secure communication pipelines between an HttpServer Verticle and a variety of polyglot SockJS clients via Websockets or fallback transports. Surprisingly, a Java-based EventBusBridgeClient is not among the ootb facilities, even though Java is the main story on the server. Here I will show you how easy to create your own and a few of the awesome things you can do with it.

The EventBusBridge Server

Router router = Router.router(vertx);

// Allow all addresses to flow in and out on the bridge

BridgeOptions options = new BridgeOptions()
  .addInboundPermitted(new PermittedOptions().setAddressRegex(".+"))
  .addOutboundPermitted(new PermittedOptions().setAddressRegex(".+"));

router.route("/eventbus/*").handler(
  SockJSHandler.create(vertx).bridge(options)
);

// Setup a body handler
router.route().handler(BodyHandler.create());

HttpServer httpServer = vertx.createHttpServer();
httpServer.requestHandler(router::accept).listen(8080);

// do server wiring

// Publish a message to "someaddress" on interval
vertx.setPeriodic(5000, t -> {
  JsonObject msg = new JsonObject().put("packet", "stuff");
  vertx.eventBus().publish("someaddress", msg);
});

// Consume messages the "importantstuff" address
vertx.eventBus().consumer("importantstuff", msg -> {
  logger.warn(msg.body());
});

With this server code we are extending the EventBus via a Websocket. It’s available to any client that can speak the SockJS protocol. We can also easily write a Java client that will speak the SockJS-protocol to our server.

The Java SockJS Client

private static final String pingMessage;

static {
  JsonObject json = new JsonObject();
  json.put("type", "ping");
  pingMessage = json.encode();
}

HttpClient client = vertx.createHttpClient();

// We use raw websocket transport
client.websocket(port, host, "/eventbus/websocket", websocket -> {

// Register
JsonObject msg = new JsonObject().put("type", "register").put(
  "address", "someaddress"
);
websocket.writeFinalTextFrame(msg.encode());

// Setup pinging for keepalive
pingTimerId = Vertx.currentContext().owner().setPeriodic(
  5000, event -> {
    websocket.writeFinalTextFrame(pingMessage);
  }
);

// Send to the server
msg = new JsonObject().put("type", "send")
.put("address", "importantstuff")
.put("body", new JsonObject().put("foo", "bar"));
websocket.writeFinalTextFrame(msg.encode());

// Receive from the server
websocket.handler(buffer -> {
  JsonObject received = new JsonObject(buffer.toString());

  logger.info(
    "received message on address: " + received.getString("address")
  );
  logger.info("message body: " + received.getString("body"));
  });
});

Note that first we must “register” the client with the server. This is accomplished by sending a properly crafted register message, which is just a json packet with the type set to “register” along with the address the client wants to subscribe to. Additionally, the SockJS protocol specifies a “ping” message for keep alive on the socket. We provide a properly crafted pingMessage to enable this at the top of this code.

The envelope for SockJS messages is specified in the protocol to look like this:

{
"type": "send"|"publish"|"receive"|"register"|"unregister",
"address": "mailbox123"
"body": "the body of the message"
}

You can see in the client implementation above we performed a “send” by specifying it in the JsonObject envelope.

The operations specified by the protocol are these:

SOCKET_CREATED This event will occur when a new SockJS socket is created.

SOCKET_CLOSED This event will occur when a SockJS socket is closed.

SEND This event will occur when a message is attempted to be sent from the client to the server.

PUBLISH This event will occur when a message is attempted to be published from the client to the server.

RECEIVE This event will occur when a message is attempted to be delivered from the server to the client.

REGISTER This event will occur when a client attempts to register a handler.

UNREGISTER This event will occur when a client attempts to unregister a handler.

You can see how trivial relaying to a proxied address or republishing on a local EventBus might be by simply switching over these operations. In the kinds of patterns this substrates enables, you can see in things like Point-to-Point Channel, Publish-Subscribe Channel, and Scatter-Gather messaging.

The Javascript sockjs-client can be found here. Vertx includes an eventbus-client, vertx-eventbus.js, that utilizes sockjs.js to provide a convenient extension of the EventBus into Javascript apps. This is ideal for running in the browser, bolting realtime messaging directly into your web apps. There is also an npm module that brings allows you to easily snap node apps into your eventing framework. Someone has even recently created a C++ implementation that provides an onramp to your native runtime applications.

This is a fantastically powerful composition medium. I highly recommend it as the foundation for modern, high-speed, real-time software that needs to start small but scale to immense sizes. Thanks to Vertx, its just cake.

Enjoy the cake…