The Verification Venue · pointed at a number nobody can look up
A Hundred Billion Walks, One Number
Polymer physics courses draw a handful of tangled conformations and then quote the connective constant of the square lattice from the literature. This page does not quote it. It counts every self-avoiding walk, one at a time, up to length 22 on the square lattice and 32 on the honeycomb, on your machine, in front of you, and measures the constant from its own census.
Every one of the 883 immersive pages in this corpus computed what one JavaScript thread could compute while a reader waited, and questions whose honest answer cost more than about ten million operations were never proposed, because they could not be shown. This page runs a C engine compiled to WebAssembly across every core you have, with a slow, deliberately obvious second implementation standing beside it, and it refuses to show you a number until the two agree on small cases. Drag the slider first: something true is on screen within a second. Then press Run the census and watch the estimate settle.
Exact count, walks of length 7
computing…
Raw ratio c(n) / c(n−1)
·
Drag it up. The count is exact at every position: the engine enumerates every walk of that length while you drag. Past n = 12 the ratios look beautifully converged. They are lying.
Two passes: the census, then the same census under a completely different decomposition. Stopping reports a partial count, never an answer.
A self-avoiding walk is a path on a lattice that never visits a site twice. Let c(n) be the number of such walks of length n starting at the origin, with c(0) = 1: the empty walk is a self-avoiding walk. The counts grow geometrically, c(n) ≈ A·μⁿ·nᵍ, and μ, the connective constant, is the thing the whole field wants. Nobody has a closed form for it on the square lattice. What this page has is a census, and a partition that makes the census parallel without cheating: every walk of length n has exactly one prefix of length d, so handing prefixes to workers and letting each complete its own walks counts every walk exactly once, whatever d is and however many chunks there are.
The symmetry is spent honestly. The engine fixes the first step East and multiplies by 4, because the four rotations act freely on walks: the first step distinguishes them, so no walk is ever counted twice. The same argument gives 3 on the honeycomb. That fixing buys a theorem the engine was not written to produce: with the first step fixed, mirror-pairing leaves exactly one walk unmoved per length (the straight ray), so the fixed-first count is odd and c(n) ≡ 4 (mod 8) for every n ≥ 1. If the census ever violates that, the enumerator is broken, and the check panel below tests it at full size.
State
idle: the small case above is already exact
Chunks done
·
Steps (engine's own counter)
·
Elapsed
·
Workers
·
μ estimate (provisional)
·
Last lengths, exact (square | honeycomb)
| n | c(n) square | h(n) honeycomb |
|---|---|---|
| awaiting the census | ||
The constant is not the count, and getting from one to the other is where the honesty lives. Three estimators run on the same computed counts: the raw ratio c(n)/c(n−1); that ratio corrected pointwise for the power-law prefactor, with the exponent fitted from this page's own counts rather than quoted from a book; and a joint fit that estimates μ and the exponent together. At any finite n they converge to different places, and their spread is the honest uncertainty, not the last digit of the last ratio.
| square lattice | raw ratio | corrected | fitted μ | spread |
|---|---|---|---|---|
| awaiting the census | ||||
| honeycomb | raw ratio | corrected | fitted μ | vs exact √(2+√2) |
|---|---|---|---|---|
| awaiting the census | ||||
Then the estimator itself gets tested. On the honeycomb lattice the connective constant is exactly √(2 + √2), proved by Duminil-Copin and Smirnov (announced 2010). This page does not reproduce that proof and does not depend on it: it uses the exact value as a target for the estimator, the one place in this piece where a right answer exists to be missed. How far the honeycomb estimators sit from the exact value at n = 32 is a direct measurement of how much you should trust the square-lattice fit at n = 22, where no such target exists.
Census parameters, pinned for the verifier: square lattice to length 22, honeycomb to 32; prefix depth 8 with 256 chunks (main pass) and depth 5 with 97 chunks (check pass); symmetry factors 4 and 3; one-step walks: 4; the line lattice: exactly 2 at every length; honeycomb target √(2+√2) = 1.8477590650225735.
The check · every number recomputed in front of you
Both implementations ran the battery below in your browser before anything else was displayed. The engine column is the compiled C; the reference column is the slow, obvious JavaScript written from the same contract. Conventions for every count on this page: square lattice rooted at the origin, first step fixed East, times the 4 rotations; honeycomb likewise, times its 3 rotations; the origin is occupied before the first step in both implementations, so no walk ever revisits it, and c(0) = 1, the empty walk, with no symmetry factor.
| battery instance | engine fingerprint | reference fingerprint | verdict |
|---|---|---|---|
| running… | |||
…
A check that has never failed is a claim about the code, not evidence about it. Press the button: it breaks the reference on purpose, by deleting the occupancy check for the West direction, and the battery must go red.
Planted objects, in the data rather than the code, run through the same unmodified engine. One is the one-dimensional lattice, where the count is exactly 2 at every length. The other is a lattice with site (0,1) blocked, whose first counts are small enough to check by hand: c(0) = 1; c(1) = 3, because the blocked site lies directly north of the origin and the first step North is itself forbidden; c(2) = 9, because of the twelve two-step walks on the open lattice exactly three (NE, NW, NN) visit (0,1). An enumerator that cannot get the trivial lattice right has not been shown to get any lattice right. Both are asserted by the offline verifier.
full-size decomposition check: awaiting the census
full-size invariants: awaiting the census
The binary is not a black box. The page fetched engine.wasm, hashed what arrived, and refuses to run it unless the hash is the one the build pinned:
expected: …
…
The reproducible build is offline by nature: your browser has no compiler. The verifier rebuilds engine.c from source and demands byte-identical output, and skips honestly (printing SKIP, never PASS) when its clang differs from the pinned one. It also runs the cross-method breadth-first check to n = 12 on both lattices, the planted-object checks, and three negative controls on itself:
What none of this rules out: two decompositions agreeing rules out partition and boundary bugs and very little else; the invariants rule out asymmetric mistakes; the cross-method check reaches only length 12; and both implementations share the contract's partition rule, so a misunderstanding fixed in the contract would be shared. That a stranger should believe the big number rests on all of these together, and on the C being the code you can read.
Operations (counted, not estimated)
·
Wall time, both passes
·
Workers, and why that number
·
Against main-thread JavaScript
·
What's exact here, what's fitted, and what's idealised
Exactly true. Every count printed is an enumeration, not an estimate. The symmetry factors are theorems (free actions of the rotation groups). c(0) = 1: the empty walk is a self-avoiding walk, and no rotation moves it. c(n) ≡ 4 (mod 8) on the square lattice follows from the rotations plus the unique reflection-fixed straight ray. The honeycomb target √(2+√2) is a proved theorem this page uses as a yardstick and does not reproduce. The line lattice count of exactly 2 per length is immediate: on a line the visited sites form a contiguous interval and the head always has exactly one free neighbour.
Fitted, and labelled as this page's measurement. The square-lattice connective constant. The prefactor exponent is fitted from the page's own counts, not quoted. The interval is the spread of the three estimators and of refits over shorter windows: it is not a statistical confidence interval and must not be read as one. The strict rise c(n) > c(n−1) is checked at every length but stated as a measured regularity: the obvious proof is false, because walks can trap themselves, and this page will not pretend otherwise.
Idealised. The census is exact for the lengths it reaches and silent beyond them; the extrapolation to μ is a model of the asymptotics, and the whole point of the honeycomb panel is to show how much that model can still be off at n = 32. The speed factor in the cost panel is measured on a slice and scaled, and the slice fraction is printed beside it for exactly that reason.