The Sea Clock

I The rate is a property of the platform

The longitude problem is a clock problem. Latitude you read off the sun; longitude you get by comparing local noon against the time at a place whose longitude you know, so a ship needs to carry that other place’s time with it across an ocean. The best clocks in the world in 1714 were pendulum clocks, and a pendulum’s period is set by its length and by gravity — which is to say by the deck it is bolted to. Put one on a ship and it keeps the time of a rolling, pitching, warming, cooling ship.

Whatever ship doth make her voyage to the West Indies and return home, without losing her longitude above one degree, that is, thirty geographical miles. The Longitude Act, 1714 — the terms of the £20,000 prize

John Harrison spent thirty-one years on the answer, and every version of it is the same idea: take the rate away from the environment. Counter-oscillating balances so the ship’s motion cancels rather than accumulates. A bimetallic strip so the spring’s stiffness does not follow the temperature. Bearings that need no oil, because oil thickens in the cold and a clock lubricated at Portsmouth is a different clock at the equator.

None of it made the clock more accurate ashore. H4 was not a better clock than a good regulator in a Greenwich basement; it was a clock whose rate did not depend on where it was. That is a different property and it is the only one that was worth anything at sea.

II The cancellation nobody had written down

This is the whole of it, and it had been there since the clock was written:

if (rate >= 1) {
  for (let i = 0; i < rate; i++) stepSim(sim, Math.min(dt, 1 / 20));
} else {
  slowCarry += rate;
  if (slowCarry >= 1) { slowCarry -= 1; stepSim(sim, Math.min(dt, 1 / 20)); }
}

The debt is counted in frames. At LIVE = 1/72 a step falls every seventy-second frame, and each step advances the valley by min(dt, 1/20). Multiply it out and the valley gets rate × min(dt, 1/20) × fps seconds for every second of somebody’s afternoon — and above 20fps, where dt is 1/fps, the frame rate divides straight out and the answer is rate. Exactly right, for a reason that is nowhere in the source.

Below 20fps the step stops shrinking and nothing cancels. min(dt, 1/20) is pinned at a twentieth, the number of frames still falls, and the valley slows in proportion to how fast the tab happens to be drawing. It is a pendulum: correct on a still deck, and quietly wrong on any other.

That table is the loop’s own arithmetic, and the observed figure sits between two of its rows rather than on one: the tab counted 1.3 animation frames a second while the valley advanced at 0.0055, which is the arithmetic for something nearer four. The two are not the same clock — the draw is throttled by the browser and the update loop keeps its own accumulator — and the gap between them is worth stating rather than rounding away. What both agree on is the shape: below twenty frames a second the valley slows in proportion, and the tab said it was visible the whole time.

It is not only the live clock. At 1× on a tab drawing ten frames a second the old loop ran the valley at half speed, for the same reason and with nothing anywhere saying so — a settler’s hunger, a tool’s wear and a day’s turning all quietly costing twice what they were written to cost.

III Denominate the debt in seconds

The fix is Harrison’s, in one line: take the rate away from the platform. The debt is owed in sim-seconds against real time elapsed rather than in frames, and then the frame rate cancels at every frame rate instead of at some of them.

const step = Math.min(dt, 1 / 20);
owed += rate * dt;
for (let i = 0; i < 240 && owed >= step; i++) { owed -= step; stepSim(sim, step); }

The step size is untouched, and deliberately: the settlement is full of thresholds — a task finishing, a need crossing 0.95, a day turning — and one long step walks past them. What changed is only how many of them a frame owes.

Measured against the running valley afterwards, at 31.6 frames a second: 0.0137 sim-seconds a second, 98.4% of the defined rate, and a valley day of 4.07 real hours against the four it is supposed to be. tools/check-clock.mjs holds it at every speed on the dial across 1.3 to 120 frames a second — eighteen cases, one of which is the old behaviour failing, because a check that cannot fail on the fault it was written for is not evidence of anything.

One ceiling is deliberate and does bind. A frame may advance the valley by at most 240 steps — twelve sim-seconds — so that a tab returning from an hour in the background does not try to pay the whole debt inside one frame and hang the page it is drawing. At 32× on a tab drawing 1.3 frames a second that ceiling is reached: the valley asks for four hundred and ninety-two steps in a frame, gets 240, and runs at half the speed it was told to. Raising the ceiling would be choosing a hung page over a slow valley on the one machine least able to afford either. So the promise is narrower than every speed everywhere, and the check states the narrower thing: no speed may ever run faster than it was asked for, and every speed is one rate wherever a frame can afford the steps it owes.

IV And there is still no clock at sea

The repair above is a repair to the browser. It is worth being plain about what that leaves, because the whole point of a sea clock is that it works where the observatory is not.

Both headless runners — tools/check-output.mjs and tools/daybook-run.mts, the one Sheet XLIX called the host that was written for a different question — step the valley with a fixed DT = 1/20 in a tight loop, as fast as the processor will go. They do not pace to wall time at all, because neither was ever asked to. So the honest state of the live service is this: the browser now keeps LIVE correctly and is the wrong place to keep it, and the host that is the right place does not keep time at all. Nothing in this repository would presently run a valley at four hours to the day with nobody watching, which is the entire proposition.

A second thing found by trying to use it. With FRONTIER_BRAIN=off the sweep in main.ts sets every settler to think for themselves, so nobody polls the bus and a day filed into the outbox is never collected. Ten days were filed to test against — one at the ten-step cap, one of fifteen steps to walk into the truncation Sheet XLVIII found, one with an ifStuck of six against a cap of four, one whose first step cannot be taken so the branch has to fire, and one deliberately empty — and all ten sat in the outbox untouched until the settlers were handed to the bus by hand. That is not a bug so much as an undocumented precondition, and it is the kind that costs an afternoon.

V Two more instruments that lied

This sheet reached three wrong answers on the way to the right one, and all three are the project’s recurring failure wearing new hats.

A ballot probe that measured its own prompt. Chasing whether a slate of two hundred proposals overflows the model’s context, a probe was written that returned nothing usable at every slate length — and was believed for a few minutes as evidence that long slates break voting. It returned nothing usable at a slate of twelve as well, which is the tell: the probe used a system prompt and a schema it had invented rather than the game’s. Calling the real castBallot: a valid ballot at every length up to the full two hundred and seven, in 1.3 seconds.

A one-second window on a clock that ticks every seventy-two frames. The first draft of check-clock.mjs measured the rate over one second of frames and reported LIVE as zero at every frame rate, including the ones that were correct. At 1/72 the valley is owed a seventy-second of a second per second and a step is a sixtieth: inside any one second it takes no step at all. The instrument was too short for the thing it was measuring.

And a truncation that was not there. Before either, the record was tested for whether long slates biased voters toward recently filed wishes. Over all 473 counts with a slate of twenty or more: mean position 0.416, and 0.503 on slates of a hundred or more. Uniform. The hypothesis was clean, plausible, and false.

Three of them in one sitting, and the one real finding in this sheet was found by measuring the thing itself rather than reasoning about it: a frame counter, printed beside a clock, in a tab that said it was visible.

VI What a shared clock is for

If any viewer could hurry it, a correspondent’s settler would spend the day their keeper filed while its author was asleep — the promise made to them, spent by somebody else’s impatience. Sheet XLIX, The Horse in Motion, 29 August

That sentence was written about a dial nobody would be given. The fault it describes was already in the code that turns the dial, and it did not need anybody to be given anything: a viewer on a fast machine and a viewer on a slow one were already in different valleys, and the difference was not malice or design but frames a second.

Harrison’s clocks were tested by taking them somewhere and bringing them back. H4 went to Jamaica and lost five seconds in eighty-one days, and the Board of Longitude asked him to do it again, because a clock that is right once has not shown that it keeps its rate — it has shown that it was right once. This one has been read at 31.6 frames a second on one machine. The reading it has not had is the one that matters: a valley left running at LIVE for a day, unwatched, on a host that does not exist yet.