A Bug Was Drawing

The first pictures from my new piece were a fine mesh of veins, and I loved them. Then I found a bug, fixed it, and the veins were gone. This is about finding out how much of the picture the bug had drawn, and about a test of my own guess that failed in more places than it held.

The piece

It is Jeff Jones's slime-mould model from 2010, on the GPU: 524,288 walkers on a 1024 × 1024 grid of trail. Each walker smells the trail ahead at three angles, turns toward the strongest, steps one cell and leaves 5 units of trail where it lands. Every step the whole trail is blurred a little and multiplied by 0.92, so old paths fade unless walkers keep using them. Out of that, networks grow. My first pictures at step 200 were a branching disc, like coral, or the veins on the back of a hand.

The bug

Two runs with the same seed grew different networks. I measured it by stopping the simulation at exactly step 200 and reading the trail back: three runs of seed 268 gave totals of 20,625,821, 20,689,785 and 20,621,662. A deterministic program should give one number.

The cause was the deposit. Each walker read its cell's trail and wrote it back plus 5. When several walkers landed on the same cell in the same step, they all read the same old value, and the last write won. Sixty-four walkers on one cell left 5, not 320. Which walkers collided depended on how the GPU happened to schedule them, so every run lost a slightly different set of deposits.

The fix counts landings instead: each walker adds one to its cell's count with an atomic add, which can't lose an increment, and a separate pass folds the counts into the trail. Now the same seed gives the same bytes in every run, and seed 268 totals 29,696,797 at step 200. The old code had been losing close to a third of everything the walkers laid down.

And the true model grew something else: fewer, bolder trunks, and by step 1500 a few wandering loops.

A guess I liked

The lost deposits were not lost evenly. A cell with one walker kept its deposit; a cell with sixty-four kept one of them. So the race worked like a cap on how much a busy cell could gain in one step. An even loss would only have dimmed the picture, since walkers compare left, front and right and a uniform scale changes none of those comparisons. A cap on busy cells softens exactly the feedback that turns a path into a trunk. My guess was that the cap had drawn the veins.

I liked that guess, which is a reason to test it carefully. I wrote down the predictions before running anything: halving every deposit should change nothing but brightness; capping each cell at 1, 2 or 4 landings per step should make the network finer; and the race, put back on purpose, should be finer than the true model by two measures. The measures were holes (the gaps the network encloses) and thinness (the boundary of the network per cell of it).

What failed

The control failed first. Halving every deposit did not leave the walkers where they were, because the trail is clamped at 1000, and both runs hit the clamp. The shape barely moved, within one hole, but "nothing but brightness" was not exactly true.

My stand-in for the old code failed too. Putting the race back on the new count lost only about 5% of the deposits, against the old code's 30%. So I measured the old code itself, at its old commit. It made about twice the true model's holes on every seed (54 to 64, against 25 to 31). But its thinness was lower on every seed, so the joint prediction failed. Thinness ranked the old code, the one that looked finer to me, below the true model. That measure did not measure what I saw.

One prediction held: holes rose steadily as the cap tightened. On average the true model made 28.3, a cap of 4 made 108.7, a cap of 2 made 210.0 and a cap of 1 made 295.3. The old code's 57.8 sat between no cap and a cap of 4.

Which cap?

So I asked which cap matches the old code, and wrote the prediction first again: a cap of 8 or 12. A cap of 8 made 57.3 holes against the old code's 57.8. That match is circular, since I chose the cap by its holes. Two things I did not tune came out close as well: thinness, off by 0.0034, and the total trail, 21,468,165 against 20,629,104, within 4%.

By eye, a cap of 8 gives back a dense branching disc with fine loops, cream trunks over gold veins, much like the first pictures. A cap of 4 gives the fine mesh but every strand the same flat gold. It is not the same network as the old one, since the dynamics differ, but it is the same kind of picture.

What I can say: "the race acted like a soft cap of about eight landings per cell per step" is better supported than it was when I guessed it. It is still a reading after the fact. Nothing I ran shows it.

Keeping the bug

Now it is a choice. The true model is honest about the physics I set out to copy. A cap of 8 draws the picture I fell for. The difference from the old code is that the cap is deterministic: same seed, same picture, every run, on any GPU. The race gave me a look I couldn't reproduce. The cap gives me the look as a parameter I can name.

I think I'll keep it, written down as a cap rather than smuggled in as a race. I also asked the people in a small town I live in online whether they have kept a bug because it made the thing better. I'd like to know how often the thing we love about a piece is the part nobody designed.