Joel Holder

Conway’s Circle, and the Right Triangle Hiding in Every Triangle

2026-08-27T19:30:00+00:00

Here is a party trick you can do with a ruler.

Draw any triangle. Take each side and, at each of its two ends, keep going past the corner — extend the line — by a very specific amount: the length of the side opposite that corner. You now have six new points floating out beyond the triangle, two hanging off each vertex.

Those six points lie on a circle.

Not approximately. Exactly. And it doesn’t matter what triangle you started with — squat, spindly, obtuse, nearly equilateral. Six extensions, one circle, every time.

Produce each side past each corner by the opposite side's length. The six endpoints are concyclic.

This is Conway’s circle, after John Conway — the same restless mind behind the Game of Life. It is one of those results that looks like a coincidence and turns out to be a right triangle wearing a disguise. This post is about taking the disguise off: why a circle, where its center is, where its radius comes from, and why the whole thing is really the Pythagorean theorem applied six times in six different reference frames.

The claim, said precisely

Let’s pin down a few names and keep them for the rest of the post.

Label the corners $A$, $B$, and $C$. Label each side with the small letter of the corner it faces — the corner it does not touch:

\[a = |BC|, \qquad b = |CA|, \qquad c = |AB|.\]

So $a$ is the side directly across from corner $A$, $b$ is across from $B$, and $c$ is across from $C$. Add the three side lengths together and you get the perimeter — the distance once around the triangle. Half of that gets its own name, the semiperimeter (“semi-“ just means half):

\[s = \frac{a + b + c}{2}.\]

Each side is named for the corner across from it. The semiperimeter $s$ is half the trip around.

Now the construction itself, one corner at a time.

Start at a corner — say $A$. Two sides of the triangle meet there. Extend both of them in a straight line past $A$, out beyond the triangle, and keep going until you have added a length equal to $a$, the side opposite $A$. A concrete way to add “a length equal to $a$”: open a compass to the length of side $a$, put its point on $A$, and sweep an arc. Wherever that arc crosses an extended side is where you stop. Corner $A$ now has two new points hanging off it.

Do exactly the same at $B$, adding a length $b$ each time, and at $C$, adding a length $c$. Six extensions, six new points.

The construction in four steps: mark the opposite side, swing that length past the corner, repeat at all three corners, and a circle catches all six points.

Here is the same thing in motion — swing the arc at one corner, mark where it lands, move to the next, and once all six points are down, draw the circle:

One corner at a time: step out by the opposite side, and every landing spot turns out to sit on the same circle.

Claim. Those six points lie on a single circle. Its center is the triangle’s incenter $I$, and its radius is

\[R = \sqrt{r^2 + s^2},\]

where $r$ is the inradius — the radius of the inscribed circle.

Everything interesting is packed into that square root. Let’s earn it.

A circle is a promise about distance

Before chasing the proof, it helps to be blunt about what a circle is, because the definition does most of the work.

A circle is not primarily a round shape. A circle is the set of all points at one fixed distance from one fixed point. That’s the whole content. “These points lie on a circle” is exactly the statement “there is a single point from which all of them are the same distance away.”

So the mystery “why do six points land on a circle?” collapses into a much more concrete question:

Is there one point in the plane that is equidistant from all six extension points?

If we can name that point and measure that distance, we are done — the circle is then guaranteed, for free, by the definition. No roundness to verify, no curvature to check. Just one distance, computed six times, coming out equal.

That reframing is the first real move. We are no longer looking for a circle. We are looking for a center.

Finding the center

From the last section, the whole job is now this: find one point that is the same distance from all six extension points. Call it the center — the problem is solved the moment we have it.

Here is the only clue on the table. The six points aren’t scattered at random; they come in three pairs, and each pair sits on the straight line through one side of the triangle. (Every side lies along an endless straight line, and the extensions just slide out along it. I’ll call that line the side’s side-line.)

So whatever the center is, it sits at some distance from each of the three side-lines. “Distance from a point to a line” means the shortest distance: head straight at the line so you meet it square-on, at a right angle, and measure that.

In the next two sections the radius $R$ will turn out to be built from two ingredients — this straight-in distance, and a distance measured along the side-line. For all six points to come out at one common distance, the straight-in distance has to be the same number for all three side-lines. That is the one thing we need from the center:

it is equally far from all three sides.

Exactly one point does that, and you can find it by folding.

Take two sides — say $AB$ and $AC$ — that meet at corner $A$. Which points are equally far from both of those lines? Picture standing in the corner of a room: the spots the same distance from both walls run down the diagonal, straight through the middle of the corner. In a triangle that middle line is the angle bisector at $A$ — the crease you would get by folding side $AB$ exactly onto side $AC$. Every point on that crease is equally far from the two sides.

Do the same fold at corner $B$. Its bisector is the set of points equally far from $BA$ and $BC$.

Where the two creases cross, the point is equally far from $AB$ and $AC$ (it lies on $A$’s bisector) and equally far from $AB$ and $BC$ (it lies on $B$’s bisector) — so it is the same distance from all three sides at once. That point is the incenter, $I$.

Two folds locate $I$: the point the same distance $r$ from all three sides. Its circle, the incircle, is the largest that fits inside.

The circle centered at $I$ with that common distance as its radius touches all three sides and crosses none of them — the biggest circle that fits inside the triangle. It is the incircle, and its radius is the inradius, $r$. Picture blowing up a balloon inside the triangle until it presses on all three sides: its center is $I$, and $r$ is how big it got.

That is our candidate center. Now we measure.

Why the number is $s$: half the perimeter, made of pieces

We are about to see $s$ — half the perimeter — turn up everywhere. It’s worth a minute on why that exact number, because it isn’t a convenience. It is the total of three little lengths hiding on the triangle’s edges.

The incircle touches each side once. Mark those three touch points. They chop the triangle’s boundary into six pieces.

Look at the two pieces that meet at corner $A$: one runs from $A$ to the touch point on $AB$, the other from $A$ to the touch point on $AC$. They are the same length. (It’s the “two tangents from one point” fact: the two lines you can draw from an outside point to just touch a circle are equal, because the picture is mirror-symmetric across the line from the point to the circle’s center.) Call that shared length $x$. Call the matching pair at corner $B$ length $y$, and the pair at corner $C$ length $z$.

The boundary is six pieces — $x, y, z$ each appearing twice. One of each is $s$.

Now walk once around the triangle. In order, you cross $x,\ y,\ y,\ z,\ z,\ x$ — each of the three lengths twice. So

\[\text{perimeter} = 2x + 2y + 2z,\]

and half of it is

\[s = x + y + z.\]

That is what “halfway” means here: $s$ is one copy of each tangent length. The perimeter counts each of them twice, because every one is shared between two sides; $s$ is what’s left once you stop double-counting.

One lap spends $x$, $y$, and $z$ twice each. Half the lap is one full set: $s = x + y + z$.

And now each tangent length gets a short name. On side $AB$ the two pieces are $x$ (from $A$) and $y$ (from $B$), and together they make the whole side: $x + y = c$. Since $x + y + z = s$, subtracting gives $z = s - c$. The same move on the other two sides gives all three:

\[x = s - a, \qquad y = s - b, \qquad z = s - c.\]

So on side $AB$, the touch point $F$ sits a distance $s - a$ from corner $A$, and $s - b$ from corner $B$.

The top-up to $s$

Now extend the side. Past $A$ we add a length $a$; past $B$ we add a length $b$. Measure from the touch point $F$ out to each new point, along the line:

Toward the “beyond A” point

$(s - a) + a = s$

Toward the “beyond B” point

$(s - b) + b = s$

Both land on $s$. And this is exactly why the rule extends by the opposite side. On side $AB$, the piece from corner $A$ to the touch point is $x = s - a$. To reach a full set $s$, the gap still to fill is $s - (s - a) = a$ — the side opposite $A$. “Extend by the opposite side” is just “fill the gap back up to one full set of tangent lengths.” Every extension point, on every side-line, ends up exactly $s$ from that line’s touch point.

The touch point cuts the side into $s-a$ and $s-b$. Producing by the opposite side tops each run up to $s$.

The right triangle hiding in the picture

Now put the two measurements together, on one side-line, say $AB$.

Stand at the incenter $I$. Drop a perpendicular to line $AB$. By definition of “distance from a point to a line,” this perpendicular has length $r$ and its foot is the touch point $F$. From $F$, walk along the line a distance $s$ — and you arrive at one of the extension points, $P$.

So $I$, $F$, and $P$ form a triangle with a right angle at $F$: one leg $r$ straight down to the line, one leg $s$ along the line. The distance from $I$ back to $P$ is the hypotenuse.

One leg $r$, one leg $s$, right angle at the touch point. The hypotenuse is $R$.

Legs of the right triangle

$|IF| = r, \qquad |FP| = s$

Pythagoras

$|IP|^2 = r^2 + s^2$

Distance from the incenter to the extension point

$|IP| = \sqrt{r^2 + s^2}$

Nothing in that calculation mentioned which side, which end, or which extension point. Every one of the six points is $r$ off some side-line and $s$ along it from that line’s touch point. So every one of the six is exactly $\sqrt{r^2 + s^2}$ from $I$.

Six points, one distance, one center. By the definition of a circle, we’re finished. The radius is $R = \sqrt{r^2 + s^2}$, and Conway’s circle is real.

Hypotenuse, or law of cosines?

Both — and seeing why is the “mental bedrock” worth sitting with.

The general tool for “two sides and the angle between them, find the third side” is the law of cosines. For triangle $IFP$, with the angle $\theta$ at the vertex $F$:

\[R^2 = |IF|^2 + |FP|^2 - 2\,|IF|\,|FP|\cos\theta = r^2 + s^2 - 2rs\cos\theta.\]

The Pythagorean theorem is not a different law. It is this law at one specific angle. When $\theta = 90^\circ$, $\cos\theta = 0$, the entire cross term $-2rs\cos\theta$ vanishes, and what’s left is

\[R^2 = r^2 + s^2.\]

So the honest answer to “are we taking the hypotenuse, or using the law of cosines?” is: we are using the law of cosines, and it collapses to the hypotenuse, because the angle is exactly right. And the angle is exactly right for a reason we did not arrange by hand — it is $90^\circ$ because “the distance from $I$ to the line” means the perpendicular distance. Perpendicularity is baked into the word “distance.” The right angle is a gift from the metric, not a feature of the triangle.

That $\cos\theta = 0$ is doing something quietly profound: it is the reason the two legs don’t interfere. The run along the line ($s$) and the drop to the line ($r$) contribute to $R$ independently, each through its own square, with no interaction term. Change one, and the other’s contribution is untouched. That independence is exactly what “perpendicular” buys you, and it is why the answer is a clean sum of two squares rather than a messy blend of three lengths.

Sum of squares, and what it means

You asked what it means to add the squares. Three answers, at three altitudes.

Geometrically. $r$ and $s$ are the two legs of a right triangle, and $\sqrt{r^2 + s^2}$ is its hypotenuse — the straight-line shortcut across the right angle. Adding the squares and taking the root is the operation that turns “how far across, how far up” into “how far, as the crow flies.” Set up local coordinates on side-line $AB$: origin at the touch point $F$, one axis running along the line, the other pointing at $I$. Then $I$ sits at $(0, r)$ and the two extension points sit at $(+s, 0)$ and $(-s, 0)$. The displacement from $I$ to an extension point is $(\pm s, -r)$, and its length is $\sqrt{s^2 + r^2}$. The construction is a machine for handing six points the same coordinates $(\pm s, 0)$ relative to $I$’s $(0,r)$ — in six different frames, one per side per end — and the sum of squares reports all six back as the same distance.

Mathematically. The plane’s ruler is the sum of squares. The distance between $(x_1, y_1)$ and $(x_2, y_2)$ is $\sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2}$ — Pythagoras, promoted to the definition of length. And a circle of radius $R$ about a center is, by definition, the level set

\[(x - x_0)^2 + (y - y_0)^2 = R^2 :\]

the places where that sum of squares holds a constant value. So “why do the six points form a circle?” and “why does the sum $r^2 + s^2$ come out constant?” are the same question asked twice. The circle is the shape of “sum of squares = constant.” Nothing else.

Philosophically. The sum-of-squares law is the statement that space is flat — Euclidean, uncurved, the same in every direction. It is the local ruler that a flat plane hands you. A circle is what “keep the same distance” looks like when you measure with that ruler. On a curved surface — the sphere, the hyperbolic plane — the ruler is different, “straight lines” bend, and this construction would not close up into a circle without being re-derived from scratch, with $r$ and $s$ no longer combining by a bare Pythagoras. So Conway’s circle is a fingerprint of the triangle, yes — but just as much a fingerprint of the flat plane it’s drawn on. The roundness is borrowed from the metric.

That last point echoes something from the staircase post: the Euclidean distance formula is the quiet foundation under a surprising amount of calculus and geometry, and it is always a sum of squares under a root.

The perimeter is the chord

Look again at a single side-line. It carries two of the six points — one produced past each endpoint — and we showed each sits a distance $s$ from the touch point, on opposite sides of it. So the two extension points on that line are

\[s + s = 2s = a + b + c\]

apart. The chord that side-line cuts across Conway’s circle has length exactly the perimeter of the triangle.

That is the clean answer to why the extension points terminate where they do — “along the line the perimeter traces.” The stopping rule was chosen so that the half-chord equals the half-perimeter $s$. Then $s$ becomes one leg of the right triangle, the perpendicular offset $r$ is the other, and $R = \sqrt{r^2 + s^2}$ falls out. The perimeter is not lurking in the background of this figure; it is drawn on it three times, once as each side-line’s chord. Walk once around the triangle and you have walked the length of any one of those chords.

There is a satisfying bookkeeping here. The semiperimeter $s$ is a sum — it is literally $\tfrac{1}{2}(a + b + c)$, the kind of running total that shows up all over elementary geometry. Conway’s construction takes that sum, stands it up as the long leg of a right triangle, and squares it. The radius carries the whole perimeter inside it, folded into one term under the root.

Change the triangle — the circle keeps its promise

Every step above used only three things: that the triangle has an incenter (every triangle does), that the tangent lengths from a vertex are equal (true for any circle and any external point), and that $r$ and $s$ are positive (true unless the triangle collapses to a segment). Nowhere did we use a special angle, a special ratio, or a special shape.

So the circle is not a property of some triangles. It is a property of the word “triangle.” Deform yours however you like — the incenter slides, $r$ and $s$ change, the radius $\sqrt{r^2 + s^2}$ grows and shrinks — and the six points ride the changing circle without ever stepping off it.

One vertex wanders. The incenter drifts, the radius breathes, and the six points never leave the circle.

Watch the edge land

The walk-through above took one corner at a time. Here is the same construction fired all at once, so you can see the six tips reach and the circle close in a single motion.

Each edge is a directed segment — a vector from one corner to the next. (In the geometric-algebra sense the edge is the vector; the oriented triangle it bounds is the bivector, an area element. What we stretch here is the edge vector.) Take that edge vector, run it past the far corner, and keep going by the length of the opposite side. Do it on all six half-edges. The six tips light up — and a circle threads all six.

Produce each edge by the opposite side. The tips land, and the circle closes through them.

The reason it always lands: extending by the opposite side is the same as topping the tangent run up to $s$, and once every tip is $s$ along its line and the center is $r$ off every line, Pythagoras gives all six tips the same distance from the center. The “landing” is just $\sqrt{r^2 + s^2}$ agreeing with itself six times.

What it implies, and what it only rhymes with

A concentric pair. $R^2 = r^2 + s^2$ says Conway’s circle is the incircle with the semiperimeter added in quadrature. Same center; the incircle is Conway’s circle with the $s$ term switched off. Two circles about one point, and the gap between them is entirely the perimeter’s doing.

A family, not a one-off. A triangle carries a small crowd of distinguished circles: the circumcircle through its three vertices, the incircle tangent to its three sides, the nine-point circle, the three excircles, and Conway’s. Three points already pin down a unique circle; three lines already pin down an incircle. The triangle is the smallest figure with enough structure to have a “center” worth arguing about — and it turns out to have several, each the center of its own circle.

Where I’d be careful. You raised the circle’s other lives — the shape that encloses the most area for a given perimeter, the curve that is the envelope of infinitely many tangent lines while a triangle makes do with three. Those are true and lovely facts about circles, but they are not the cause here. Conway’s circle is not the output of an optimization and not an envelope; it is six points that happen to be equidistant from the incenter. Keeping that distinction sharp is the difference between a resonance and an explanation. The honest through-line is smaller and, I think, better: three straight edges, extended by a rule that knows nothing but lengths, are already enough data to summon a curve — because a circle needs almost no data. One center, one radius. Three tangent lengths and a flat metric hand you both.

And the plane it lives on. “Is a triangle the simplest closed figure that can exist?” In the flat plane, essentially yes: three is the fewest sides that bound a region, and three non-collinear points determine exactly one circle — triangle and circle are paired from the start. But push the same question onto the actual sphere $S^2$ and the tidy answer frays. There is no scaling-similarity there, angles in a triangle sum to more than $\pi$, “lines” are great circles, and $r$ and $s$ stop combining by a clean $r^2 + s^2$. The Pythagorean sum of squares is a flat-space privilege. Conway’s circle leans on it completely.

Conway

John Horton Conway (1937–2020) collected constructions like this — things you can do with a pencil in ten seconds that hide a clean reason a layer down. The Game of Life is the famous one, but the instinct is the same here: a rule simple enough to hand to a child, generating structure that takes a paragraph to explain and a diagram to feel.

He apparently liked this circle enough that a proof-without-words version circulated with his name on it. Fitting. The proof really does fit in a picture: drop a perpendicular of length $r$, run a distance $s$ along the side, and the hypotenuse back to the incenter is the same length no matter which of the six tips you chose.

That is the whole secret. A triangle is just barely enough scaffolding — three tangent lengths, one incenter, one flat ruler — for a circle to have no choice but to appear.

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.