Eleven years
of puzzles

Project Euler, one problem at a time.

Vikas Munshi

Add up every number below 1,000 that is a multiple of 3 or 5.

Problem 1. Take thirty seconds.

The obvious way stops working

Counting one by oneThe clever way

Project Euler: 1,013 puzzles and one rule

Problem 1: Multiples of 3 or 5

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Find the sum of all the multiples of 3 or 5 below 1,000.

Answer:

Maths puzzles that need a computer to finish, a new one most weeks.
Every answer is a single number, and the site checks it.
The rule: solve it yourself, and share answers only for the first 100.
Problem 1 has been solved by 853,325 people. Problem 0, by 0.

On 2 July 2015, I solved my first one.

It took ten years to reach 100, and twelve months to go from 100 to 300.

2015 0 solved

EasierHarder

Harder problems, fewer people

The higher the level, the fewer I've solved

How many people have solved it?

Every problem with a difficulty rating, one dot each; mine in colour. The newest have no rating yet.

Two long pauses, then a surge

What changed:
I built a framework

The story behind the solver

Every feature began as a problem I ran into.

Keep private solutions private, in a public repository

~~Encrypted strings in the code~~needed its own loader ~~Encrypted .enc files~~checked out, checked back in A git filterplain text at work, ciphertext in git
Keep the key safe, and don't lose it (I did, more than once)

Every machine holds its own sealed copy, and any holder can pass it on, whole or in two halves.
Do the old solutions still work after an update?

Each keeps its test cases and answer; one line re-checks them all: loop {solved}: eval {loop.number}
A new machine: GitHub holds the code, not the setup

One command builds the rest: make install-all, from system packages to git hooks.
Code that stays right, and can be rewritten

mypy and flake8 on every commit, docs generated from the code; each time the framework changed shape, code transformers rewrote every solution.
Turn solutions into knowledge

An explanation beside every solution, tags by technique, articles linking problems, and a website to read them.

Space highlights one row at a time. The left side is the problem as I met it; the right is what the solver does about it now.

Encryption went through three designs. Encrypting strings inside the code needed a custom loader to run anything. Encrypted .enc files beside the code needed a checkout and check-in step, and a lock to go with it. Now a git filter encrypts on the way into git and decrypts on the way out, so I never see ciphertext while I work.

The key: I lost it more than once. Now each machine keeps its own copy, sealed to that machine's key; any holder can issue it to another machine (key-export, or over the message spool), or split it in two halves (key-split, key-reconstruct) so no single message carries all of it.

Old solutions: every solution has test cases with recorded answers, so after a package upgrade one loop re-runs them all. The runner gives every solution the same contract, which is what makes that loop possible.

A new machine: a one-line install script clones the repository and runs make install-all, which sets up the system packages, the Python environment, git hooks, tab completion, Chrome and Claude Code. Secrets stay outside the repository, in ~/.euler.

Code quality: every commit passes mypy and flake8 (the git hooks refuse otherwise), and autoflake, isort and black tidy each new solution. Transformability: the framework changed shape more than once (the runner, the decorators, the signature of solve()), and each time I wrote code transformers that rewrote every existing solution rather than editing hundreds by hand. Consistent code is what makes that possible. And the reference docs (the command index, the package layout, the tooling reference) are generated from the code by update-docs, so they say what the code does, not what it once did.

Knowledge: the explanations, tags and articles are counted on the previous slide.

From problem to solution

1Fetchsummary
2Set upnew 7
3Writesolve()
4Checkeval 7
5Measurebenchmark 7
6Keepgit-commit 7

Problem 7: 10 001st Prime · answer 104,743
The problem: Listing the primes 2, 3, 5, 7, 11, 13, the 6th is 13. What is the 10,001st?
The solution: A Sieve of Sundaram: cross out every index of the form i + j + 2ij; each surviving index k stands for the odd prime 2k + 1. Sieving indices up to n·ln n covers numbers up to about 2n·ln n, safely past the n-th prime, and the (n − 1)-th odd prime is the answer.

Space steps through the six stages for Problem 7, "What is the 10,001st prime number?". The framework is called solver: a shell of commands, plus the runner every solution plugs into.

The worked example (the 6th prime is 13) comes from the problem statement, so it's fine to show. The answer stays off the slide; it's in these notes if asked.

The point for a general audience: I still solve each problem myself; the framework does the fetching, checking, timing and keeping, the same way every time.

Crossing out: the sieve

Problem 10: Summation of Primes · answer 142,913,828,922
The problem: Find the sum of all the primes below two million.
The solution: A Sieve of Eratosthenes up to two million, then add up the survivors. Five versions are kept: Eratosthenes, Sundaram, an incremental sieve, trial division (the slow side of the race on the slide), and the primesieve library.

Press Space for each step: 2, 3, 5 and 7 cross out their multiples, then the survivors light up. The last step races both methods below two million, live on this laptop. ← steps back; R replays the current step.

Below two million: 4,347,776 cross-outs against 179,492,731 divisions, about 41× less work. In Python it's 0.3 s against 19 s.

The point for a general audience: we found primes without ever dividing. Doing the work in a smarter order beats doing it faster.

Counting without walking

Grid	Routes
2 × 2	6
3 × 3	20
4 × 4	70
10 × 10	184,756
20 × 20	over 100 billion

Problem 15: Lattice Paths · answer 137,846,528,820
The problem: Starting at the top-left corner of a 20 × 20 grid and moving only right or down, how many routes reach the bottom-right corner?
The solution: Every route is 40 moves, 20 of them to the right, so a route is just a choice of which 20 moves go right: the central binomial coefficient C(40, 20) = 40! / (20!)². A closed form, no search.

Space steps through: the six routes on a 2 × 2 grid, the table showing listing explode, the edge corners, the fill (each corner is the sum of above and left; the highlighted 6 = 3 + 3), the tilt into Pascal's triangle, and Problem 15's 20 × 20 grid shaded by route count.

The corner of the 6 × 6 grid reads 924. The last step says "over a hundred billion" on purpose; the exact number is in these notes if asked.

For a general audience this is dynamic programming without the name: remember small answers and build bigger ones from them.

Working from the bottom up

Problem 18: Maximum Path Sum I · answer 1,074
The problem: Find the largest total from top to bottom of a 15-row triangle of numbers, stepping each time to one of the two numbers just below.
The solution: Bottom-up dynamic programming: replace each number with itself plus the larger of the two below it, row by row from the bottom; the top then holds the answer. Each row is touched once.

Problem 67: Maximum Path Sum II · answer 7,273
The problem: The same question for a 100-row triangle, which has 2⁹⁹ paths: far too many to try one by one.
The solution: The same bottom-up fold as Problem 18, unchanged: one pass over 5,050 numbers.

Space steps through: the puzzle, trying all 8 paths (the best, 23, stays highlighted), the 100-row scale of Problem 67, then folding the small triangle from the bottom one row at a time until the top reads 23, and finally the 100-row triangle folding in one sweep.

The worked example is the one printed in Problem 18's statement, so 23 is fine to show. Both answers stay off the slide; they're in these notes if asked.

This is dynamic programming again, from the other direction: each row only needs the best results from the row below it.

A simple rule, a wild ride

Problem 14: Longest Collatz Sequence · answer 837,799
The problem: Halve n if even, otherwise make it 3n + 1, until it reaches 1. Which starting number under one million gives the longest chain?
The solution: Chain lengths are remembered as they are found, in a cache built fresh on every run, so a chain stops as soon as it meets a number already worked out. Only the upper half of the range is scanned: any x up to 500,000 has 2x still below the limit, and 2x's chain is one step longer, so x can never win.

Space steps through: the rule from 6, the wild ride from 27 (peak 9,232), the cloud of chain lengths up to 10,000, the open problem, what remembering saves (light bars are full chains, dark bars the part actually worked out), and the total below one million.

The scatter stops at 10,000 on purpose: Problem 14's answer is below one million and stays off the slide; it's in these notes if asked.

Below one million: 131,434,272 steps one at a time against 5,226,259 with the memory, counted offline in Python.

Too big for a calculator

Too many to try

Problem 96: Su Doku · answer 24,702
The problem: Solve all fifty Su Doku puzzles in the given file, and add up the 3-digit numbers in the top-left corner of each solution grid.
The solution: Kept three ways, all depth-first searches that prune hard: backtracking with fewest-candidates-first and forward checking, exact cover by Knuth's Dancing Links, and Norvig-style constraint propagation that deduces to a fixpoint before guessing.

Space steps through: Grid 01 (the statement's own example, 32 clues), every blank flickering through digits (9⁴⁹ boards), all nines (nonsense), then whole-board counts written out in full, shrinking rule by rule, and finally why listing them all is no way out.

The ladder: 9⁸¹ ≈ 2.0 × 10⁷⁷ with no rule; (9!)⁹ ≈ 1.1 × 10⁵⁰ with boxes; bands of rows and boxes are independent, 948,109,639,680 = 9! × 56 × 6⁶ each, so (that)³ ≈ 8.5 × 10³⁵ with rows; 6,670,903,752,021,072,936,960 ≈ 6.7 × 10²¹ with columns (Felgenhauer and Jarvis, 2005). Note the switch of framing: 9⁴⁹ counts fillings of this one puzzle, the ladder counts whole boards with no clues.

If asked about symmetry: relabelling digits, swapping rows within a band, bands, transposing and so on fold the count to 5,472,730,538 essentially different grids (Russell and Jarvis, 2006). That would fit on a disk, but a puzzle's clues are not in canonical form: matching them means unfolding the 1.2 trillion symmetries again.

The clues in the fifty grids range from 22 to 36, about 28 on average. The fewest clues any uniquely solvable puzzle can have is 17 (McGuire, Tugemann and Civario, 2012, by exhaustive computer search).

Deduce first, guess last

Approach	Grid 01	All fifty
Try every board	5.7 × 10⁴⁶	2.3 × 10⁵⁶
Backtrack, cell by cell	1,605 tries	11,011,447 tries
Deduce, then guess	no guesses	28 guesses

Solver	C	Python
Backtracking, fewest candidates first	6.4 ms	46 ms
Exact cover: Dancing LinksDonald Knuth, 2000	1.6 ms	54 ms
Constraint propagationafter Peter Norvig, 2006	1.0 ms	51 ms

Space steps through: Grid 01 with its candidates pencilled in (159 across 49 blanks), the deduction cascade (four waves of 15, 10, 13 and 11 placements; the candidates thin out as they go), the comparison with trying and plain backtracking, and the three kept solvers, with the top-left 483 from the statement highlighted.

The comparison was counted offline in Python. "Tries" are digit placements tested by plain backtracking (first blank, digits 1 to 9, check the 20 peers). "Guesses" are tentative placements made after propagation stalls; 40 of the 50 grids need none, and the hardest needs 7. Try every board for all fifty is the sum of 9 to the number of blanks, dominated by the grid with 59 blanks.

The timings are each solver's average over all fifty puzzles, from Problem 96's results.json (63 runs each); they are typed into the slide, so re-check them after a re-benchmark.

Literature: Donald Knuth, "Dancing Links" (2000): Algorithm X on exact cover, 324 constraint columns for Su Doku. Peter Norvig, "Solving Every Sudoku Puzzle" (2006): the two propagation rules plus fewest-candidates search. Yato and Seta (2003): Su Doku on n² × n² boards is NP-complete. Felgenhauer and Jarvis (2005): the count of valid grids.

The point for a general audience: when there are too many possibilities to try, use every rule to cut them down before trying anything.

An honour code, backed by a vault

One master key

Sealed copyMy laptop

Sealed copyMy web shell

Sealed copyA collaborator

Each copy opens only with its holder's own key.

Working with AI

What it helps with

Writing the explanation beside each solution
Translating a Python solution into C
Reviewing my work for mistakes
Drafting the blog articles

What it doesn't do

Publish anything I haven't read
Decide when an answer is right: the tests and the site do
Push its own work: it stops at a local commit, and I take it from there

Problem 15, solved by hand in 2019, before any AI

Its explanation, written later together with AI

@runner.main
def solve(*args: str) -> str:
    lattice_size = runner.parse_int(args[0])
    return str(math.factorial(2 * lattice_size)
               // math.factorial(lattice_size) ** 2)

“The crucial observation is that the geometry of the grid is irrelevant to the count: any valid path consists of exactly 2n unit steps, of which n must go right and n must go down. A path is fully determined by the order in which we interleave these two kinds of moves.”

Problem 15: Lattice Paths · answer 137,846,528,820
The problem: Starting at the top-left corner of a 20 × 20 grid and moving only right or down, how many routes reach the bottom-right corner?
The solution: Every route is 40 moves, 20 of them to the right, so a route is just a choice of which 20 moves go right: the central binomial coefficient C(40, 20) = 40! / (20!)². A closed form, no search.

Be candid: people are curious and a bit sceptical; own both.

The example is Problem 15: the solution was written by hand in 2019, before AI tools existed; the explanation beside it (solutions/public/p0015/notes.html) was co-written with AI later. The method is the 2019 one; the @runner.main wrapper around it came later, when every solution moved onto the runner framework. The passage stops before the answer.

Live: pick a problem

?

Call out a number from 1 to 100, or press Space to draw one.
I open it on the website and run it.
The answer and its timing appear there, not on this slide.

Small puzzles add up.

Start with Problem 1 at projecteuler.net.

Under the hood

For the developers in the room: how the framework is built.

~/euler ❯ solver

A solution is one function

p0007_s0.py

@runner.main
def solve(*args: str) -> str:
    """Sieve of Sundaram over [1, n·ln n] …"""
    n = runner.parse_int(args[0])
    if n == 1:
        return str(2)
    max_expected_value = int(n * math.log(n))
    numbers = list(range(0, max_expected_value + 1))
    for i in numbers[1:]:
        for j in range(i, max_expected_value + 1):
            try:
                numbers[i + j + 2 * i * j] = 0
            except IndexError:
                break
    return str(2 * [i for i in numbers if i != 0][n - 2] + 1)

p0007_s0.c

#include "runner.h"

const char *solve(int argc, char *argv[]) {
    static char _answer[32];
    int n = parse_int(argv[1]);
    …
    for (int i = 1; i <= max_expected_value; i++) {
        if (numbers[i] == 0) continue;
        for (int j = i; ; j++) {
            long long idx = (long long)i + j + 2LL * i * j;
            if (idx > max_expected_value) break;
            numbers[idx] = 0;
        }
    }
    …
    snprintf(_answer, sizeof _answer, "%lld", result);
    return _answer;
}

The runner owns everything else: the arguments, --runs=N timing, a consistency check, and one output line, <runs> <seconds> <answer>. Python and C share the contract, so either runs under the same eval and benchmark.

Benchmarks that don't lie

packages/solver/solver/runners/runner.py, the timed loop

for _ in range(runs):
    _start, _result, _stop = perf_counter(), solve(*args), perf_counter()
    elapsed.append(_stop - _start)
    if result is not None and _result != result:
        errors.append(f"Expected consistent result, got {_result} …")
    result = _result
…
print(f'{runs} {average} {result}')

--runs=N repeats solve() and reports the average.
Every run must return the same answer, or the exit code says so.

The warm-cache trap

# Built once, at import: free on every timed run after the first
PRIMES = primes_below(10**7)

@runner.main
def solve(*args: str) -> str:
    n = runner.parse_int(args[0])
    …

@runner.main
def solve(*args: str) -> str:
    n = runner.parse_int(args[0])
    # Built inside solve(), sized to the input: timed on every run
    primes = primes_below(bound_for(n))
    …

A small command language

What you type

What the lexer normalises it to

One decorator per command

packages/solver/solver/core/git.py

@register(requires='contributor', aliases=('commit',),
          quietable=True)
def git_commit(
    problem: Problem,
    *targets: Literal['solution', 'solutions', 'docs',
                      'blogs', 'update'],
    message: Annotated[str, Ask('Message', when=_is_not_amend,
                                multiline=True)] = '',
    amend: bool = False,
    reset: bool = False,
) -> int:
    """Stage and commit the named targets — the one commit verb."""

git_commit becomes git-commit; requires sets the lowest profile allowed.
problem: Problem takes a bare number or {next}, remembers it as the current problem, and fills it in when left out.
*targets: Literal[…]: any number of choices, checked and tab-completed.
Annotated[str, Ask(…)]: left out, the shell asks for it, but only when it applies (an amend keeps its message).
A bool becomes a flag; the return value is the exit code.

docs/commands-index.md, generated by update-docs

#### Command: `git-commit` (`commit`)

Stage and commit the named targets — the one commit verb.

* ⚑ needs contributor or above.
* ❏ uses/sets current problem.
* ✎ asks for anything you leave out.
* » supports --silent to suppress output.

**usage**
git-commit
[problem=<n>] (default current)
[solution|solutions|docs|blogs|update ...]
[message=<str>] (asked)
[amend=true|--amend]
[reset=true|--reset]
[silent=true|--silent]

Generated, never written: update-docs builds this index, the command catalogue, the package layout and the tooling reference from the live code.
Every full release reruns it, so the reference says what the code does now.

The signature is reformatted to fit the slide; the code is packages/solver/solver/core/git.py's git_commit. Functions stay plain Python: the decorator registers them, it doesn't transform them. Only one function in register.py knows about Annotated: it lifts the Ask out and hands everything else the plain type. Ask is on 24 parameters across the commands.

The problem parameter is the same current problem the {problem} variable holds on the previous slide, which is why eval alone re-runs the active problem. The docstring is the help text and the source of the generated docs; check-commands holds every docstring to one standard.

update-docs fills the marked blocks in the guides from the code itself: the registry (this index, the user guide's catalogue, the authorization table), the package tree (the README's layout), the Makefile's comments and each script's summary line (the tooling reference). scripts/ops/release.sh runs it on every full release, and update-docs --check reports anything stale.

One shell, three packages

euler_webshellthe web shell, the per-user service, the PTY, the message spool, solver-host

↓ imports

euler_sitethe content site and the auth service

↓ imports

solverthe solver shell: standalone, no web code at all

Dependencies point one way. layers.py fails any import that points up, on every commit.
A fourth package, euler_content, is data: the public tree the signed-out site serves.

packages/webshell/euler_webshell/shell/overlays.toml

[git-sync]          # after it returns, nudge the page:
emit = ["git"]      # OSC 5379 → the header's git chip

[summary]           # problems.json changed
emit = ["progress", "git"]

[show]              # swap the left pane, not a browser tab
replace = "euler_webshell.shell.viewer:show"

The web shell is the solver shell plus an Extension: more commands, a ticket for identity, and these overlays.
The solver shell never imports it, and never knows it is in a browser.

Encrypted at rest, plaintext at work

Working treeplaintext, as you edit it

clean: encrypt →← smudge: decrypt

Git objectsciphertext, as pushed

solutions/private/** filter=solver-crypt -text -diff

your passwordproven by SRP at sign-in, never sent derives PKArgon2id with the SRP salt, in the browser; it opens the vault unlocks ~/.euler/idthis machine's X25519 key, encrypted at rest unwraps enc-key.jsonthe master key, sealed to this machine gives AES-256 master keywhich decrypts every file

PasswordyouAccount page or vault change-password: a new SRP verifier and a new vault key, then every session signs out. A forgotten one is reset by mail, and the vault goes with it.

Private keyyouuser --regen (the account page's Regen): the master key moves to the new key, or a maintainer re-authorizes it.

Vault keyyour password changeReplaced on every password change, with the secrets re-encrypted under it; a reset destroys it.

Master keyan adminkey-rekey, the only revocation: every private file re-encrypted, the new key re-issued to each registered public key.

Deterministic: each file's nonce is an HMAC of its plaintext, so an unchanged file encrypts to the same bytes and git sees no change, while different text never reuses a nonce.

The chain starts at sign-in. SRP proves the password without sending it; the same password and the account's SRP salt also derive PK in the browser (Argon2id, 64 MiB of memory per guess, under its own label so it never equals the login's derivation). PK goes only to the user's own service, where it unwraps the vault key, and the vault key decrypts ~/.euler/id. So the private key that opens everything rests encrypted, and the web shell starts already unlocked without ever asking for a password. In a terminal, the same PK is derived from the password typed there. The design is docs/vault-guide.md.

Without the deterministic nonce, every checkout would re-encrypt every private file with a fresh random nonce, and git would report hundreds of changed files that nobody touched. The filter is packages/solver/solver/crypto/gitfilter.py, run as a long-lived git filter process. Nothing is decrypted in git itself; plaintext exists only in the working tree once the master key is available.

Who changes what. The password is the user's: a change on the account page (or vault change-password in a terminal) re-mints the SRP verifier and re-keys the vault: a fresh vault key, the secrets re-encrypted under it, wrapped under the new PK. Every session then ends, the changing one included, so nothing still holds the old vault key. There is deliberately no admin reset verb; a forgotten password is reset by mail, and since the old PK is gone the vault is destroyed with it (the data was unreachable the moment the password was forgotten). The private key is the user's too: user --regen mints a new pair and, if the old key could open the master key, re-wraps it to the new one with nobody involved; otherwise it files a key request for a maintainer's user-authorize. The vault key is never rotated by hand: first sign-in mints it, every password change replaces it, a reset destroys it. The master key is the admin's: key-rekey is the only thing that revokes anyone, re-encrypts every private file under a new key, and re-issues it over the message spool to every registered public key.

The lesson: enc-key.json used to be one tracked file holding every machine's entry, which caused a long run of merge conflicts. It is now machine-local, and a new holder gets their sealed copy over the message spool.

One service per collaborator

BrowserSRP-6a login: the password never leaves it

↓ TLS: a Let's Encrypt certificate over DNS-01, checked for renewal daily · dynamic DNS every 5 minutes

Caddystrips identity headers; signed-out reads go to the public site, everything else asks the auth service, then routes by X-User-Slug

↓ unix sockets under /run/euler

euler-sitethe public site: the packaged public tree, read-only, nothing private

euler-user@aliceown uid, home, clone, branch and vault; pages and the /ws terminal

euler-user@bobsame shape, fully separate

auth · messages · maileach on its own uid

↓ the only way out

Squid domain allowlist + per-uid nftableseach service reaches only what it needs

The design of record is docs/web-server-guide.md. Alice and Bob are placeholders. A visitor who isn't signed in reads the public site: the same content app over a packaged copy of the public tree, with no private files to leak. Everyone else is checked by the auth service on every request and routed to their own service. Those sockets belong to a group only the edge and the services are in, and each per-user service checks which uid is calling, so one collaborator cannot reach another's instance even from inside the host.

Each collaborator's keys are exposed only to their own code: separate uid, separate clone, separate encrypted vault. Their terminal is the web shell, the solver shell plus its web extension, run on a PTY and carried over a WebSocket. Outbound traffic goes through a domain allowlist and a per-uid firewall, which is where "the plaintext never leaves" is enforced on the network.

Reaching it at all: the host sits on a home connection, so a timer checks the public IP every five minutes and updates the DNS record when it changes. acme.sh, as its own non-root user, issues and renews the certificate through a DNS-01 challenge, so no inbound port 80 is ever opened; only 443 is forwarded.

Defence in depth

Login: SRP-6a: the password never crosses the wire; the server keeps only a verifier, made slow to guess with Argon2id. Reset and invite forms cost a proof of work.
Identity: The edge strips client identity headers; only the auth service sets them, and each service checks which uid is calling. A web shell starts from a single-use ticket.
Isolation: One uid, home, clone and branch per collaborator, behind sockets no other collaborator can open; every service in a systemd sandbox.
Secrets: Each user's keys in a password-derived vault (Argon2id, AES-GCM); private solutions ciphertext in git.
The way out: A domain allowlist and per-uid firewall rules, loopback included; mail through a relay holding its own credentials.
The page: A Content-Security-Policy with a fresh nonce per response: only the site's own scripts run, nothing from a CDN. The terminal obeys only its own shell's signals.

Shipping it

Conventional Commitsfeat:, fix:, docs: …

→

make releasebumps version.py, commits, tags, pushes

→

make redeploy-webrefuses unless the tag is on origin

Every commit

No whitespace errors or conflict markers
No build artifacts, gitignored or unencrypted private files
shellcheck on staged scripts; flake8; mypy, tests included
The layering check: no import points up

Every push, and on demand

The encryption and binary audits, on exactly the blobs pushed
flake8, mypy, and shellcheck over every tracked script
The full unit test suite, when code, scripts or tests change
make audit: the whole tree, on demand

Designs I built and threw away

Brokers for secrets: Services that held the API and git keys on behalf of a shared web user. One was built and working. Dropped once giving every collaborator their own user removed the need.
A checkout lock: A second lock on top of the workspace's own. It worked as designed and confused everyone, so it was reverted.
One shared key file: Every machine's sealed key in one tracked file: a long run of merge conflicts. Now each machine keeps its own.
Versions from git tags: Build-time version detection from git. Replaced by one tracked version.py that only the release script writes.

Thank you. Questions?

Ask about the puzzles, the maths, or the machinery.

Vikas Munshi. This deck lives in the project, at docs/presentation.