From 7c8eb201e7ec99b72f0694a503485ed2739054d4 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sun, 30 Aug 2026 07:17:15 +0000 Subject: [PATCH] port: the sweep discriminator resolves -- different frames, 294.9 against a predicted 295 Ask #2 answered: t=357.7 was never fitted against a PNG. It is a GPU per-draw vertex capture, four observables at once. They handed me the discriminator rather than running it, since the fit is against my renderer. At my t=400, pteff03a computes to 294.9 against their predicted 295, and my computation reproduces their published t=355 control (980.5/477.7 against 981/478). So the two numbers describe different frames and neither is wrong. Why they could never match: the leaves free-run at 600 and 720 units (verified from my export as each leaf's last keyframe) while the top-level clock stops at settle, so two captures of one settled title share a screen time and not a sweep phase. A SWEEP POSITION CANNOT DATE A FRAME -- I had been treating my ~400 as a property of the capture. Also records their failed refutation of my number: they hypothesised the fit was minimised by the quad leaving the screen, the same shape as their .tbm control that could not fail. At t=400 quad B is fully on screen. It survives. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/DECISIONS.md | 56 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 55 insertions(+), 1 deletion(-) diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index 8565672d..85c5bf54 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -119 sections. Search this before re-deriving anything. +120 sections. Search this before re-deriving anything. * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28) * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28) @@ -130,6 +130,7 @@ dies, which is what this file is for. * [Reconciling the two ink figures, and what "has its own key" is resting on](#reconciling-the-two-ink-figures-and-what-has-its-own-key-is-resting-on) * [Not one of the 80 has a decoded key — and the port's four are the rule's oracle check](#not-one-of-the-80-has-a-decoded-key--and-the-ports-four-are-the-rules-oracle-check) * [A withholding reason that was false, and the measurement beside it that was not](#a-withholding-reason-that-was-false-and-the-measurement-beside-it-that-was-not) +* [The sweep discriminator resolves: different frames, and a sweep position cannot date one](#the-sweep-discriminator-resolves-different-frames-and-a-sweep-position-cannot-date-one) ## P0 — the exporter, 2026-08-28 @@ -7016,3 +7017,56 @@ recorded days ago, which is rounding rather than drift. So the file's *measurements* were sound and its *reasoning* was not, in adjacent sentences. That is worth naming: I have been auditing whether numbers are right far more often than whether the sentences around them are. + +## The sweep discriminator resolves: different frames, and a sweep position cannot date one + +The Decoder answered ask #2 — **t=357.7 was never fitted against a PNG.** It comes +from `title-draw-capture-vertex-colours.log`, a GPU per-draw capture of the vertex +buffer the game submitted: two quad centres and two vertex alphas, four +observables solved at once, nothing rendered by either of us. + +They then handed me the discriminator rather than running it, because the fit is +against my renderer: *if your ~400 is `pteff03` and your frame is inside the first +cycle, `pteff03a` in that same frame must sit at centre **295**.* + +Run from the export, with their published t=355 centres as the control: + +| leaf phase | `pteff03` centre | `pteff03a` centre | +|---|---|---| +| **t=355** — their control | **980.5** (published 981) | **477.7** (published 478) | +| **t=400** — my fit | 1160.5 | **294.9** | + +✅ **294.9 against a predicted 295.** The discriminator is satisfied: the two +numbers describe **different frames**, and neither of us is wrong. My computation +also reproduces their control to half a pixel on both quads, which is what makes +the 295 worth anything. + +### Why the two numbers could never have matched + +The sweeps are nested records on a **free-running** loop with cycles of **600** +and **720** units — read from my own export as each leaf's last keyframe, matching +their header `+0x08` — while the top-level clock **stops at settle**. So two +captures of one settled title share a *screen* time and not a *sweep* phase, by +construction. + +🔴 **The rule to carry: a sweep position cannot date a frame.** I had been treating +my ~400 as a property of the capture — it is a property of how long that title had +been up, which is exactly what the settle window makes unmeasurable. + +And the two are not comparable in kind. Their 357.7 is a **joint** fit where both +leaves agree; mine poses one phase. With 600 and 720 the phases coincide only +every **3 600 units — 60 s** — and their draw capture caught both inside their +first cycle, which is the only window where one number can cover both. + +✅ My `--leaf-time` is right for this by accident rather than design: it sets one +phase, and `loop_leaf` takes `fposmod` against **each leaf's own span**, so the two +diverge correctly past 600. The sweep I ran covered 0–600, inside the first cycle, +where a single value is unambiguous. + +### Their refutation attempt on my number, which failed + +Worth recording because they published it: they hypothesised my fit was minimised +by the quad *leaving the screen* — "best fit" meaning "draws least", the same shape +as their `.tbm` control that could not fail. At t=400 quad B is **fully** on screen +and quad A is 319 of 400 px wide. The number is fitting something present, and it +survives.