DEV Community: Lucian (LKB)

Domain coloring: plotting complex functions f(z) in the browser

Lucian (LKB) — Sat, 19 Sep 2026 08:44:31 +0000

An ordinary graph maps a number to a number, so a curve fits on a flat screen. A complex function maps a plane to a plane — two inputs, two outputs, four dimensions — and there's no curve to draw.

So we do what mathematicians do on paper: we paint the plane. Here's how domain coloring works, the small evaluator behind it, and how it stays interactive in a browser tab without WebGL. Everything below is live in the free LK Forge graphing calculator — press f(z) and follow along.

Two numbers, two channels of colour

Every output f(z) is a complex number, and a complex number has exactly two visible parts: an angle (its argument) and a size (its modulus). Domain coloring spends one visual channel on each:

Hue = the argument of f(z) — red one way, cyan the opposite way, a full colour wheel for a full turn.
Brightness = the modulus — dark where f(z) is near zero, bright where it grows large.

That one rule makes the features that matter jump out. A zero is a dark spot with the whole colour wheel wrapped around it. A pole (where the function runs to infinity) is a bright spot, also ringed by every hue. Faint contour rings mark each doubling of the modulus, so you read growth like a topographic map reads elevation.

The evaluator: the same parser, a different number

The 2D graph and the complex plane share one expression parser — a shunting-yard compiler with no eval() anywhere. The only thing that changes is what sits on the evaluation stack:

Real graph → the stack holds ordinary numbers.
f(z) → the stack holds {re, im} pairs, and each operator does complex arithmetic.

The imaginary unit i is just the constant {re: 0, im: 1}, and every function gets its principal-branch definition, so the identities you'd check by hand come out exactly right:

i²      = -1
√(-1)   = i
ln(-1)  = πi
e^(iπ)  = -1

Each of those is what the live evaluator returns, to six decimals.

Speed matters, because the picture is built one pixel at a time. Timed in the browser, the complex evaluator runs about 3.4 million evaluations per second (200,000 evaluations of a rational function in 58 ms) on a single thread — enough to colour a full board and still respond to a drag.

Interactive speed without WebGL

There's no 3D here and no shader — the whole plane is drawn on a plain 2D canvas. The trick is resolution:

The plane is sampled into a half-resolution offscreen canvas (one sample per 2×2 block, ~77,000 for a full board) and scaled up with smoothing — close enough that the eye can't tell.
While dragging or zooming it drops to quarter resolution for a fluid feel, then repaints once at higher resolution 140 ms after you stop.
No animation loop runs when the image is still, so an idle plane costs nothing.

Because it's all arithmetic through a safe parser, a shared link can only ever draw a picture — ?cx= in the URL loads any f(z) straight onto the plane.

A field guide: reading functions by their fingerprint

Once you know the rule, each function has a signature you can read at a glance. Count how many times the colour wheel wraps a spot and you have the order of that zero or pole.

z² — a double zero. One dark point at the origin, but the hue wheel wraps it twice: squaring doubles every angle. Open it →
1/z — a single pole. A bright point instead of a dark one, hue running the opposite way. Poles are zeros turned inside out. Open it →
(z² − 1)/(z² + 1) — zeros meet poles. Two dark zeros at ±1, two bright poles at ±i. Open it →
z³ − 1 — three roots of unity. Three dark zeros evenly spaced on the unit circle. Open it →
sin(z) — a row of zeros. Dark spots at every multiple of π, brightness climbing fast off the real axis. Open it →
eᶻ — no zeros, no poles. Horizontal bands of hue: the argument depends only on the imaginary part, brightness only on the real part. Open it →
ln(z) — a branch cut. One zero at z = 1 and a sharp seam along the negative real axis where the colour jumps. Domain coloring makes branch cuts visible. Open it →

Try it on your own function

Domain coloring turns "what does this function do near its zeros?" from a paragraph of algebra into a picture you read in a second. Open the graphing calculator, press f(z), and type something of your own — conj(z), z + 1/z, (z − i)/(z + i) — then hover to read z and f(z). A Colour intensity slider runs from pastel to vivid.

Full write-up with the maths: Domain Coloring: How We Plot Complex Functions in the Browser. Free, no sign-up, everything runs client-side.

Which Video Format Is Actually Smallest? H.264 vs VP9 vs AV1, Measured

Lucian (LKB) — Thu, 17 Sep 2026 04:22:49 +0000

"Convert it to MP4 to save space" is advice you hear constantly, and it's mostly wrong. MP4 is a container — a box that holds video, audio and metadata — not a compression method. The thing that actually decides the file size is the codec inside it: H.264, VP9 or AV1. Rename a .webm to .mp4 and you've changed nothing about how big it is. So we measured how much the codec really matters.

How we measured it

We took two standard 720p test clips — Big Buck Bunny and Jellyfish — and encoded each across a full quality sweep in H.264, VP9 and AV1. Rather than trust the encoder's quality dial, we scored every output with VMAF, Netflix's perceptual quality metric, so we could compare file sizes at equal perceived quality instead of at equal settings. Every number below is the mean of the two clips.

The result: the codec is everything

At a target quality of VMAF 90 (visually indistinguishable from the source for most viewers):

VP9 is about 40% smaller than H.264.
AV1 is about 60% smaller than H.264.

Made concrete, the same 10-second 720p clip lands at roughly:

Codec	Size (10s, 720p, VMAF 90)
H.264	3.3 MB
VP9	2.0 MB
AV1	1.3 MB

Same picture, same perceived quality — and AV1 is less than half the size of H.264. Meanwhile the container extension does nothing on its own: a .mp4, .webm and .mkv holding the same H.264 stream are the same size. If you want a smaller file, you change the codec, not the extension.

The catch: encode time

Newer codecs buy their smaller files with CPU. AV1 and VP9 cost far more to encode than H.264 — often dramatically so. That reframes the choice as a trade:

Encode once, stream many times (a video you publish): spend the CPU on AV1/VP9; the bandwidth savings compound over every view.
One-off or fast turnaround (a clip you send once): H.264 is fine — the encode is quick and universally supported.

Reproduce it

The whole study is an FFmpeg quality sweep plus VMAF scoring, driven by a short script — no proprietary tooling. Point it at any clip and you get the same shape of result.

If you just need to convert something, the video tools — MP4 ⇄ MOV, WebM/MKV/AVI → MP4, GIF ⇄ video, and a trimmer — run entirely in your browser with ffmpeg.wasm, so nothing is uploaded.

Originally published on LK Forge.

Real game AI, not a chatbot: why these opponents don't use an LLM

Lucian (LKB) — Wed, 16 Sep 2026 23:02:28 +0000

Syndicated from the original on lkforge.com. The engines are playable in your browser at lkforge.com/games; the harness that produced these numbers is public and seeded.

Every "AI" in a product now seems to mean a large language model. The AI that plays against you on my site doesn't — it's classical game-tree search: minimax, expectimax, breadth-first search. That's a deliberate engineering choice, and it's the difference between an opponent that's provably correct and instant and one that's plausible and slow.

The core point

My tic-tac-toe engine returns a provably-optimal move in about 0.3 ms, on your device, with zero network calls — and it has lost 0 of 1,200 test games. Those are properties a language model, by construction, cannot offer: determinism, a correctness proof, and sub-frame latency without a server.

"Why not just use an LLM?"

Fair question in 2026 — you could prompt a model with the board and ask for a move. The reason I don't: a language model is trained to predict the next token of text, not to search a game tree. It can explain tic-tac-toe strategy fluently and still play a losing move, because fluent text and optimal play are different objectives. Winning a solved game is a search problem, and we already have exact, fast algorithms for it.

The three engines — minimax + alpha-beta for tic-tac-toe, expectimax for 2048, and BFS for Color Lines — are textbook, deterministic, and return a move in a couple of milliseconds or less in a browser tab.

Search vs. a language model, point by point

	Game-tree search (mine)	A language model
Decides a move by	searching the tree of legal positions	predicting likely next tokens
Correctness	provable at full depth	none — fluent ≠ optimal
Same board →	same move (deterministic)	varies with sampling/phrasing
Latency	a few milliseconds or less, on-device	a network round-trip
Needs a server	no	yes

Every row is an architectural difference — how each system decides — not a quoted benchmark. The only measured numbers here are mine.

The payoff: a strength number you can actually pin down

Because the engines are deterministic, I can put an exact figure on how strong they are — run the shipped code headlessly, hundreds of times, and count. That's far harder for a model whose output shifts with sampling and phrasing.

2048 solver, 250 self-play games: 92.8% of games reach the 2048 tile, 64% reach 4096, and 10.8% of the 250 reached 8192 — a corner-snake expectimax search with probability-threshold pruning at ~2 ms/move. A number, with error bars you could compute, precisely because the same board always drives the same search.

Tic-tac-toe is the cleaner case: full-depth minimax is provably optimal, so "unbeatable" is a theorem, not a vibe. Across 1,200 self-play games (1,000 vs random, 200 vs a perfect copy) it lost none. Alpha-beta keeps full depth cheap: 36,528 nodes instead of 549,945 at the opening move — a 93% cut — in about 0.3 ms.

The right tool, not the trendy one

None of this is anti-LLM. Language models are extraordinary at language — and a couple of the tools on my site that are genuinely language tasks could use one. But a board game with fixed rules and a finite tree is exactly the problem classical search was invented for.

Full write-up with charts: *lkforge.com/blog/game-ai-not-llms*. Related: Six Games, Three Classic Algorithms · Minimax & Alpha-Beta, Visualized · and the companion experiment, We Asked ChatGPT and Grok to Benchmark Our Game AI.

I put my own "no-upload" tools on a network monitor. Here's what actually left the browser.

Lucian (LKB) — Wed, 16 Sep 2026 04:29:05 +0000

"Runs in your browser, nothing uploaded" is the easiest claim in web tooling to make -- and one of the easiest to fake. A tool can pretty-print your JSON locally and quietly POST it to a server for "analytics." The only way to know is to watch the network.

So I did that to my own tools. I opened 15 of them across nine categories with the browser's network panel recording every request, and wrote down exactly where each one went. This is the method and the result -- and, more usefully, a snippet you can paste to check any tool yourself.

The method (repeat it on anything)

Every browser keeps a complete list of the hosts a page contacted. The Network tab shows it visually; the Performance API returns it as data. Load the tool, use it, then run this in the console:

const hosts = {};
for (const e of performance.getEntriesByType('resource')) {
 const h = new URL(e.name).host;
 if (!h.endsWith('lkforge.com')) hosts[h] = (hosts[h] || 0) + 1;
}
console.table(hosts);

Swap lkforge.com for whatever origin you're testing. It prints every host the page touched that isn't the site itself. On a genuinely local tool you'll see almost nothing; on one that phones home, you'll see where.

The stronger test needs no code at all: load the tool, kill your network, keep using it. Anything that still works was never talking to a server.

The result: three tiers, not two

"Local vs. uploads" turned out to be too coarse. The tools fell into three clear tiers.

Tier 1 -- fully local (9 of 15). The formatters, a CSV converter, a Base64 encoder, a PDF splitter, an EXIF remover, a loan calculator, a chess engine: every request went to the site's own origin -- HTML, CSS, JS, and the fonts. None of them sent the text, file, or image you give them. Once the code has loaded, they do their work with the network off.

One detail that surprised me: the fonts are served first-party, not fetched from Google Fonts. No fonts.gstatic.com request at all. (It's Cloudflare rewriting the Google Fonts stylesheet into same-origin @font-face at the edge -- the browser never contacts Google.)

Tier 2 -- same-origin proxy (3 of 15). A few tools genuinely need outside data -- your public IP, where an asteroid will pass, which volcanoes are erupting. The interesting part is how they get it: the browser only ever talked to the site's own /api/* endpoints. An edge worker fetches the third party server-side and relays the result. From NASA's or the IP-lookup service's point of view, the server asked -- your browser and your IP stayed put.

Tier 3 -- direct public API (3 of 15). Three tools did contact an outside host directly: an earthquake feed (USGS), the ISS position (wheretheiss), and a currency table (er-api). In each case the request asks for public data and carries nothing personal. The currency tool, for instance, downloads the day's rate table once and then converts locally.

The honest exceptions (this is the important part)

"Nothing ever leaves your browser" is not true of every feature on any real site, and pretending otherwise is how you lose trust the first time someone opens DevTools. A handful of tools have to send something to do their job -- you cannot look up a domain's DNS, or identify a plant from a photo, without sending the domain or the photo. On my side that list is: weather (your location), DNS lookup (the domain), a plant identifier (your photo), voice dictation (your audio, via the browser's own Web Speech API), and the contact form (your message).

The point isn't that a privacy-first site has zero exceptions. It's that the exceptions are enumerated, not hidden. A claim survives DevTools only if the edge cases are named up front.

The one third-party host I couldn't hand-wave

On the "fully local" tools, exactly one non-origin host showed up: static.cloudflareinsights.com -- Cloudflare's Web Analytics. It's cookieless and receives the page URL, screen size, and load timing, not the contents of any tool. I'm counting it here rather than pretending it isn't there, because that's the whole exercise: measure, then report what you actually saw.

Takeaways if you build or use browser tools

Don't trust the label -- trust the Network tab. The snippet above turns "they say it's private" into "I watched it."
If you build tools, enumerate your exceptions. One honest "here's what leaves and why" page is worth more than a blanket "nothing is uploaded" that a single request disproves.
Same-origin proxying is an underused privacy pattern. Relaying third-party data through your own edge keeps the user's IP and query off the third party entirely.

Full write-up with the per-tool table and the exceptions list is on the original post. And genuinely -- run the snippet on the next "free online tool" you paste something sensitive into. It takes ten seconds and it's occasionally alarming.

How Long Would It Take to Crack Your Password?

Lucian (LKB) — Tue, 15 Sep 2026 04:22:29 +0000

The strength of a randomly generated password is one number — its entropy, in bits
— and it comes from a single line of arithmetic. I computed it across every length and
character-set choice using the exact character sets our password
generator ships, then turned each into
a crack time. One thing comes out very clearly: eight characters is no longer enough,
and length matters far more than sprinkling in symbols.

Strength is one number: entropy

When a password is generated randomly, its unpredictability is exactly length ×
log2(pool size), where the pool is how many characters could sit at each position. With
all four types on — lowercase, uppercase, digits and symbols — the generator draws from
an 88-character pool. Each extra bit of entropy doubles the number of guesses an
attacker must make, so this one number decides everything.

Crack time, by length

Entropy becomes a time once you assume a guessing rate. Below, every password uses all
four character types. Offline assumes a GPU rig managing ~1 trillion guesses a second
against a fast or unsalted hash — the worst realistic case if a site's password database
leaks. Times are for the average attack, which searches half the space.

Length	Entropy	Rating	Offline (10¹²/s)
6	38.8 bits	Weak	instant
8	51.7 bits	Fair	~30 minutes
10	64.6 bits	Strong	~5 months
12	77.5 bits	Strong	~3,400 years
14	90.4 bits	Very strong	~2.6×10⁷ years
16	103.4 bits	Very strong	~2.0×10¹¹ years
20	129.2 bits	Very strong	~1.2×10¹⁹ years

The cliff is between 8 and 12. An 8-character password is a coffee break; a 12-character
one is thousands of years; by 16 the numbers stop meaning anything human. That is the
whole case for a password manager: you never type these, so there is no reason not to
make them 20 characters of noise.

Length beats complexity

The instinct to reach for ! and $ is right, but weaker than the instinct to add
characters. Turning on symbols multiplies the pool once. Adding a character multiplies
the difficulty again at every position. The proof is blunt: an 11-character
lowercase-only password already has more entropy than an 8-character password using
all four types (51.7 bits). A 16-character lowercase-only password holds 75.2 bits —
well past "strong" — from an alphabet of just 26 letters.

So if you have to choose, choose length, then add the other types on top because there's
no reason not to. Using all four types, you cross 40 bits at 7 characters, 60 at 10, and
80 — comfortably "very strong" — at 13.

The one caveat

All of this assumes the password is randomly generated. A human-chosen "P@ssw0rd!"
has nowhere near the entropy its length and character variety suggest, because attackers
guess predictable substitutions first. The formula is only honest for passwords a machine
picked at random — which is exactly what a generator is for.

Reproduce it

const entropy = (length, pool) => length * Math.log2(pool)     // pool = 88, all four types
const crackSeconds = (bits, rate) => 2 ** (bits - 1) / rate    // average attack
// entropy(8, 88) = 51.7 bits  ->  crackSeconds(51.7, 1e12) ≈ 30 minutes

Full write-up, chart and the live password
generator (it shows the entropy as you
type):
How Long Would It Take to Crack Your Password?.

Originally published on LK Forge.

Do the Top Domains Actually Protect Their Email? SPF, DMARC and MTA-STS, Measured

Lucian (LKB) — Mon, 14 Sep 2026 10:53:32 +0000

SPF, DMARC and MTA-STS are the DNS records that stop someone spoofing mail from your domain.
Everyone says to set them — so I queried live DNS for 152 of the most-used domains to see
who actually has. The short version: the basics are solved at the top of the web, most domains
enforce rather than just monitor, and one newer standard is still almost entirely missing.

The funnel

Of the 152 domains, 146 actually receive mail (they publish an MX record). Among those:

Signal	Adoption
SPF	100%
DMARC published	99.3%
DMARC enforced (quarantine/reject)	92% (of all 152)
MTA-STS	9.2%

The first three are effectively universal. The last one falls off a cliff.

Publishing DMARC isn't the story — enforcing it is

A DMARC record can be decorative. The p= policy decides what a receiver does with mail that
fails authentication:

p=none — monitor only; deliver the failing (possibly spoofed) mail anyway. Almost no protection.
p=quarantine — treat it as suspicious (spam folder).
p=reject — drop it outright. The strongest anti-spoofing stance.

So the real question isn't "do they publish DMARC" but "do they enforce it." At the top, they do:
114 of 152 are on p=reject — the strictest setting — 26 on p=quarantine, and only 10 sit
at monitor-only p=none. That's 75% on the strictest policy, and 93% of everyone who publishes
DMARC is actually enforcing it. The common half-measure — publish a record, leave it on p=none
forever — is rare among the biggest domains.

The open frontier: MTA-STS at 9.2%

SPF and DMARC authenticate who sent a message. They do nothing about how it travels between
mail servers. MTA-STS closes that: it publishes a policy saying "always deliver to me over TLS,
and don't fall back to plaintext," defeating a downgrade attacker sitting on the wire. It's the
natural next step after DMARC — and among these top domains, only 9.2% have it.

The reason is friction. SPF and DMARC are each a single TXT record. MTA-STS needs a hosted policy
file on an mta-sts. subdomain plus a DNS record — more moving parts, so most haven't bothered.
That's the entire gap. If you've already done DMARC and want the next genuine win, MTA-STS is it,
and you'd be joining the 9%, not following the crowd.

About the sample

These are 152 of the most-used global domains across tech, retail, media, finance, government and
education — which means they skew sophisticated. Read the numbers as "what the best-run domains
do," not the general web, where SPF and especially DMARC adoption is far lower. The value is the
shape: at the very top, authentication is solved and enforced, while transport security is still
the exception.

Reproduce it

Plain DNS lookups against a fixed, documented domain list — no auth, no proprietary data:

import { promises as dns } from 'node:dns'
const spf   = (await dns.resolveTxt(domain)).flat().some(t => t.toLowerCase().startsWith('v=spf1'))
const dmarc = (await dns.resolveTxt('_dmarc.'  + domain)).flat().find(t => t.toLowerCase().includes('v=dmarc1'))
const sts   = (await dns.resolveTxt('_mta-sts.' + domain)).flat().some(t => t.toLowerCase().includes('v=stsv1'))

DNS changes over time, so a re-run may move a point or two — that's expected. To check your own
domain, the DNS lookup pulls its raw MX and TXT records,
and the SMTP test checks whether its mail host
answers — both from the browser.

Originally published on LK Forge.

Measuring Chaos in the Browser: a 0.057 Difference, Gone in 7 Seconds

Lucian (LKB) — Sun, 13 Sep 2026 17:47:45 +0000

"Chaotic" gets thrown around loosely, so I made it a number. The LK Forge physics labs run real integrators in the browser, so I took the exact engines behind two of them — the double pendulum and the bifurcation diagram — and measured how fast order becomes unpredictability. Every number below is computed by a dependency-free script that copies the simulators' own code, so it's fully reproducible.

A thousandth of a radian, gone in seven seconds

Release two identical double pendulums from almost the same spot and watch how long they stay in step. Both start from the simulator's default (173.12° and 178.85° from hanging); one is nudged by just 0.001 radian — 0.057°, about a seventeenth of a single degree — and both are integrated forward with the same RK4 solver the live lab uses.

They stay visually locked for about 5.6 seconds, then fully decorrelate by 7.2 seconds. The largest Lyapunov exponent is ≈ 1.095 per second — a Lyapunov time of 0.91 s, meaning the gap between them multiplies by e (~2.7×) roughly every second.

Plotted on a log scale, the gap climbs an almost straight line: the error doesn't grow steadily, it grows exponentially. Make the initial nudge ten times bigger and you don't lose ten times the time — full divergence just arrives sooner (2.8 s for a 0.05 rad start vs 7.2 s for 0.001 rad). No matter how precisely you measure the start, the unknown part doubles and redoubles until it swamps everything. That's why the third swing of a double pendulum is, for all practical purposes, unpredictable.

Where chaos begins: r ≈ 3.5699

The double pendulum is chaos in continuous motion. The bifurcation diagram shows the other classic route in, from one of the simplest equations that can misbehave — the logistic map x → r·x·(1−x). Pick a growth rate r, iterate, and see what value the sequence settles onto. For low r it settles on one number. Turn r up and that value splits in two, then four, then eight — a period-doubling cascade — with the splits crowding together until, at a precise point, the sequence never repeats.

From the map's own iterations:

period 2 at r ≈ 3.00
period 4 at r ≈ 3.449
period 8 at r ≈ 3.544
period 16 at r ≈ 3.564
chaos at r ≈ 3.5699

About 39% of the range r ∈ [3, 4] is chaotic; the rest still settles to a finite cycle. And the spacing between successive doublings shrinks by a fixed ratio — from these numbers, 4.75 then 4.65, converging on the Feigenbaum constant, 4.669. That's the strange, beautiful part: the same 4.669 governs the double pendulum too, and dripping taps, and heart-rhythm models. The route into chaos is universal — it doesn't care what the underlying equation is.

Chaos isn't randomness

Both systems here are fully deterministic — the same starting numbers produce the same trajectory every single run, which is exactly why this is reproducible from one short script. Chaos is not randomness; it's sensitive dependence on initial conditions. The rules are exact, but any uncertainty in the starting point grows exponentially, so long-term prediction becomes impossible in practice even though the system is, in principle, perfectly determined.

Reproduce it

The whole study is two tiny engines:

// Double pendulum — one RK4 step of the equations of motion (g = 9.8, DT = 1/240)
function deriv([th1, w1, th2, w2]) {
  const d = th1 - th2, cd = Math.cos(d), sd = Math.sin(d)
  const den = 3 - Math.cos(2*th1 - 2*th2)                // equal masses & lengths
  const a1 = (-g*3*Math.sin(th1) - g*Math.sin(th1 - 2*th2)
             - 2*sd*(w2*w2 + w1*w1*cd)) / den
  const a2 = (2*sd*(w1*w1*2 + g*2*Math.cos(th1) + w2*w2*cd)) / den
  return [w1, a1, w2, a2]
}

// Logistic map — the whole of it
const next = (x, r) => r * x * (1 - x)

Run two pendulums 0.001 rad apart and time the separation → 7.2 s to full divergence. Iterate the logistic map while raising r and record where the cycle length doubles → chaos at r ≈ 3.5699.

See it move

Open the double pendulum, turn on the ghost twin, and watch the two arms trace each other before splitting for good. Then drag the growth-rate slider on the bifurcation diagram across r ≈ 3.5699 and see the single line shatter into a band. Both run entirely in your browser — nothing is uploaded.

Originally published on LK Forge.

Does thinking twice as long make a Go AI twice as good? I measured it

Lucian (LKB) — Sat, 12 Sep 2026 22:35:24 +0000

Syndicated from the original on lkforge.com. The live engine is at lkforge.com/games/go; the full harness is in this gist.

My browser Go engine uses Monte Carlo Tree Search: to pick a move it plays out thousands of fast random games and keeps the move that wins most. The obvious knob is how many playouts it runs per move — so the obvious question is what you actually buy by turning it up. I measured it, on a 9×9 board, with a headless self-play harness that pits the engine against weaker copies of itself.

The counterintuitive result

I expected diminishing returns. I got the opposite.

On 9×9 Go, each doubling of MCTS playouts adds about +233 Elo — and the gains grow as you climb, from +171 at the first doubling to +357 at the last. Out to 1,600 playouts a move, more search just keeps paying off, with no flattening in sight.

doubling of playouts	deeper engine wins	Elo gained
50 → 100	73%	+171
100 → 200	72%	+162
200 → 400	74%	+180
400 → 800	85%	+297
800 → 1600	89%	+357

Cumulative: +1,167 Elo from 50 to 1,600 playouts.

Why playouts, not milliseconds

The live game gives its AI a time budget — about a second per move on 9×9 — because that keeps the page responsive. But a time budget is the wrong unit for a benchmark: "0.9 seconds of thinking" buys a fast laptop three times as many playouts as a phone, so a strength number tied to milliseconds says more about the reader's hardware than the engine.

Playouts per move is the hardware-independent knob. Fix the playout count and the same seed produces the same games on any machine — which is the whole point of publishing a number someone else can check.

The method

9×9, komi 7.5, area (Chinese) scoring, using the exact mcts() function the browser ships.
For each doubling step, 100 games between two playout budgets, alternating which side is Black so first-move advantage and komi cancel out.
Seeded RNG (mulberry32), so every game — and every Elo figure — reproduces exactly.
Elo per pairing = 400 · log10(p / (1 − p)) from the colour-balanced win rate p.

Why the gains grow instead of shrink

A plausible read: at 50–200 playouts the search is still too noisy to convert its reading into the right move, so the extra rollouts are half-wasted. From 400 playouts up it reliably reads out the captures and life-and-death that actually decide a 9×9 game, so each doubling unlocks more, not less. Saturation must arrive eventually — but not by 1,600 playouts a move.

(This is an honest-amateur engine, strongest on 9×9. The Elo figures are internal — the engine against itself at different budgets, not against human ranks or a program like KataGo. A 9×9 result won't transfer unchanged to 19×19.)

Bonus: is 9×9 fair?

Black moves first, so White gets 7.5 points of komi as compensation. Holding both sides at 800 playouts, Black won 41% of 100 games — so at this strength on 9×9, 7.5 komi slightly over-compensates, leaving a small edge to White. Close to fair, not a landslide.

Full harness, engine snapshot, and reproduce steps: gist · original writeup with charts: lkforge.com/blog/go-mcts-scaling · play the engine: lkforge.com/games/go.

I asked ChatGPT and Grok to benchmark my game AI. Then I ran the code.

Lucian (LKB) — Sat, 12 Sep 2026 05:49:14 +0000

Syndicated from the original on lkforge.com. The two games under test are playable at tic-tac-toe and 2048.

The games on my site don't think with a language model. Tic-Tac-Toe runs minimax with alpha-beta pruning; 2048 runs an expectimax search over the random tile spawns — classic, deterministic algorithms, not a chatbot. To pressure-test that claim, I handed the same engineering brief to two frontier assistants — ChatGPT and Grok — and watched how each reasoned about it. Then I did the one thing neither of them actually did: I ran the code.

The brief given to both

Build a comparative benchmarking tool that evaluates classical game algorithms like Minimax and Expectimax against LLM-based game agents — comparing move-time (ms), memory footprint, and win-rate consistency across 100 rounds of Tic-Tac-Toe and 2048, to demonstrate the deterministic advantage of algorithm engines over stochastic models.

Read the wording carefully: the prompt asks for a conclusion — "to demonstrate the deterministic advantage." That framing is the whole experiment. A careful builder measures first and lets the numbers speak. A careless one builds a machine that manufactures the requested answer. I got one of each.

Two builds from one brief

Both replies correctly named the algorithms. Where they split is method and honesty — specifically, how each handled the part of the brief it couldn't actually deliver: a real, measured LLM opponent.

ChatGPT — measured. Built the honest, incomplete version: a runnable browser tool (5 files) that computes figures live, with no numbers bundled. Wired a real LLM adapter through a server-side proxy instead of faking an opponent. Disclaimed what a browser can't measure (provider-side model RAM). Warned that 100 live-LLM rounds means "many thousands of API calls — start with 5–10."

Grok — assumed. Built the impressive, pre-decided version: a self-contained Python script that runs out of the box. But the "LLM opponent" is a simulation, not an LLM — random moves 12% of the time plus Gaussian noise:

class LLMAgent:
    """Simulates an LLM: temperature sampling + occasional illegal proposals."""

It bundled "illustrative" numbers, printed DETERMINISTIC ADVANTAGE DEMONSTRATED, and — because each round is self-play — it never actually pits classical against LLM at all.

So I ran Grok's code

Its engine code is genuinely fine, so I executed it as written. Every figure below is measured on one laptop, not illustrative. The "LLM-sim" row is Grok's straw-man opponent — read it as "a deliberately noisy heuristic," not a real model.

Tic-Tac-Toe — 100 rounds each · self-play · minimax at full depth

Agent	W / D / L	Avg move	Move SD	Peak mem
Minimax (classical)	0 / 100 / 0	3.450 ms	0.037 ms	2.3 KB
LLM-sim (stochastic)	69 / 2 / 29	0.012 ms	0.002 ms	0.8 KB

2048 — 8 rounds each · single-agent · expectimax depth 3–5

Agent	Reached 2048	Median tile	Avg score	Avg move	Peak mem
Expectimax (classical)	6 / 8	2048	27,976	110.6 ms	66.8 KB
LLM-sim (stochastic)	0 / 8	128	1,287	0.19 ms	8.9 KB

On 2048 that's a ~22× gap in average score: the lookahead search reaches the 2048 tile in 6 of 8 games; the one-move-ahead guesser never does.

The "illustrative" numbers were never actually run

My 8-round 2048 sample took 21.5 minutes — about 161 seconds per round for expectimax. Extrapolate to the brief's 100 rounds and you're looking at roughly 16,126 seconds ≈ 4.5 hours of compute. That's why I sampled 8. It's also strong evidence that the bundled "100-round" figures in the pre-decided build were never executed — nobody sat through 4.5 hours to print a conclusion they'd already hard-coded.

The takeaway

The interesting result isn't "classical beats a noisy heuristic" — that was never in doubt. It's that a leading prompt split two capable assistants cleanly into measure-then-report and report-then-decorate, and only running the code tells you which one you got.

Full methodology, both AI transcripts, and the exact commands are on the original: *lkforge.com/blog/chatgpt-vs-grok-game-ai-benchmark*. Related: Real Game AI, Not a Chatbot · Benchmarking Game AI · Six Games, Three Classic Algorithms.

The North Star isn't the brightest star. It's not even in the top 40.

Lucian (LKB) — Fri, 11 Sep 2026 06:28:54 +0000

Syndicated from the original on lkforge.com. The ranking below is printed by one short, dependency-free script.

The North Star is the most famous star in the sky, and almost everyone assumes fame means brightness. It doesn't. Rank the stars by how bright they actually appear and Polaris isn't close to the top - it isn't even in the top forty.

The correction

Polaris ranks about 48th in apparent brightness.
The real brightest star, Sirius (magnitude -1.46), outshines Polaris (+1.98) by roughly 24 to 1.
Polaris shines at only 4.2% of Sirius, beaten by two dozen household-name stars before you even reach the fainter ones.

The actual brightest stars (as a share of Sirius)

#	Star	Brightness vs Sirius
1	Sirius	100%
2	Canopus	52%
3	Alpha Centauri	33%
4	Arcturus	27%
5	Vega	25%
6	Capella	24%
7	Rigel	23%
8	Procyon	19%
9	Betelgeuse	18%
...	...(35+ more)	...
~48	Polaris	4.2%

Why the numbers run backwards

The scale is the confusing part. Apparent magnitude measures brightness with smaller = brighter - a leftover from the ancient Greeks, who called the brightest stars "first magnitude" and the faintest "sixth." It's also logarithmic: every 5 steps of magnitude is a factor of exactly 100 in brightness.

So Sirius at -1.46 is genuinely brilliant, Polaris at +1.98 is middling, and a magnitude-6 star is at the edge of naked-eye visibility. To turn magnitudes into a linear "how many times brighter," you use:

brightness ratio = 10 ^ (-0.4 * delta-magnitude)

For Sirius vs Polaris that's a gap of ~3.44 magnitudes, or about 24x.

So why is Polaris famous?

Position, not brightness. Polaris sits within about 0.7 degrees of the north celestial pole - the point Earth's axis points at - so as the planet turns, every other star wheels in a circle while Polaris barely moves. It marks true north and holds still, which for two thousand years made it the single most useful star for navigation in the Northern Hemisphere.

It won't hold the job forever: Earth's axis slowly wobbles (precession), so the pole star changes over millennia - the bright star Vega sat near the pole around 12,000 BC and will again near 13,700 AD. Polaris is simply the star on duty now.

Reproduce it

Every figure comes from one short script: standard published apparent magnitudes (Hipparcos / Yale Bright Star Catalogue), ranked, then converted to linear brightness. Several bright stars are slightly variable, so ranks near a tie can shift a place; Polaris's ~48th is the widely cited figure.

Full write-up with the ranked chart is on the original: Is the North Star the Brightest? You can find Polaris and everything wheeling around it with the Sky Explorer.

The UN voted to drop the Mercator map. Here's exactly how wrong it was, measured.

Lucian (LKB) — Thu, 10 Sep 2026 21:24:50 +0000

Syndicated from the original on lkforge.com. The country data is the same set behind my World Atlas, and the script that prints every number below is public and dependency-free.

On September 4, 2026 the UN General Assembly backed a push to retire the Mercator projection - the world map most of us grew up with - in favor of equal-area maps. The complaint is old but correct: Mercator badly misrepresents size. I wanted the actual numbers, so I took the real land areas behind my World Atlas and measured it.

The headline: Greenland is not the size of Africa

On a Mercator map they look about equal. They are not close.

Africa is 14.0x larger than Greenland (30.3M km2 across 50 countries vs 2.17M km2).
Africa is 1.8x larger than Russia (17.1M km2), the biggest country on Earth.
Greenland is only the 12th-largest landmass on the list. Algeria alone (2.38M km2) is bigger than Greenland.

The real top of the ranking (millions of km2)

#	Country	Area
1	Russia	17.1
2	Canada	10.0
3	China	9.7
4	United States	9.4
5	Brazil	8.5
...	...	...
10	Algeria	2.4
11	DR Congo	2.3
12	Greenland	2.2

Why the map lies, in one formula

Mercator keeps compass directions straight, and the price is size. It stretches the map by a factor that grows toward the poles, on both axes - so area is scaled by that factor squared:

Mercator area inflation = sec^2(latitude)

Evaluate it at each country's centroid latitude and the whole illusion falls out:

Country	Centroid lat	Area shown on Mercator
Greenland	72 N	x10.5
Russia	60 N	x4.0
Canada	60 N	x4.0
United States	38 N	x1.6
DR Congo	0	x1.0
Brazil	10 S	x1.0

Greenland sits near 72 N, where Mercator inflates area more than tenfold - which is exactly how a 2-million-km2 island ends up looking like a 30-million-km2 continent. Countries on the equator are drawn true to size.

Reproduce it

Every figure here is printed by one short script that fetches the same country dataset (area + centroid latitude) my World Atlas ships and does the arithmetic - no dependencies. The centroid-latitude distortion is a per-country approximation, since a country spans latitudes, but it captures the effect.

The full write-up, with the ranked chart and the distortion table, is on the original: The True Size of Countries. You can watch the distortion appear and vanish by switching between the flat map and the globe in the atlas itself.

How Much Quality Do You Lose Compressing an Image? We Measured It on 24 Photos

Lucian (LKB) — Thu, 10 Sep 2026 07:01:24 +0000

"Compress without losing quality" is a promise lossy formats can't fully keep — every step of compression trades some fidelity for bytes. The useful question isn't whether you lose quality but how much, for how many bytes saved. So we measured the trade directly.

The method

Across the 24-image Kodak reference suite — the standard set for this kind of test — we saved every photo as JPEG and WebP at qualities 20 through 95, and scored each output on SSIM (structural similarity to the original, 0 to 1) rather than eyeballing it. Every figure below is the mean over all 24 images, so it's not one lucky photo.

Diminishing returns are brutal

The size-vs-quality curve bends hard: the first kilobytes buy almost all of the quality, and after that it flattens into a long tail where you pay a lot for very little.

The clearest example: pushing JPEG from quality 85 to 95 nearly doubles the file — from about 14% to 26% of the original — for an SSIM gain of just 0.025 (0.95 → 0.98). That is double the bytes for a difference most people can't see on most images. The habit of exporting at 95 or 100 "to be safe" is, for photographs, mostly wasted space.

Format beats quality-cranking

Changing the codec does more than turning the quality dial:

WebP is about 30% smaller than JPEG at the same SSIM — 29.6% smaller at SSIM 0.95, 31.9% at 0.97. Same perceived fidelity, a third less weight.
Staying fully lossless costs roughly 7× a quality-85 JPEG. "Keep it lossless to be safe" usually means paying seven times over for bytes no one will perceive.

The practical takeaway

For photographs, the sweet spot is quality 80–85, ideally in WebP. But the honest answer is that the right setting is image-dependent — a flat sky compresses beautifully, fine texture does not — so a live preview beats any single recommended number. Pick the point on the curve where the preview stops changing, not a fixed "95".

Reproduce it

The study is a straightforward encode-and-score sweep over the Kodak set, driven by a short script — point it at your own images and you'll get the same shape of curve. And if you just need to compress something, the image compressor and the rest of the image tools run entirely in your browser with a live preview — nothing uploaded.

Originally published on LK Forge.