Why move

Zensical is the spiritual successor to Material for MkDocs, from the same author. The direction is right. The execution is early. Plugin coverage is thin, theming hooks are still shifting, and the documentation lags the code. Fine for a landing page. Not where I want to spend cycles when I’m trying to publish.

Quarto sits in a different place. It is a scientific publishing system first and a static site generator second. That ordering matters. .qmd and .ipynb are first-class inputs. Code executes at render time and the outputs are pinned via freeze. Math, citations, cross-references, and figure numbering are part of the format, not bolted on. The same source renders to HTML, PDF, and reveal.js without a second toolchain.

For a site that will mix prose with notebooks and blog posts, that is the whole game.

The migration

Content was straightforward. Markdown is markdown. Front matter shifted from MkDocs conventions to Quarto’s:

---
title: "Hello, Quarto. Bye, Zensical."
date: "2026-05-23"
categories: [news]
---

The blog index is a Quarto listing page. No plugin, no template hacking:

---
title: "Blog"
listing:
  contents: posts
  sort: "date desc"
  type: default
  categories: true
  feed: true
---

Theming is Bootstrap plus SCSS overrides. I kept Litera and added a styles-dark.scss for dark mode tweaks. Highlight styles are split per scheme so code blocks read well in both:

format:
  html:
    theme:
      light: litera
      dark: [litera, styles-dark.scss]
    highlight-style:
      light: github
      dark: monokai

Cloudflare Pages

This is the part that needed care. Cloudflare Pages does not ship Quarto in its build image. The official path is to install it yourself in the build step.

I pin the version. Floating versions are a great way to wake up to a broken site:

#!/usr/bin/env bash
set -euo pipefail

QUARTO_VERSION="${QUARTO_VERSION:-1.9.37}"

curl -fsSL "https://github.com/quarto-dev/quarto-cli/releases/download/v${QUARTO_VERSION}/quarto-${QUARTO_VERSION}-linux-amd64.tar.gz" \
  | tar -xz -C /opt
export PATH="/opt/quarto-${QUARTO_VERSION}/bin:${PATH}"

quarto render

In the Pages project settings:

• Build command: ./build.sh
• Build output directory: _site
• Root directory: project root

A few things worth knowing if you walk this path:

Pin the Quarto version explicitly. Quarto’s HTML output evolves between minor releases. The inline theme-toggle script in particular references DOM nodes that older versions did not emit. If your build image and your local version drift, you can ship a site whose JavaScript throws on load and silently falls back to defaults. Ask me how I know.

Commit _freeze/. Cloudflare’s builders are ephemeral and do not have your Python or R environment. Freezing computational output locally and checking it in means the builder only needs Quarto and pandoc, not your full data stack. Build times drop to seconds.

Skip output-dir surprises. Quarto writes to _site by default. Match Cloudflare’s output directory to that and resist the urge to rename.

A planet is a great circle

Start with one planet. The friend can see it only if it sits above their local horizon. The set of surface points that can see a faraway object is exactly the half of the sphere facing it — a hemisphere. The edge of that hemisphere, where the object sits right on the horizon, is a great circle.

Make this precise with vectors. Let be the outward unit normal at a surface point, and let point toward a planet. The planet is above the horizon at exactly when

Because each planet lands uniformly in the sky, is a uniform random direction, so is a uniformly random hemisphere with a random great circle for its rim.

The star plays the same game with one sign flipped. You can only see planets at night, which means the star must be below your horizon: . That’s a seventh hemisphere, the “night” side, bounded by a seventh great circle.

So six planets plus one star give seven random great circles. Seeing the full parade from a point means landing on the correct side of all seven at once: inside all six planet hemispheres and on the night side of the star.

Counting the regions

Seven great circles in general position slice the sphere’s surface into flat-faced regions, and every region sees its own fixed subset of the seven bodies. How many regions? Euler’s formula for any graph drawn on a sphere settles it:

Count each piece for circles:

• Vertices. Any two distinct great circles cross at two antipodal points, so .
• Edges. Each circle is cut by the other six into arcs, so .
• Faces. Rearranging Euler, .

The sky carves the ground into exactly 44 regions. Hold that number.

Getting

Two facts about those 44 regions do all the work.

First, at most one region ever sees the full parade. The parade region is the intersection of seven half-spaces (six “above the horizon,” one “below”). An intersection of half-spaces is convex, and on a sphere a convex set lands inside a single region — it can’t be split across two. So on any given night, either exactly one of the 44 regions is the lucky one, or none is.

Second, by symmetry every region is equally likely to be the friend’s home. The friend’s location is just one more fixed point; the seven circles are placed uniformly at random around it. Nothing distinguishes one of the 44 regions from another ahead of time, so the friend’s point is equally likely to fall in any of them.

Now read the question again. We’re told a parade is visible somewhere — exactly one region is lucky. The friend wins if their home is that one region out of 44. With every region equally likely,

It’s worth checking that “a parade is visible somewhere” is even possible to condition on — it has to have positive probability. A fixed point sees the parade with probability (each of the seven independent half-space tests is a fair coin). Summing that chance over all 44 regions, the probability that some region is lucky works out to . This is a clean special case of Wendel’s theorem on random hemispheres. The ratio is what matters: one lucky region in , so . The conditioning is well posed and the count is honest.

The tower, and getting

The tower extends the friend’s reach. They can now see a body if it clears the horizon at any surface point within distance of the tower’s base, not just at the base itself. Climbing higher effectively pushes each horizon outward by a small angle.

Two competing effects show up, and the sign of each is the whole puzzle.

Planets help. Reaching toward a planet that is just below your horizon can pull it into view. So for each of the six planets, the region that “sees” it grows outward by a band of width . The lucky region inherits six of these expanding edges.

The star hurts. Here’s the trap. The star is a celestial body too, and the same reach can pull the star above the horizon — meaning the top of your tower is in daylight, which kills the parade. So along the one edge of the lucky region that borders the star’s night-circle, the region shrinks by a band of width .

To first order in , the area a band adds (or removes) is just its length times its width:

So I need the expected perimeter of the lucky region, split by edge type. Symmetry hands me both pieces.

The seven great circles have total length . Each arc borders exactly two of the 44 regions, so summing every region’s perimeter double-counts the arcs: the grand total of all perimeters is . All 44 regions are symmetric, so each has expected perimeter

And the seven circles are interchangeable, so each contributes of that perimeter. Six circles are planets, one is the star:

Plug in. The expected area change is

The friend’s base is uniform on the whole surface of area , so the probability rises by

Matching this to ,

Six edges push out, one edge pulls in, , all over the same . The day/night boundary is the only thing that makes smaller than “six bands’ worth,” and it’s exactly the detail the puzzle is built around.

Checking it in code

The hand argument leans on a small-angle picture, so I want a closed form to differentiate and confirm. Translate the tower reach into an angle (arc length over radius). Reaching toward a planet drops its horizon, so you see planet when ; the star must stay down even from the tower top, so night means . Since is uniform on , a fixed tower sees the parade with probability

Dividing by the same (a parade still has to exist somewhere), I get the conditional probability as a function of . Its value and slope at are and .

import sympy as sp

delta = sp.symbols("delta", positive=True)
s = sp.sin(delta)

g = (1 + s)**6 * (1 - s) / 128          # fixed tower sees the full parade
P_exists = sp.Rational(11, 32)          # parade visible somewhere (Wendel, 7 circles)
p = g / P_exists                        # conditional probability, as a function of delta

alpha = sp.simplify(p.subs(delta, 0))
beta = sp.simplify(sp.diff(p, delta).subs(delta, 0))   # d/d(r/R) at r = 0
series = sp.series(p, delta, 0, 2).removeO()

print("alpha          =", alpha)
print("beta           =", beta)
print("p(r/R) approx  =", sp.expand(series))

alpha          = 1/44
beta           = 5/44
p(r/R) approx  = 5*delta/44 + 1/44

Both fall straight out: and , with the linear expansion exactly matching the by-hand answer.

It’s also worth confirming the region count and the existence probability independently. Euler’s formula gives the faces, and Wendel’s theorem gives the chance a parade is possible at all.

from math import comb

n = 7                                   # 6 planets + 1 star
V = 2 * comb(n, 2)                      # antipodal crossings
E = n * 2 * (n - 1)                     # arcs per circle, times circles
F = 2 - V + E                           # Euler: V - E + F = 2
print(f"V = {V}, E = {E}, F = {F} regions")

# Wendel: P(all n random hemispheres share a common point) in 3D
P = sp.Rational(sum(comb(n - 1, k) for k in range(3)), 2**(n - 1))
print(f"P(parade possible) = {P} = {F}/128")

V = 42, E = 84, F = 44 regions
P(parade possible) = 11/32 = 44/128

Monte Carlo gut-check

Before I trust either the region count or the tower correction, I want to drop a few million random skies on a fixed friend and watch the empirical numbers land. I put the friend at the north pole (one fixed point is as good as any), scatter seven uniform directions for each night, and apply the same horizon tests.

import numpy as np

rng = np.random.default_rng(20260330)
N = 4_000_000

def unit(n):
    v = rng.standard_normal((n, 3))
    return v / np.linalg.norm(v, axis=1, keepdims=True)

friend = np.array([0.0, 0.0, 1.0])      # WLOG, by symmetry

def parade_prob(rR):
    """P(friend with tower reach r/R sees the parade | a parade exists)."""
    sin_d = np.sin(rR)
    seen = np.ones(N, dtype=bool)
    for _ in range(6):                  # planets: must clear the horizon
        seen &= friend @ unit(N).T > -sin_d
    seen &= friend @ unit(N).T < -sin_d  # star: must stay below it (night)
    return seen.mean() / (11 / 32)      # condition on a parade existing

print(f"alpha empirical : {parade_prob(0.0):.5f}   exact 1/44 = {1/44:.5f}")
for rR in (0.02, 0.05):
    pred = 1/44 + 5/44 * rR
    print(f"r/R={rR:.2f}: sim {parade_prob(rR):.5f}   alpha+beta(r/R) {pred:.5f}")

alpha empirical : 0.02279   exact 1/44 = 0.02273
r/R=0.02: sim 0.02506   alpha+beta(r/R) 0.02500
r/R=0.05: sim 0.02893   alpha+beta(r/R) 0.02841

The base rate sits on , and the small- values track closely. The fit drifts as grows, which is expected — is only the first-order slope, and the curvature of shows up once the band stops being thin.

A picture of the lucky region

To see why is so small, it helps to draw the 44 regions for one random sky and shade the single region that sees every planet at night.

import matplotlib.pyplot as plt

rng2 = np.random.default_rng(28)
normals = rng2.standard_normal((7, 3))
normals /= np.linalg.norm(normals, axis=1, keepdims=True)
planets, star = normals[:6], normals[6]

# dense grid of surface points in lat/lon
lon = np.linspace(-np.pi, np.pi, 720)
lat = np.linspace(-np.pi/2, np.pi/2, 360)
LON, LAT = np.meshgrid(lon, lat)
U = np.stack([np.cos(LAT)*np.cos(LON), np.cos(LAT)*np.sin(LON), np.sin(LAT)], -1)

sees_planets = np.all(U @ planets.T > 0, axis=-1)   # all six above horizon
night = U @ star < 0                                # star below horizon
parade = sees_planets & night

fig, ax = plt.subplots(figsize=(7, 4))
ax.contourf(LON, LAT, parade.astype(float), levels=[0.5, 1.5], colors=["#2a9fd6"], alpha=0.85)
for nrm, col in [(p, "#888888") for p in planets] + [(star, "#d62728")]:
    # the great circle u . n = 0, drawn as its locus in lat/lon
    val = U @ nrm
    ax.contour(LON, LAT, val, levels=[0], colors=[col], linewidths=1.2)
ax.set_xlabel("longitude"); ax.set_ylabel("latitude")
ax.set_xticks([]); ax.set_yticks([])
ax.set_title("one random night on Pyrknot")
plt.savefig("thumbnail.png", dpi=110, bbox_inches="tight")
plt.show()

Gray circles are planet horizons, the red circle is the star’s night boundary, and the blue patch is the parade region. On most nights that patch is tiny or absent — which is exactly why landing in it is a -in- event.

What made it nice

The whole puzzle hinges on one change of view: a planet in the sky is a hemisphere on the ground, and its rim is a great circle. After that, is Euler’s formula ( regions, one of them lucky) and is a perimeter split six-to-one between planets that help and a star that hurts. No integrals, no heavy machinery — just careful counting and one sign you can’t afford to miss.

The official Jane Street solution takes the same great-circle route and lands on the same pair, and .

Tokenizing: text becomes words

The first job is to chop the raw text into tokens — the smallest meaningful pieces. Names, numbers, string literals, operators, and the structural markers that make Python Python: newlines that end a logical line, and the INDENT/DEDENT tokens that stand in for the braces other languages use. CPython’s real tokenizer is written in C and lives under Parser/, but the standard library ships a pure-Python one you can run yourself, the tokenize module.

import tokenize, io

src = "x = 2 + 3 * 4\n"
for tok in tokenize.generate_tokens(io.StringIO(src).readline):
    name = tokenize.tok_name[tok.type]
    if name in ("ENCODING", "ENDMARKER", "NL"):
        continue
    print(f"{name:9} {tok.string!r}")

NAME      'x'
OP        '='
NUMBER    '2'
OP        '+'
NUMBER    '3'
OP        '*'
NUMBER    '4'
NEWLINE   '\n'

Each token carries its type, its text, and its position in the source. The numeric values behind names like NAME and OP are generated from Grammar/Tokens and can shift between releases, so you always refer to them by name through the token module, never by number.

The tokenizer is where one of the more interesting recent reworks happened. Through Python 3.11 an f-string was handed to the parser as a single opaque STRING token, and a separate hand-written C routine picked it apart. That was fragile and full of special cases. PEP 701, in Python 3.12, formalized f-strings into the real grammar. The tokenizer now emits structured pieces — FSTRING_START, FSTRING_MIDDLE, FSTRING_END — and the parser handles the {...} expressions like any other code.

src = 'f"hi {name}"\n'
for tok in tokenize.generate_tokens(io.StringIO(src).readline):
    n = tokenize.tok_name[tok.type]
    if n in ("ENCODING", "ENDMARKER", "NEWLINE", "NL"):
        continue
    print(f"{n:14} {tok.string!r}")

FSTRING_START  'f"'
FSTRING_MIDDLE 'hi '
OP             '{'
NAME           'name'
OP             '}'
FSTRING_END    '"'

The practical payoff: f-strings stopped having weird arbitrary limits. You can nest quotes of the same kind, use backslashes, and write multi-line expressions inside the braces. The lexer change is what made all of it fall out for free.

Parsing: words become a tree

A flat list of tokens has no structure. Parsing turns it into an abstract syntax tree (AST) — a nested representation where 2 + 3 * 4 knows that the multiplication binds tighter than the addition. Since Python 3.9, CPython uses a PEG parser (a parsing expression grammar) that replaced the old hand-maintained LL(1) parser; the old parser module was removed in 3.10. The grammar itself is a readable file, Grammar/python.gram, and the C parser is generated from it.

The key idea behind PEG is ordered choice. When a rule lists alternatives, they’re tried in written order and the first match wins. That removes the ambiguity that plagues older grammar styles, at the cost of needing memoization to stay fast (so-called packrat parsing). The full rationale is in the parser guide in the CPython internals docs.

You rarely touch the parser directly. You reach for the ast module, which gives you the tree as Python objects you can inspect, walk, or rewrite.

import ast

tree = ast.parse("x = 2 + 3 * 4")
print(ast.dump(tree, indent=2))

Module(
  body=[
    Assign(
      targets=[
        Name(id='x', ctx=Store())],
      value=BinOp(
        left=Constant(value=2),
        op=Add(),
        right=BinOp(
          left=Constant(value=3),
          op=Mult(),
          right=Constant(value=4))))])

Read the nesting: the assignment’s value is a BinOp for +, whose right side is another BinOp for *. Precedence is baked into the shape of the tree, not decided later. This is the level tools like linters, formatters, and type checkers operate on, because it’s the first representation that actually understands the structure of your code.

Compiling: the tree becomes bytecode

The AST is still a description of your program, not something to execute. The compiler (Python/compile.c) lowers it into bytecode: a flat sequence of simple instructions for a stack machine. Along the way it builds a symbol table to work out which names are local, global, or captured from an enclosing scope, then turns the tree into a control-flow graph and emits instructions. The compiler design page in the developer guide walks the full path.

The result is a code object: bytecode plus everything needed to run it — constants, names, argument counts, line-number tables. The dis module disassembles it into something readable.

import dis

dis.dis(compile("x = 2 + 3 * 4", "<demo>", "exec"))

  0           RESUME                   0

  1           LOAD_SMALL_INT          14
              STORE_NAME               0 (x)
              LOAD_CONST               1 (None)
              RETURN_VALUE

Two things to notice. First, there’s no 2, 3, 4, or any arithmetic in the output. The compiler folded the constant expression 2 + 3 * 4 down to 14 at compile time, so the running program just loads the answer. Second, LOAD_SMALL_INT is a specialized instruction for small integers — one of many narrow, fast opcodes CPython has grown over the years.

Disassembling a function shows more of that flavor:

def add(a, b):
    return a + b

dis.dis(add)

  1           RESUME                   0

  2           LOAD_FAST_BORROW_LOAD_FAST_BORROW 1 (a, b)
              BINARY_OP                0 (+)
              RETURN_VALUE

LOAD_FAST_BORROW_LOAD_FAST_BORROW is a single fused instruction that loads two local variables at once, and BINARY_OP is a generic operation the interpreter can later specialize once it sees what types actually flow through it. More on that in a moment.

One warning that the docs repeat and I’ll repeat too: bytecode is not stable. The instruction set changes every minor release, sometimes a lot. Never pickle it, never ship it between versions, never depend on a specific opcode existing. It’s an internal detail. dis is for understanding, not for building on.

The evaluation loop: running the bytecode

The bytecode finally runs in the evaluation loop, the heart of the interpreter, in Python/ceval.c. At its core is a function, _PyEval_EvalFrameDefault, that walks the instructions of a frame (one call’s worth of execution state — its locals, its value stack, its position in the bytecode) and does what each one says. Call a function and a new frame goes on the stack; return and it pops off.

For most of Python’s history this was a big dispatch loop: fetch an instruction, jump to the code for it, repeat. The last few releases have made it considerably cleverer, and that’s where a chunk of recent performance work lives.

The specializing adaptive interpreter (PEP 659, Python 3.11) is the big one. The interpreter watches which instructions run hot and rewrites them in place into specialized forms. A generic BINARY_OP that keeps seeing two integers quietly becomes an int-only add that skips the type checks. If the assumption later breaks — someone passes strings — it falls back to the general version. You write ordinary Python; the interpreter adapts the bytecode to your actual data as it runs.

The experimental JIT (PEP 744, Python 3.13) goes a step further. Hot code is translated into a lower-level sequence of micro-operations, optimized, and then compiled to actual machine code using a technique called copy-and-patch. It’s off by default and has to be built in explicitly, so it’s still a preview rather than something most people run. What’s new in 3.14 is that the official Windows and macOS installers now ship the experimental JIT in the binary, so it’s far easier to try — but it remains experimental.

The tail-call interpreter (Python 3.14) is a different, quieter speedup. Instead of one giant loop, each opcode becomes a small C function that hands control to the next via a guaranteed tail call, which lets the C compiler keep interpreter state in registers. It needs a recent Clang and is opt-in at build time, and it changes nothing you can observe from Python — same bytecode, same behavior, just a faster engine. (Worth a caution: the early headline numbers were inflated by a compiler regression in the baseline; the honest figure is a few percent.)

The runtime underneath

The pipeline above tells you how code gets executed. It doesn’t tell you how the engine keeps house: who’s allowed to run, where objects live, and when they get cleaned up. That’s the runtime, and it’s where three of the most-discussed pieces of CPython sit.

import sys, sysconfig

free_threaded = bool(sysconfig.get_config_var("Py_GIL_DISABLED"))
print("free-threaded build:", free_threaded)
print("GIL currently enabled:", sys._is_gil_enabled())

free-threaded build: False
GIL currently enabled: True

import sys

data = ["a", "b", "c"]
print("refs to the list:", sys.getrefcount(data) - 1)
also = data
print("after a second name:", sys.getrefcount(data) - 1)

refs to the list: 1
after a second name: 2

import gc

gc.collect()        # start from a clean slate
a = {}
b = {}
a["b"] = b          # a -> b
b["a"] = a          # b -> a, a cycle
del a, b            # outside references gone; refcounts still nonzero

unreachable = gc.collect()   # find and free the cycle
print("objects reclaimed by the cyclic collector:", unreachable)

objects reclaimed by the cyclic collector: 2

print("gc thresholds (gen0, gen1, gen2):", gc.get_threshold())

gc thresholds (gen0, gen1, gen2): (2000, 10, 10)

Branching out: the concurrency models

Once you understand the GIL, the menu of concurrency tools makes sense. Each one is a different answer to “how do I do more than one thing, given that lock?”

Threads (threading) are real OS threads, but on the standard build the GIL means only one runs Python at a time. Perfect for I/O-bound work, where threads spend their time waiting and the lock is free. Not a path to multi-core CPU speed — unless you’re on the free-threaded build, which is exactly the wall PEP 703 is tearing down.

Processes (multiprocessing) sidestep the GIL by running separate Python interpreters in separate processes, each with its own lock and memory. True parallelism, at the cost of no shared memory by default and the overhead of pickling data across the boundary. A safety-relevant change landed in 3.14: on most Unix systems the default start method moved from fork to forkserver, because fork in a multi-threaded program is a long-standing source of deadlocks. If you relied on fork, you now request it explicitly.

Async (asyncio) is single-threaded concurrency. One thread, one event loop, many coroutines that voluntarily yield at await points. No GIL contention because there’s only one thread; the win is handling thousands of mostly-waiting connections without thread overhead. It’s cooperative, so one coroutine that blocks on CPU work stalls everything — the model is for I/O, not computation.

Subinterpreters (PEP 734) are the newest branch, and they sit between threads and processes. Built on the per-interpreter GIL, multiple isolated interpreters run inside one process, each with its own lock, so they execute Python in parallel — but with far less isolation cost than separate processes. Python 3.14 exposed them to Python code for the first time, through the new concurrent.interpreters module, plus an InterpreterPoolExecutor in concurrent.futures that runs each worker in its own interpreter.

The rule of thumb, slightly rewritten for 2026:

• I/O-bound, many connections → asyncio
• I/O-bound, simpler or blocking-library code → threads
• CPU-bound → processes, or subinterpreters, or the free-threaded build if you can use it

import os

# A neutral way to size a thread/process pool to the machine.
print("CPUs available to this process:", os.process_cpu_count())

CPUs available to this process: 6

What’s new, gathered up

The recent releases touch almost every stage above. Pulling the thread together:

Python 3.13 was the foundation release for the big shifts. Experimental free-threading (PEP 703) and the experimental JIT (PEP 744) both landed as previews. It also shipped a much nicer REPL — multiline editing, colors, paste handling — borrowed from PyPy, and gave locals() well-defined behavior in PEP 667.

Python 3.14 (released October 2025) is where several of those grew up. Free-threading became officially supported, subinterpreters got a real stdlib API, and the JIT started shipping in the official installers. On the language side it added two features worth knowing:

Deferred annotations (PEP 649) changed how type hints are stored. Annotations are no longer evaluated when a function or class is defined; they’re computed lazily on demand, so forward references just work without quoting them in strings. A new annotationlib module gives you control over how you read them back.

Template strings (PEP 750), or t-strings, are a new sibling of f-strings. A t"..." doesn’t produce a finished string — it produces a Template object that keeps the literal parts and the interpolated values separate, so a library can process them safely before assembling the result. It’s built for the exact situations where f-strings are dangerous: SQL, shell commands, HTML.

from string.templatelib import Template, Interpolation

name = "world"
template = t"hello {name}"
print("type:", type(template).__name__)
for part in template:
    if isinstance(part, Interpolation):
        print(f"  interpolation: expr={part.expression!r} value={part.value!r}")
    else:
        print(f"  literal text:  {part!r}")

type: Template
  literal text:  'hello '
  interpolation: expr='name' value='world'

The static text and the substituted value stay distinct, which is what lets a template-aware function escape the value correctly instead of trusting an already-flattened string. 3.14 also added Zstandard compression (compression.zstd) and a remote debugging hook that lets you attach pdb to a running process by PID.

Python 3.15 is in development — feature-frozen and in beta as of this writing, with a release planned for October 2026, so treat all of this as tentative until it ships. The draft what’s-new points at some genuinely interesting items: lazy imports (PEP 810) via a lazy import form that defers loading a module until first use, UTF-8 as the default text encoding regardless of locale (PEP 686), and a new profiling package including a low-overhead statistical sampling profiler. The free-threading and JIT work continues underneath. I’ll write these up properly once 3.15 is final and the list stops moving.

The shape of it

Step back and the whole thing is one straight line with a support structure beneath it. Text becomes tokens, tokens become a tree, the tree becomes bytecode, and a loop runs the bytecode — and under that loop, reference counting and a cyclic collector manage memory while the GIL (or its absence) decides who runs. Every stage is inspectable from Python itself: tokenize, ast, dis, gc, sys. That openness is the nicest thing about CPython. You don’t have to take the pipeline on faith; you can print it out and watch it work.

If you want to go deeper, the two best maps are the Python Developer’s Guide and the InternalDocs/ folder in the CPython source. Both are written for people seeing this for the first time, and both are kept current with the code.

The Nash baseline

Each robot’s strategy is a single number: a rethrow threshold . Keep the first throw if , otherwise take a fresh throw. (Why a threshold? Holding the opponent’s strategy fixed, the value of keeping is increasing in while the value of rethrowing is constant — so the keep/rethrow decision flips at one cutoff.)

If a robot uses threshold , its final score has CDF

(Below , the only way to land at is a rethrow, with weight ; above , kept first throws contribute too.)

In a symmetric Nash equilibrium both robots use the same , and the player at the cutoff is indifferent between keeping and rethrowing. The win probability from keeping a score of exactly is . The win probability from rethrowing is . Setting them equal,

The golden-ratio conjugate. At Nash both robots win half the time.

Spears’ leak

Spears picks , then gets the bit before deciding whether to rethrow. Under the assumption that Java-lin plays Nash with threshold , the most informative choice is — the bit then exactly distinguishes “Java-lin rethrew” from “Java-lin kept”. Any other leaves Spears uncertain about whether Java-lin’s final score is uniform on or on , which is the only thing the bit can resolve. (You can verify this by writing out Spears’ win probability as a function of and checking that is the maximum; the derivative changes sign there.)

So under Spears’ (mistaken) belief, after observing Java-lin’s final score is

• : (Java-lin rethrew).
• : (Java-lin kept).

Spears now picks a rethrow threshold for each value of , again by indifference.

. Java-lin’s score is uniform on . Keeping wins with probability ; rethrowing wins with probability . So .

. Java-lin’s score is uniform on . Keeping wins with probability ; rethrowing wins with probability . Setting them equal,

using .

Java-lin’s counter-shift

Now Java-lin secretly knows the leak. Spears is committed to thresholds and , regardless of what Java-lin does. Java-lin picks a new threshold to maximise its win probability. Crucially, the bit Spears receives is still (because Spears chose before this game began).

Suppose . Java-lin’s behaviour splits into three intervals:

in	Java-lin does	Bit	Spears’ threshold
	rethrow
	keep
	keep

The middle row is the trick. On Java-lin keeps a score that the Nash version would have thrown away. Spears, still believing Java-lin played Nash, expects a uniform rethrow from these values and sets — leaving Java-lin’s actual score in pleasantly above Spears’ rethrow target. The leak says “Java-lin rethrew”, but Java-lin didn’t.

Let for and for be Spears’ CDF when using threshold . Java-lin’s win probability is

The first integral evaluates to . The other two don’t depend on . Differentiating,

Setting gives

And , so the assumption holds. Below the marginal benefit of nudging up is positive too (the integrand is for ), so is the unique maximiser.

Solving in code

from sympy import Rational, sqrt, simplify, integrate, Symbol, Piecewise, nsimplify

x, T = Symbol("x", positive=True), Symbol("T", positive=True)
phi = (sqrt(5) - 1) / 2
r0  = Rational(1, 2)
r1  = 1 - phi/2

def F_S(y, r):
    return Piecewise((r*y, y <= r), (y*(1 + r) - r, True))

# Win prob with Java-lin threshold T (assumes 1/2 <= T <= phi):
W_expr = (
    T * Rational(3, 8)
    + integrate(F_S(x, r0), (x, T, phi))
    + integrate(F_S(x, r1), (x, phi, 1))
)
W_star = simplify(W_expr.subs(T, Rational(7, 12)))
print("Closed form:", nsimplify(W_star))
print(f"Decimal:    {float(W_star):.12f}")
print(f"Submission: {float(W_star):.10f}")

Closed form: 229/192 - 5*sqrt(5)/16
Decimal:    0.493937090365
Submission: 0.4939370904

Tidied up, the closed form is

Just below . Spears’ bit was worth more than Java-lin’s counter-shift could fully recover, but the gap is tiny — the Nash baseline of is almost reached.

Monte Carlo gut-check

Before I trust the recursion, I want to play a few million games at against Spears’ fixed thresholds and watch the empirical win rate land on .

import numpy as np

rng = np.random.default_rng(20251204)
phi_f = float(phi)
r0_f, r1_f = 0.5, float(r1)
T_f = 7/12

N = 2_000_000
XJ = rng.uniform(0, 1, N)
XS = rng.uniform(0, 1, N)
RJ = rng.uniform(0, 1, N)
RS = rng.uniform(0, 1, N)

YJ = np.where(XJ >= T_f, XJ, RJ)
bit = XJ > phi_f
r_used = np.where(bit, r1_f, r0_f)
YS = np.where(XS >= r_used, XS, RS)

wins = float((YJ > YS).mean())
print(f"Empirical win prob: {wins:.6f}")
print(f"Analytic  win prob: {float(W_star):.6f}")

Empirical win prob: 0.493868
Analytic  win prob: 0.493937

The two agree to within Monte Carlo noise, which is a relief — small mistakes in the bit-conditioning logic are easy to make.

A picture of the optimum

import matplotlib.pyplot as plt

def F_S_num(y, r):
    return np.where(y <= r, r*y, y*(1+r) - r)

def W(T):
    rethrow_win = (1 - r0_f + r0_f**2) / 2
    xs = np.linspace(T, phi_f, 400)
    mid = np.trapezoid(F_S_num(xs, r0_f), xs)
    xs = np.linspace(phi_f, 1, 400)
    top = np.trapezoid(F_S_num(xs, r1_f), xs)
    return T * rethrow_win + mid + top

Ts = np.linspace(0.30, phi_f, 200)
Ws = np.array([W(T) for T in Ts])
T_star = 7/12
W_num = float(W_star)

fig, ax = plt.subplots(figsize=(7, 5))
ax.plot(Ts, Ws, color="#1f77b4", lw=2)
ax.axvline(phi_f, color="grey", lw=0.8, ls=":", alpha=0.8, label=r"Nash $\varphi$")
ax.axvline(T_star, color="black", lw=0.8, ls="--", alpha=0.7)
ax.axhline(W_num,  color="black", lw=0.8, ls="--", alpha=0.7)
ax.plot([T_star], [W_num], "o", color="#d62728", ms=7)
ax.annotate(
    f"$T^\\star = 7/12$\n$W^\\star \\approx {W_num:.10f}$",
    xy=(T_star, W_num), xytext=(T_star - 0.18, W_num - 0.012),
    arrowprops=dict(arrowstyle="->", color="black", lw=0.8),
)
ax.set_xlabel("Java-lin's rethrow threshold $T$")
ax.set_ylabel("win probability")
ax.legend(loc="lower right")
ax.grid(True, alpha=0.3)
plt.savefig("thumbnail.png", dpi=110, bbox_inches="tight")
plt.show()

The shape makes sense. Pushing down from keeps more of the band — exactly the band Spears mis-reads as a uniform rethrow — and that pays until drops below . Past that point, the kept scores are too weak to beat Spears’ often enough, and the gain from extra band-keeping turns negative.

What made it nice

The trick was the asymmetry of belief. Spears’ threshold is locked in by Spears’ assumption that Java-lin plays Nash; Java-lin can break that assumption without Spears noticing, and the bit Spears receives turns into mild misinformation on the interval . One derivative picks the right , and the rest is integrals.

The official Jane Street solution follows the same path and lands on the same answer, .

Reading the rules

At each pitch the pitcher picks a probability of throwing a strike, and the batter picks a probability of swinging. The four cells of the resulting 2-by-2 give

pitcher  batter	wait	swing
ball	balls	strikes
strike	strikes	home run with prob , else strikes

An at-bat is a Markov chain on counts with and . It terminates when (walk, point), (strikeout, points), or a home run ( points).

Let be the at-bat value to the batter under Nash equilibrium play. Boundary conditions are and .

A symmetry that does most of the work

Write and . Combining the four cells, the expected payoff at is

Stare at that for a moment. It’s symmetric in and : swap them and nothing changes. The pitcher minimises this and the batter maximises it, but they’re playing against the same expression. So at equilibrium

That single observation collapses two unknowns per state into one. The Jane Street solution calls it out as the trick: “the outcome of a pitch is symmetric with respect to the pitcher’s choice and the batter’s choice.”

Solving the per-state game

In a mixed-strategy equilibrium of a game, each player picks the probability that makes the opponent indifferent between their two pure actions. From the batter’s side, the batter is indifferent between always waiting (value if the pitcher’s pitch lands as a ball, if a strike — overall ) and always swinging (value ).

Setting those equal and solving for gives

And the equilibrium value (just plug into the always-swing expression — both pure actions give the same answer by indifference) is the very tidy

That’s the recursion. Walk the count grid from the terminal states inward and you get and at every state in twelve assignments.

Counting the path to a full count

Once is known at every state, the state-to-state transition probabilities follow from the same payoff matrix. Reading off the cells:

(The three add to , as a sanity check.) Starting from with mass and pushing forward through this Markov chain, is just the mass that lands on .

Backward, then forward, in code

import numpy as np

def solve(p):
    """Return q(p) and the equilibrium swing probabilities."""
    V = np.zeros((5, 4))
    V[4, :] = 1.0          # walk
    V[:, 3] = 0.0          # strikeout
    sigma = np.zeros((4, 3))
    for tot in range(5, -1, -1):
        for b in range(4):
            s = tot - b
            if not (0 <= s <= 2):
                continue
            Vb, Vs = V[b+1, s], V[b, s+1]
            sg = (Vb - Vs) / (4*p - (1+p)*Vs + Vb)
            sigma[b, s] = sg
            V[b, s] = Vs + sg * p * (4 - Vs)
    # forward: probability of reaching each state
    q = np.zeros((5, 4))
    q[0, 0] = 1.0
    for tot in range(6):
        for b in range(4):
            s = tot - b
            if not (0 <= s <= 2) or (b, s) == (3, 2):
                continue
            sg = sigma[b, s]
            p_strike = 2*sg - sg*sg*(1+p)
            p_ball = (1 - sg)**2
            q[b, s+1] += q[b, s] * p_strike
            q[b+1, s] += q[b, s] * p_ball
    return q[3, 2], sigma, V

q0, _, V = solve(0.5)
print(f"At p = 0.5: q = {q0:.6f},  V(0,0) = {V[0,0]:.6f}")

At p = 0.5: q = 0.184180,  V(0,0) = 0.919179

A quick sanity check at — half of swung-at strikes leave the park, which is way too generous for the pitcher. The batter’s expected score should be high, and reaching full count should be unlikely. Both come out as expected.

Optimising

We want . It’s a one-dimensional problem and is smooth on , so Brent’s method on the interior is more than enough.

from scipy.optimize import minimize_scalar
from mpmath import mp, mpf

res = minimize_scalar(
    lambda p: -solve(p)[0],
    bounds=(1e-6, 1 - 1e-6),
    method="bounded",
    options={"xatol": 1e-13},
)
p_star = res.x
q_star = -res.fun
print(f"p* = {p_star:.12f}")
print(f"q* = {q_star:.12f}")
print(f"Submission: q* = {q_star:.10f}")

p* = 0.226973229098
q* = 0.295967993374
Submission: q* = 0.2959679934

To ten decimal places, , attained near .

Monte Carlo gut-check

Before I trust either the recursion or the optimiser, I want to play a few hundred thousand at-bats at the optimal and the equilibrium , and see the empirical full-count rate land on .

rng = np.random.default_rng(20251004)

def simulate(p, sigma, n=400_000):
    full = 0
    for _ in range(n):
        b = s = 0
        while b < 4 and s < 3:
            if (b, s) == (3, 2):
                full += 1
                break
            sg = sigma[b, s]
            t = rng.random() < sg     # pitcher throws strike with prob sigma
            sw = rng.random() < sg    # batter swings with prob sigma
            if not t and not sw:
                b += 1
            elif t and not sw:
                s += 1
            elif not t and sw:
                s += 1
            else:
                if rng.random() < p:
                    break             # home run
                s += 1
    return full / n

_, sigma_star, _ = solve(p_star)
print(f"Empirical q at p* : {simulate(p_star, sigma_star):.4f}")
print(f"Analytic  q at p* : {q_star:.4f}")

Empirical q at p* : 0.2962
Analytic  q at p* : 0.2960

The two agree to within Monte Carlo noise. Good — both halves of the solver are honest.

A picture of the optimum

import matplotlib.pyplot as plt

ps = np.linspace(0.01, 0.99, 200)
qs = np.array([solve(pp)[0] for pp in ps])

fig, ax = plt.subplots(figsize=(7, 5))
ax.plot(ps, qs, color="#1f77b4", lw=2)
ax.axvline(p_star, color="black", lw=0.8, ls="--", alpha=0.7)
ax.axhline(q_star, color="black", lw=0.8, ls="--", alpha=0.7)
ax.plot([p_star], [q_star], "ko", ms=6)
ax.annotate(
    f"$p^\\star \\approx {p_star:.4f}$\n$q^\\star \\approx {q_star:.10f}$",
    xy=(p_star, q_star), xytext=(p_star + 0.15, q_star - 0.04),
    arrowprops=dict(arrowstyle="->", color="black", lw=0.8),
)
ax.set_xlabel("home-run probability $p$ on a swung strike")
ax.set_ylabel("probability of reaching full count")
ax.set_xlim(0, 1)
ax.set_ylim(0, max(qs) * 1.1)
ax.grid(True, alpha=0.3)
plt.savefig("thumbnail.png", dpi=110, bbox_inches="tight")
plt.show()

The shape makes sense. As , batters never bother swinging and pitchers always throw strikes, so at-bats end in three pitches (strikeouts) — full counts are rare. As , every swung strike is a home run; batters swing freely and at-bats end fast for the other reason. The sweet spot for length sits in between, just below .

What made it nice

The trick was the symmetry. Once you spot that, every state collapses to a one-variable indifference equation, and the value recursion fits in a few lines of code. Wrapping it in a 1D optimiser over does the rest.

The official Jane Street solution follows the same backward-induction-plus-1D-search and lands on the same answer, .

Reading the rules

Speeds are independent uniform on . A pass between two cars with speeds does one of three things, depending on where sits:

• : both in the slow lane. The slower car must brake to and stop on the shoulder.
• : both in the fast lane. The slower car brakes to and changes lanes.
• : different lanes, no interaction.

Constant deceleration of mi/min² means braking from speed down to target speed takes time . The distance you would have covered at speed minus the distance you actually covered (a triangle of base and height , plus a matching acceleration triangle on the way back up — actually, let me just compute it).

If you cruise at for time you travel . If you instead brake linearly to (takes minutes, average speed , distance ) and accelerate back (same), you travel . So the lost distance is

Lost distance . Sanity check the puzzle’s worked examples:

• Slow lane, braking to : cost mile. The puzzle says “exactly mile”. Match.
• Fast lane, , : cost miles. Match.

How often two cars meet

This is the tricky bit and it’s where I got stuck for a while. A car’s speed alone doesn’t tell you how many other cars it meets — a fast car catches more slow cars per minute, and it spends less time on the road for a given trip length . Both effects matter.

Fix the faster car at speed and trace its journey from to in space. A second car at speed is overtaken iff it starts at a that puts it on a collision course inside the highway. That set of starts is a parallelogram with sides parallel to the two cars’ worldlines.

Two of its sides are the -car’s worldline (length , slope ) and a translate of the -car’s worldline (slope ). The cross-product / shoelace formula gives the area as

Since trip starts arrive uniformly at rate per (mile minute), the expected number of -speed cars overtaken (per ) is . The factor and the rate both factor out of the optimisation — they don’t depend on — so we can drop them.

import numpy as np
import matplotlib.pyplot as plt

N, u, v = 1.0, 1.1, 1.8
fig, ax = plt.subplots(figsize=(7, 5))

# v-car worldline from (0,0) to (N, N/v)
ax.plot([0, N], [0, N/v], color="#d62728", lw=2.2, label=f"$v$-car ($v={v}$)")
ax.annotate("", xy=(N, N/v), xytext=(0, 0),
            arrowprops=dict(arrowstyle="->", color="#d62728", lw=2.2))

# Parallelogram of u-car starts: corners at (0,0), (N, N/v), (N, N/v - N/u + N/u) ... let's compute
# u-car starts at (x0, t0) and reaches (x0 + N, t0 + N/u). For an overtake in [0,N], we need
# the u-car's worldline to cross the v-car's worldline somewhere in distance [0, N].
# Parametrise: at time t, v-car at v*t, u-car at x0 + u*(t - t0). Equal => t = (x0 - u t0) / (v - u).
# Want 0 <= v*t <= N. The start region is a parallelogram.
corners = np.array([
    [0, 0],
    [N, N/v],
    [N - N*u/v, N/v - N/u],   # actually let's just shade by enumeration below
    [-N*u/v + 0, -N/u],
])

# Shade by sampling
xs = np.linspace(-1.2, 1.2, 600)
ts = np.linspace(-1.2, 1.0, 600)
X, T = np.meshgrid(xs, ts)
# u-car at speed u starting at (X, T) reaches highway position v*tt at time tt where
# X + u*(tt - T) = v*tt  =>  tt = (X - u*T) / (v - u)
tt = (X - u*T) / (v - u)
pos = v * tt
mask = (pos >= 0) & (pos <= N) & (tt >= T) & (tt - T <= N/u)
ax.contourf(X, T, mask.astype(float), levels=[0.5, 1.5], colors=["#1f77b4"], alpha=0.25)

# Draw a sample u-car worldline through the parallelogram
x0, t0 = -0.3, -0.2
ax.plot([x0, x0 + N], [t0, t0 + N/u], color="#1f77b4", lw=1.6, ls="--",
        label=f"$u$-car ($u={u}$)")

ax.axhline(0, color="black", lw=0.4)
ax.axvline(0, color="black", lw=0.4)
ax.axvline(N, color="black", lw=0.4, ls=":")
ax.set_xlabel("distance")
ax.set_ylabel("time")
ax.set_xlim(-1.2, 1.2)
ax.set_ylim(-1.1, 0.9)
ax.legend(loc="upper left")
ax.grid(True, alpha=0.3)
plt.savefig("thumbnail.png", dpi=110, bbox_inches="tight")
plt.show()

The objective

Putting the rate and the cost together, the expected lost distance per pass (up to constants that don’t depend on ) is

Both integrals are over pairs in the appropriate lane, weighted by the parallelogram area and the cost with or .

Doing the inner integrals

The inner integral over is elementary:

So the slow-lane piece is

And the fast-lane piece is

Differentiating with Leibniz

We want . Both pieces have in their limits and in the integrand, so Leibniz’s rule is the right tool.

Slow lane. The boundary term at is . So

Fast lane. The boundary term at is . So

The first term in the bracket is a polynomial in (after dividing); the second yields to integration by parts with . Dropping the algebra,

Setting and tidying gives the optimality condition

A transcendental equation, but a tame one — the LHS is a cubic and the RHS is the cubic times (which is negative on ). One root in .

Solving numerically

from mpmath import mp, mpf, log, findroot

mp.dps = 30

def foc(a):
    a = mpf(a)
    return 16*a**3 - 24*a**2 - 15*a + 2 - 6*a*a*(a + 4)*log(a/2)

a_star = findroot(foc, mpf("1.18"))
print(f"a* = {mp.nstr(a_star, 15)}")
print(f"Submission: {mp.nstr(a_star, 11)}")

a* = 1.17714141681551
Submission: 1.1771414168

To ten decimal places, .

Monte Carlo gut-check

Before I trust either the cost formula or the rate, I want to see them line up with a simulation. I drop pairs of speeds, simulate every pass under the rules, and average the lost distance — weighted by the parallelogram-area rate so the base rate is honest too.

import numpy as np

rng = np.random.default_rng(20250704)

def expected_loss(a, N=400_000):
    u = rng.uniform(1, 2, N)
    v = rng.uniform(1, 2, N)
    lo = np.minimum(u, v)
    hi = np.maximum(u, v)
    rate = 1/lo - 1/hi
    cost = np.where(
        hi <= a, lo**2,
        np.where(lo >= a, (lo - a)**2, 0.0),
    )
    return float(np.mean(rate * cost))

for a in [1.10, 1.1771414168, 1.25, 1.40]:
    print(f"a = {a:.10f}: J = {expected_loss(a):.6f}")

a = 1.1000000000: J = 0.007327
a = 1.1771414168: J = 0.006015
a = 1.2500000000: J = 0.007328
a = 1.4000000000: J = 0.018900

The minimum sits firmly at , exactly where the FOC says it should.

A picture of the cost

import numpy as np
import matplotlib.pyplot as plt
from scipy.integrate import dblquad

def J(a):
    j1, _ = dblquad(lambda v, u: u*u*(1/u - 1/v), 1, a, lambda u: u, lambda u: a) if a > 1 else (0, 0)
    j2, _ = dblquad(lambda v, u: (u-a)**2*(1/u - 1/v), a, 2, lambda u: u, lambda u: 2) if a < 2 else (0, 0)
    return j1 + j2

aa = np.linspace(1.001, 1.999, 80)
vals = np.array([J(a) for a in aa])
a_star = 1.1771414168

fig, ax = plt.subplots(figsize=(7, 5))
ax.plot(aa, vals, color="#1f77b4", lw=2)
ax.axvline(a_star, color="black", lw=0.8, ls="--", alpha=0.7)
ax.plot([a_star], [J(a_star)], "ko", ms=6)
ax.annotate(
    f"$a^\\star \\approx {a_star:.10f}$",
    xy=(a_star, J(a_star)), xytext=(a_star + 0.1, J(a_star) + 0.005),
    arrowprops=dict(arrowstyle="->", color="black", lw=0.8),
)
ax.set_xlabel("lane speed $a$")
ax.set_ylabel("expected lost distance per pass (up to constant)")
ax.grid(True, alpha=0.3)
plt.show()

The curve is convex with a single interior minimum. As the slow-lane region shrinks but every slow-lane pass still costs almost a full mile. As the fast-lane region shrinks but fast-lane passes get expensive because the slower car has to brake far. The optimum balances those two costs.

What made it nice

The trick was untangling the rate from the cost. Once I drew the parallelogram, the base rate for a pair of speeds fell out and the rest was a calculus exercise. Constant-acceleration kinematics give a clean for the cost, and Leibniz’s rule keeps the differentiation honest even with inside the limits.

The official Jane Street solution follows the same path and lands on the same answer, .

What we’re really being asked

The tree is infinite, complete, and binary: every node has exactly two children, forever. Each node is independently labeled (probability ) or (probability ). A path down the tree starts at the root and, at each step, picks one of the two children — so a path is an infinite sequence of nodes.

“Sum at most ” means the labels along the path add up to . Since labels are or , that’s the same as saying the path uses at most one node labeled .

Define two events on the subtree rooted at any given node:

• = “some infinite path down this subtree has sum ” (at most one ),
• = “some infinite path down this subtree has sum ” (all s).

Let and . Both are well-defined: every node’s subtree is statistically identical to every other node’s subtree, so the probabilities don’t depend on which node you root at. The puzzle asks for the that makes .

Setting up the recursion

The trick is to condition on the root’s label and on the two child subtrees. The two children are independent copies of the whole tree, so their events are independent of each other and of the root.

Equation for . A subtree contains an all-zero path iff (i) the root is , and (ii) at least one of the two child subtrees contains an all-zero path.

Equation for . A subtree contains a “ ones” path iff:

• the root is (probability ), and a child subtree continues with a ones path — at least one of the two children must succeed, so probability ; or
• the root is (probability ), in which case the path has already used its one , and a child subtree must continue with an all-zero path — probability .

That’s the whole setup. Now we have to solve.

Picking the right branch

The first equation factors as , so

Both are honest fixed points. Which one is the actual probability?

This is a classical Galton–Watson survival question in disguise. Walk down the tree taking only -labeled nodes; at each step you have , , or surviving children, with mean . The branching process survives forever with positive probability iff its mean offspring is , i.e. . Below that threshold the all-zero path dies out almost surely and . Above it, the survival probability is the non-trivial root, .

A puzzle with answer “exactly ” can’t live in the regime (we’ll see why momentarily), so we take

The cubic

Substitute that into the equation for . First simplify :

So the -equation becomes

Setting (the puzzle’s condition), so :

Multiply through by :

Expand the last term: . Collecting,

A cubic in . The puzzle says “find to 10 decimal places,” so we just need its root in .

Monte Carlo gut-check

Before I trust the cubic, I want to see the recursion match a simulation. Sampling an infinite tree is impossible, but the path either “fails” within the first few dozen levels or it doesn’t — at depth around 100, the probability of a -ones path of length is already indistinguishable from the limit at the precision we care about.

import numpy as np

def survives(p, depth, k, rng):
    """Does some path of length `depth` use at most k ones, under labelling p?"""
    if depth == 0:
        return True
    label = 0 if rng.random() < p else 1
    if label == 1:
        k -= 1
        if k < 0:
            return False
    return (
        survives(p, depth - 1, k, rng)
        or survives(p, depth - 1, k, rng)
    )

import sys
sys.setrecursionlimit(5000)

rng = np.random.default_rng(20250403)
p_star = 0.5306035754
N, depth = 5000, 120
hits = sum(survives(p_star, depth, 1, rng) for _ in range(N))
print(f"Monte Carlo at p = {p_star}: {hits / N:.4f}  (target 0.5)")

Monte Carlo at p = 0.5306035754: 0.5008  (target 0.5)

The simulator does the recursion the same way the math does — try the left subtree, and if that fails, try the right. With 5,000 trials at depth 120 the estimate sits around , exactly as the analytic answer demands.

Solving the cubic exactly

sympy solves it symbolically. Three real roots fall out; only one of them lies in .

from sympy import Rational, solve, sqrt, simplify, cbrt, nsimplify, latex
from sympy.abc import p

cubic = 3*p**3 - 10*p**2 + 12*p - 4
roots = solve(cubic, p)
for r in roots:
    val = complex(r.evalf())
    if abs(val.imag) < 1e-10 and 0.5 < val.real < 1:
        p_root = r
print("Exact root:")
print(p_root)
print()
print(f"Decimal:    {p_root.evalf(15)}")
print(f"Submission: {p_root.evalf(11)}")

Exact root:
-(134/27 + 2*sqrt(57)/3)**(1/3)/3 + 8/(27*(134/27 + 2*sqrt(57)/3)**(1/3)) + 10/9

Decimal:    0.530603575430005
Submission: 0.53060357543

Tidied up, the closed form is

That comes out of Cardano’s formula applied to the depressed cubic; it’s not pretty, but it’s exact. To ten decimal places,

A picture of the bifurcation

The reason picking the right branch matters is best seen as a graph. Plot and as functions of :

• For , the branching process dies. Both and are .
• For , the non-trivial fixed points kick in and rise smoothly toward as .

The puzzle’s answer is the at which the red curve crosses .

import numpy as np
import matplotlib.pyplot as plt

ps = np.linspace(0, 1, 600)
b = np.where(ps > 0.5, 2 - 1/np.where(ps > 0, ps, 1), 0.0)
b = np.clip(b, 0, 1)

# a satisfies a = p a(2-a) + (1-p) b(2-b); solve the quadratic in a per p.
def a_of(p, b):
    if p <= 0.5:
        return 0.0
    # p a^2 - (2p - 1) a + (1-p) b (2-b) wait — rearrange:
    # a = p a (2 - a) + (1-p) b (2-b)
    # a - 2p a + p a^2 = (1-p) b (2 - b)
    # p a^2 - (2p - 1) a - (1-p) b (2-b) = 0
    A, B, C = p, -(2*p - 1), -(1 - p) * b * (2 - b)
    disc = B*B - 4*A*C
    r1 = (-B - np.sqrt(disc)) / (2*A)
    r2 = (-B + np.sqrt(disc)) / (2*A)
    # Pick the root in (0, 1] — the one that grows continuously from 0 at p = 0.5.
    return r1 if 0 <= r1 <= 1 else r2

a = np.array([a_of(pp, bb) for pp, bb in zip(ps, b)])
p_star = 0.5306035754

fig, ax = plt.subplots(figsize=(7, 5))
ax.plot(ps, a, color="#d62728", lw=2, label=r"$\Pr(A)$ — at most one 1")
ax.plot(ps, b, color="#1f77b4", lw=2, label=r"$\Pr(B)$ — all zeros")
ax.axhline(0.5, color="black", lw=0.8, ls="--", alpha=0.6)
ax.axvline(p_star, color="black", lw=0.8, ls="--", alpha=0.6)
ax.plot([p_star], [0.5], "ko", ms=6)
ax.annotate(
    f"$p^\\star \\approx {p_star}$",
    xy=(p_star, 0.5), xytext=(p_star + 0.04, 0.42),
    arrowprops=dict(arrowstyle="->", color="black", lw=0.8),
)
ax.set_xlabel("$p$ (probability a node is labelled 0)")
ax.set_ylabel("survival probability")
ax.set_xlim(0, 1)
ax.set_ylim(0, 1)
ax.set_aspect("equal")
ax.grid(True, alpha=0.3)
ax.legend(loc="upper left")
plt.savefig("thumbnail.png", dpi=110, bbox_inches="tight")
plt.show()

What made it nice

Two ideas carried the whole solution. First, fixing on the right event — “the subtree rooted here contains a good path” — turned an infinite-tree question into a recursion of one variable per event. Second, recognising the all-zero path as a Galton–Watson process picked the right branch of the quadratic without any hand-waving, and gave a clean threshold at .

The puzzle is a nice miniature for a more general technique: whenever you have a self-similar random structure, write down the probability of an event in terms of its restriction to the children, solve the resulting fixed-point equation, and use a separate principle (here, sub-/super-criticality) to pick the physically meaningful root. The same recipe handles “is there an infinite open path?” in percolation on a tree — the puzzle’s is exactly the percolation probability with parameter .

The official Jane Street solution follows the same path and lands on the same cubic and the same root, .

Reading the condition

Place the square as . Call the blue point and the red point . Let be the side of closest to .

The puzzle asks for the probability that some satisfies .

The set of points equidistant from and is the perpendicular bisector of segment . So the condition is:

The perpendicular bisector of crosses the closest side .

Equivalently: the two endpoints of lie on opposite sides of the bisector. Translating “side of the bisector” back to distance, that means one endpoint is closer to and the other is closer to .

That is the form I’ll use.

Cutting the work down with symmetry

The square has 8-fold dihedral symmetry. By rotating and reflecting, I can assume lives in one specific octant — the lower triangle below the line with :

In this octant the closest side is the bottom edge from to . Its endpoints are the two corners and .

By the law of total probability,

The factor 8 absorbs the symmetry.

A tale of two circles

For a fixed , the event becomes:

• is closer to than to , and is closer to than to , or
• the same with and swapped.

“ is closer to than to ” means is outside the circle centered at that passes through . Call those circles and :

So the favourable region for is the symmetric difference of the two disks, intersected with :

where is the disk bounded by .

Let me draw it.

import numpy as np
import matplotlib.pyplot as plt
from matplotlib.patches import Circle, Rectangle
from matplotlib.path import Path
from matplotlib.patches import PathPatch

x, y = 0.35, 0.18
r0 = np.hypot(x, y)
r1 = np.hypot(1 - x, y)

fig, ax = plt.subplots(figsize=(6, 6))
ax.add_patch(Rectangle((0, 0), 1, 1, fill=False, lw=1.5, ec="black"))

theta = np.linspace(0, 2 * np.pi, 400)
def disk_in_square(cx, cy, r):
    u = cx + r * np.cos(theta)
    v = cy + r * np.sin(theta)
    return np.clip(u, 0, 1), np.clip(v, 0, 1)

# Shade D0 \ D1 and D1 \ D0 by sampling the unit square
gx, gy = np.meshgrid(np.linspace(0, 1, 600), np.linspace(0, 1, 600))
in0 = gx**2 + gy**2 <= r0**2
in1 = (gx - 1) ** 2 + gy**2 <= r1**2
sym_diff = in0 ^ in1
ax.imshow(
    sym_diff, extent=(0, 1, 0, 1), origin="lower",
    cmap="Blues", alpha=0.35, aspect="equal",
)

ax.add_patch(Circle((0, 0), r0, fill=False, ec="#1f77b4", lw=1.2))
ax.add_patch(Circle((1, 0), r1, fill=False, ec="#1f77b4", lw=1.2))
ax.plot([x], [y], "o", color="blue", ms=8)
ax.annotate("B", (x, y), xytext=(8, 8), textcoords="offset points")
ax.plot([0, 1], [0, 0], color="black", lw=2.5)
ax.text(0.5, -0.05, "closest side $\\ell$", ha="center", va="top")

ax.set_xlim(-0.05, 1.05)
ax.set_ylim(-0.1, 1.05)
ax.set_aspect("equal")
ax.set_xticks([0, 1]); ax.set_yticks([0, 1])
plt.savefig("thumbnail.png", dpi=110, bbox_inches="tight")
plt.show()

Quick Monte Carlo gut-check

Before grinding through an integral I always like to run the simulation. If the analytic answer disagrees with a million random trials, the analytic answer is wrong.

rng = np.random.default_rng(20241201)
N = 1_000_000

B = rng.random((N, 2))
R = rng.random((N, 2))

# Closest side of B: 0=bottom, 1=top, 2=left, 3=right.
dists = np.stack([B[:, 1], 1 - B[:, 1], B[:, 0], 1 - B[:, 0]], axis=1)
side = np.argmin(dists, axis=1)

# Reflect/rotate so that the closest side is always the bottom.
# Equivalent to working in the octant — but here I just transform B and R together.
Bp, Rp = B.copy(), R.copy()
top = side == 1
Bp[top, 1] = 1 - Bp[top, 1]; Rp[top, 1] = 1 - Rp[top, 1]
left = side == 2
Bp[left] = Bp[left, ::-1]; Rp[left] = Rp[left, ::-1]
right = side == 3
Bp[right] = Bp[right, ::-1]; Rp[right] = Rp[right, ::-1]
Bp[right, 1] = 1 - Bp[right, 1]; Rp[right, 1] = 1 - Rp[right, 1]

# Two-circles condition: R inside one disk and outside the other.
in0 = Bp[:, 0] ** 2 + Bp[:, 1] ** 2 >= Rp[:, 0] ** 2 + Rp[:, 1] ** 2
in1 = (1 - Bp[:, 0]) ** 2 + Bp[:, 1] ** 2 >= (1 - Rp[:, 0]) ** 2 + Rp[:, 1] ** 2

estimate = float(np.mean(in0 ^ in1))
print(f"Monte Carlo (N = {N:,}): {estimate:.6f}")

Monte Carlo (N = 1,000,000): 0.491470

That gives . Now the closed form.

The integrand, geometrically

Two convenient facts about the octant :

1. Both radii satisfy throughout the octant. (Worst case for is , where — but in the octant , so , and a quick check shows whenever .) That means each disk’s intersection with is a clean quarter disk:

2. The two disks meet at and at its reflection below the -axis. Inside we only see the upper half of the lens. Its area splits cleanly into two circular segments, one carved off each disk by the vertical chord :

   where, using the sector area formula minus a triangle,

Putting it together,

Closed form via sympy

sympy handles the double integral exactly.

from sympy import Rational, atan, integrate, pi, log, simplify, latex
from sympy.abc import x, y

us = [x, 1 - x]
radii_sq = [u**2 + y**2 for u in us]
angles = [atan(y / u) for u in us]
slices = [(rsq * a - u * y) / 2 for u, rsq, a in zip(us, radii_sq, angles)]
quarter = [pi * rsq / 4 for rsq in radii_sq]

p_xy = sum(quarter) - 2 * sum(slices)
prob = simplify(8 * integrate(p_xy, (y, 0, x), (x, 0, Rational(1, 2))))
prob

print(f"Closed form: {prob}")
print(f"Decimal:     {prob.evalf(15)}")
print(f"Submission:  {prob.evalf(11)}")

Closed form: -log(2)/6 + 1/12 + pi/6
Decimal:     0.491407578838308
Submission:  0.49140757884

Tidying the symbolic answer:

To ten decimal places, 0.4914075788.

The Monte Carlo estimate above lands within 0.001 of this — consistent with the standard error of a million-sample Bernoulli.

What made it nice

Two moves did most of the work. First, restating “perpendicular bisector hits the side” as “one corner closer to , the other closer to ” turned a metric question into a region-membership question. Second, the 8-fold symmetry collapsed the problem to a single octant, where the geometry is clean enough that every relevant area is either a quarter disk or a circular segment.

The official Jane Street solution follows the same path and arrives at the same closed form, .