
Cuban Music, Neutron Pulses, and a 1965 Plotter
5/4/2026
7 minutes readPhoto by Rhys Kentish on Unsplash
Cuban Music, Neutron Pulses, and a 1965 Plotter
5/4/2026
7 minutes readYou have one hundred jobs and seven worker pods. You need to distribute the jobs as evenly as possible. What do you reach for?
Almost everyone writes this:
const base = Math.floor(100 / 7); // 14
const remainder = 100 % 7; // 2
// First two pods get one extra
const buckets = [15, 15, 14, 14, 14, 14, 14];
The math is correct. The total is one hundred. Two pods carry one extra job each. If your only criterion is "no pod gets more than one job over its share," you can stop here.
For many real workloads you cannot. The two heavier pods are adjacent. Anything that streams work in order (beat sequencing, time-slicing, packet shaping, scheduled cron expansion, rate limiting across a sliding window) sees the imbalance front-loaded into the start of the cycle. The pods rotate out of imbalance, but they never converge to evenness within the cycle.
A line-drawing algorithm from 1965 fixes this in four lines.
Bresenham, Repurposed
Stated as a formula:
Two floor divisions, one subtraction, run K times. In code:
function distribute(n, k) {
const out = [];
for (let i = 0; i < k; i++) {
out.push(Math.floor((n * (i + 1)) / k) - Math.floor((n * i) / k));
}
return out;
}
distribute(100, 7) returns [14, 14, 14, 15, 14, 14, 15]. Same total, same number of "extras," but the extras are now at positions 3 and 6, maximally apart in a cycle of 7. The work is spread.
This is Bresenham's line algorithm, recast as a distribution algorithm. The original was published by J. E. Bresenham at IBM in Algorithm for computer control of a digital plotter (1965). It decided whether to step diagonally or horizontally when rasterizing a line on a digital plotter using only integer arithmetic. The same accumulated-error logic, applied to a different question, decides whether each bucket gets the base count or the base count plus one.
Bresenham did not write a distribution algorithm. He wrote a line algorithm. The reapplication came later, by other people who did not know about Bresenham.
The Geometry
To see why this works as a line algorithm, draw a line from to on a grid. Column is the interval . The line enters that column at and exits at . The number of new integer -values it reaches as it crosses the column is exactly . That is the bucket count for column .
The fair distribution you wanted is the staircase rasterization of a perfectly straight line. Each bucket is a column. Each bucket count is the number of pixels the line lights up in that column.
I built an interactive version. Drag N and K, watch the line draw itself, then watch the lit cells fall down into bucket bars. Once you see it, the connection is hard to unsee.
The First Rediscovery
In 2003, a physicist at Los Alamos National Laboratory named Eric Bjorklund needed to time the firing of neutron pulses in the Spallation Neutron Source. He had K neutron pulses to fire across N available time slots, and the firings needed to be as evenly spaced as possible to avoid resonant clustering in the accelerator.
He derived an algorithm using a recursive Euclidean-style subdivision, structurally a Euclid GCD running on two strings of zeros and ones. It does not look like Bresenham. The output is identical to the floor-difference form. He published in a particle accelerator journal. He did not cite Bresenham. The two algorithms had been written for two different problems by two people who never read each other.
The Second Rediscovery
In 2005, the computer scientist Godfried Toussaint published The Euclidean Algorithm Generates Traditional Musical Rhythms. He noticed that when you fed Bjorklund's algorithm the parameters of well-known world rhythms, you got the rhythms back.
, three onsets in eight steps, is the Cuban tresillo. The foundation of salsa, reggaeton, and roughly half of modern pop.
is the Cuban cinquillo.
is the Turkish aksak.
is a West African bell pattern that you can hear in countless sub-Saharan drumming traditions.
These rhythms had been developed across cultures over centuries by musicians who had never written an algorithm. They were the sound of evenness, the same pattern that makes neutron pulses non-resonant and load balancers fair. Toussaint did not invoke Bresenham either. He arrived at the same shape from a third angle.
Three Independent Discoveries, Same Algorithm
| Discovery | Year | Problem | Cited prior work? |
|---|---|---|---|
| Bresenham | 1965 | Rasterize a line on a digital plotter | Not for this problem class |
| Bjorklund | 2003 | Time neutron pulses at a particle accelerator | No |
| Toussaint | 2005 | Why world music rhythms feel even | Cited Bjorklund, not Bresenham |
Different problems. Different decades. Different fields. Same algorithm.
It is also in places nobody bothered to publish about. Stepper-motor firmware (Marlin, Grbl) uses Bresenham-style DDA stepping to coordinate axes. AC power controllers for industrial heaters use cycle-skipping with the same floor-difference math. LED PWM dimmers use it to spread on-cycles to avoid flicker. MIDI clock subdivisions use it. The nginx smooth-weighted-round-robin algorithm is a close relative.
Convergent Discovery Is the Default
The phenomenon of multiple people independently arriving at the same idea has a name. Robert K. Merton called it the multiples thesis in his 1961 paper Singletons and Multiples in Scientific Discovery. His claim, supported by an extensive historical survey, was that independent multiple discovery is the norm in science, not the exception. Calculus, oxygen, evolution, the telephone, sunspots, sex hormones: all discovered more than once by people working in isolation.
The corollary is Stigler's Law of Eponymy: "no scientific discovery is named after its original discoverer." Bresenham did not name the algorithm after himself; we did. Stigler, with predictable irony, attributed his own law to Robert K. Merton.
The reason convergent discovery happens is not that scientists are unoriginal. It is that mathematics is real. When a problem sits at a genuine bottleneck, smart people who look at it seriously will find the same answer. There is one most-elegant way to do it given the constraints, and the math is not waiting in a textbook. It is waiting in the structure of the problem.
This is why the same four-line algorithm shows up at IBM in 1965, at Los Alamos in 2003, and in pre-colonial West African drumming. The four lines are not the idea. They are the only reasonable response to "distribute K things across N positions as evenly as possible without floats." Once you have asked that question seriously, the answer narrows itself.
The four lines find you.
Patterns, Not Tricks
I ran into these four lines once without knowing what they were. I was rendering a column graph in the terminal: fixed-width characters, a variable number of samples, a fixed terminal width. Naive division gave each bar a base width plus a remainder, and the remainder always crowded at the front. The first few bars came out a column wider than the rest, and the lopsided front shifted with every refresh. The floor-difference formula fixed it. I did not know it had a name until later.
You will see them in a stepper firmware project. In a load balancer config. In an AC power controller someone rolled in C. In a rate limiter that tries to spread requests across a window. In the rhythm pattern your DAW exports for . You will see the four lines.
The trick is the formula. The pattern is what the algorithm does: track an accumulating error, snap when it crosses a threshold, repeat. Same skeleton in dithering, in PID controllers, in nginx weighted round-robin, in Floyd–Steinberg image quantization. Different decoration each time.
A line-drawing routine you learned in graphics class will fix a fair-distribution problem on your next backend job. But only if you trained your eye to see them as the same problem.
