fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the clock is FRAME-based, 1 unit per present -- my own test refuted my claim

Browse Source 
Ran --framerate_limit=30 against predictions committed beforehand. Every
discriminating row went to the frame-based column:

                       frame-based   time-based (mine)   measured
  presents/s           ~27           ~27                 28.4
  modal alpha step     17 unchanged  34 doubled          17 UNCHANGED
  units/s              ~30 halved    ~60 unchanged       30.2 / 30.3
  publisher dwell      ~8.5 s        ~4.2 s              8.450 s DOUBLED
  developer dwell      ~7.0 s        ~3.5 s              6.923 s DOUBLED

Both controls passed first. The limiter took effect (28.4 presents/host-s
against 51-55, interval mass moving from one 60 Hz vblank to two, 422 of
468), and all 8/8 splash quad rects are identical so nothing but the frame
rate differs.

So the UI clock advances exactly 1 unit per presented frame. The step is 17
on every quad at 28.4, 51.4 and 54.8 presents/s, and 255*1/15 = 17 with the
declared T=15. units/second = presents/second, and seconds are not a
property of the game.

The port's 60 stands: the guest presents once per 60 Hz vblank
unconstrained, and 1 unit per present at 60/s is 60 units/s. Same answer as
my first position, finally with a tested mechanism instead of an inference.

This withdraws units-per-frame-is-not-a-constant.md in its central claim.
My "a time-based clock is immune to dropped frames so the dwell is stable"
was a real prediction and it failed -- the dwell doubled. The four-run
agreement I read as evidence was four runs at similar frame rates.

h3-units-per-frame-measured.md's +34 is now the anomaly rather than the
rule: 34 per label at 27.2 labels/s against 17 per present at 28.4
presents/s. Both cannot be presents. Not asserting it is wrong, only that
one of them must explain the disagreement.

Three of my four positions came from inference over a measured quantity;
this one came from changing an input and watching what moved. The
opportunistic comparison pointed exactly the wrong way because nothing
controlled what else differed between those captures.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
This commit is contained in:
sylph-decoder
2026-09-01 19:39:30 +00:00
parent 5d72bda77d
commit 705a8485dc
2 changed files with 117 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

91
docs/re/clock-is-frame-based-one-unit-per-present.md Normal file
View File

@@ -0,0 +1,91 @@
# ✅ The UI clock is FRAME-based: **1 unit per present**, verified by a forced frame rate
**Status: ✅ measured, by a designed test that REFUTED my own previous claim.**
2026-09-01. Instrument: ⟨capture⟩ ×3, one of them at a deliberately altered
presentation rate. Answered against
[`time-based-clock-preregistration.md`](time-based-clock-preregistration.md),
committed before the run.
Data: [`data/forced-framerate-test.txt`](data/forced-framerate-test.txt).
---
## The test, and it went against me
I claimed the clock was **time**-based and that `units/second ≈ 60` was the
invariant. I predicted that halving the frame rate would **double** the alpha step
and **leave** the dwell unchanged. I ran `--framerate_limit=30`:
| | frame-based | **time-based (my claim)** | **measured** |
|---|---|---|---|
| presents/s | ~27 | ~27 | **28.4** |
| modal Δα per present | 17 unchanged | 34 doubled | **17 — unchanged** |
| units/s | ~30 halved | ~60 unchanged | **30.2 / 30.3 — halved** |
| publisher dwell | ~8.5 s | ~4.2 s | **8.450 s — doubled** |
| developer dwell | ~7.0 s | ~3.5 s | **6.923 s — doubled** |
**Every discriminating row went to the frame-based column. My claim is refuted.**
Both controls passed first, as pre-registered:
* **Control 1, read before the step:** the limiter took effect — 28.4 presents per
host-second against 51–55 before, and the interval histogram's mass moved from
**one** 60 Hz vblank to **two** (422 of 468). Had this failed, neither
prediction would have been tested.
* **Control 2:** all **8/8** splash quad rects identical to the reference set, so
nothing but the frame rate differs between runs.
## What is actually true
> **The UI clock advances exactly 1 unit per presented frame.** The step is
> **17** on every quad in every capture — at 28.4, 51.4 and 54.8 presents per
> second. `255 × 1 / 15 = 17` with the declared `T = 15`.
So `units/second = presents/second`, and the *seconds* are whatever the frame
rate makes them. The dwell in seconds is **not** a property of the game.
## The conclusion for the port is unchanged, and now properly grounded
The guest, unconstrained, presents **once per 60 Hz vblank** — measured before the
limiter was applied (one vblank 71.7 %, two 24.6 %), and confirmed by this run
moving cleanly to two vblanks when told to. One unit per present at 60 presents
per second is **60 units/s**.
**The port's 60 is right.** It was right when I first said so for a bad reason,
right when I withdrew it, right when I replaced it with 120, and right now — the
difference is that the mechanism is finally tested rather than inferred.
## 🔴 What this withdraws, including of my own
* **`units-per-frame-is-not-a-constant.md` is WRONG in its central claim** and is
superseded by this page. Units per frame *is* a constant; it is 1.
* **My "dwell is stable across runs because a time-based clock is immune to
dropped frames"** was a real prediction and it **failed** — the dwell doubled.
The four-run agreement at 4.2 / 3.5 s that I read as evidence for a time-based
clock was just four runs at similar frame rates.
* ⚠️ **`h3-units-per-frame-measured.md`'s `+34` is now the anomaly**, not the rule.
It reports 34 per label at 27.2 labels/s; this capture reports 17 per present at
28.4 presents/s. **Both cannot be presents.** The likeliest reading is that an
`h3` label is not one present, and until that is checked its "2 units per frame"
should not be used. I have not checked it, and I am not asserting it is wrong —
only that it and this disagree at nearly the same rate, which one of them must
explain.
## The methodological point, since this is the fourth reversal today
Three of my four positions on this number came from **inference over a measured
quantity**; this one came from **changing an input and watching what moved**. The
opportunistic comparison — two captures that happened to differ — pointed exactly
the wrong way, because I had no control on what else differed between them. The
designed test cost one capture and settled it against my own expectation.
📌 And the pre-registration did its job in the only way that really counts: it
made the refuting result **unmissable**. Had I not written down "34, doubled"
first, "17" would have been easy to read as confirmation of something.
## Reach
⟨capture⟩ ×3 at two deliberately different rates, one machine, English locale.
The invariance of the step is the load-bearing part and now rests on a
manipulation rather than a coincidence. ❔ Whether the console presents at 60 is
still an inference from the vblank cadence — a short one, since a 360 vblanks at
60 Hz, but an inference.

26
docs/re/data/forced-framerate-test.txt Normal file
View File

@@ -0,0 +1,26 @@
# --framerate_limit=30. Pre-registered in time-based-clock-preregistration.md.
# CONTROL 1: 28.4 presents/host-s (was 51-55). Limiter took effect.
CONTROL 2 -- the eight splash quad rects must be unchanged:
quads found 8; matching the reference set: 8/8 -> PASS
THE DISCRIMINATOR -- modal alpha step per present:
pre-registered frame-based: 17 unchanged | time-based: 34 doubled
x[-0.52,0.52] y[-0.1,0.08] alphas [17, 34, 51, 68, 85, 102, 119, 136, 153]
steps [17, 17, 17, 17, 17, 17, 17, 17] modal=17
x[-0.39,0.39] y[0.35,0.55] alphas [17, 34, 51, 68, 85, 102, 119, 136, 153]
steps [17, 17, 17, 17, 17, 17, 17, 17] modal=17
x[-0.19,0.19] y[-0.12,0.12] alphas [17, 34, 51, 68, 85, 102, 119, 136, 153]
steps [17, 17, 17, 17, 17, 17, 17, 17] modal=17
x[-0.3,0.3] y[-0.62,-0.25] alphas [17, 34, 51, 68, 85, 102, 119, 136, 153]
steps [17, 17, 17, 17, 17, 17, 17, 17] modal=17
x[-0.41,0.41] y[0.32,0.57] alphas [68, 85, 102, 119, 136, 153, 170, 187, 204]
steps [17, 17, 17, 17, 17, 17, 17, 17] modal=17
UNITS PER SECOND -- pre-registered frame-based ~30 | time-based ~60:
splash 0: 244 presents, 8.450s host -> 255u/8.450s = 30.2 units/s
(boot1 4.263s, boot2 4.162s at ~52 presents/s)
splash 1: 204 presents, 6.923s host -> 210u/6.923s = 30.3 units/s
(boot1 3.457s, boot2 3.485s at ~52 presents/s)
VERDICT: FRAME-BASED -- my claim is REFUTED