From f456c87d06beba30eca3c5e1aab9b13ca2ab8321 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Wed, 2 Sep 2026 18:35:54 +0000 Subject: [PATCH] re: F6 unit 3 -- the sweep's POSITION fits the declared track, origin at leaf t=0 Took the port's point and dropped the alpha line. Three exchanges had gone on alpha -- a bound, a refutation, a downgrade -- over 14 usable samples of 1754, when the position travels 2160 px monotonically in the same capture. pteff03's declared leaf track is linear at 4.000 px/unit: -639 at t=0, -39 at t=150, 1521 at t=540. The capture's first clean segment runs frames 746..1913 with x from -641.1 to +1522.1. Both endpoints land within ~2 px on a 2160 px travel, 0.1%. Two independent checks rather than one fitted parameter. A single wrap at frame 1914 confirms the declared 600-unit loop and falls after the segment. Answers the clock origin: the leaf's t=0 is its first drawn frame, so the game does not carry the leaf forward from the title's clock. That CONFIRMS the port's own correction -- they had attributed ~135 units of earliness to the leaf starting at title t=0 and withdrew it on two relayed numbers; the full series says the withdrawal was right. Rate here is 540 units in 1167 presents = 0.463 units/present, flagged as the weak half: one run, in presents, and it does NOT match the 1 unit/present the splash work established. Either the leaf runs a slower clock or one of the two is not what I think. The origin does not depend on it. And the useful negative: a linear fit across all 1754 samples gives max residual 1108 px on 1402 px of travel, 79%, because the trajectory wraps and a straight line through a sawtooth is meaningless. A fit not checked for residual would have reported a slope and a plausible origin from that same data -- which is exactly why the port's tool selftest must reject a wrong-shape series, and why I segmented before fitting. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t --- docs/re/f6-unit3-sweep-track-fits.md | 73 ++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 docs/re/f6-unit3-sweep-track-fits.md diff --git a/docs/re/f6-unit3-sweep-track-fits.md b/docs/re/f6-unit3-sweep-track-fits.md new file mode 100644 index 00000000..c1f5d0fe --- /dev/null +++ b/docs/re/f6-unit3-sweep-track-fits.md @@ -0,0 +1,73 @@ +# F6 unit 3 — the sweep's **position** fits the declared track: origin at leaf `t=0`, both endpoints within ~2 px + +**Status: ✅ measured ⟨capture⟩ ×1.** 2026-09-02. + +**Question:** where does the sweep's own clock start, and how fast does it run? +**Look at:** its pixel x against the declared leaf track. Pass = the ends land on +the declared endpoints; fail = they do not. +**Not covered:** whether parent alpha multiplies in (that is unit 2, still 🟡); +F5. + +--- + +## Why position, and not alpha — the port's point, adopted + +Three exchanges went on alpha: a bound, a refutation, a downgrade, over **14 +usable samples of 1754**. Alpha is 8-bit, quantised and non-monotone, and a +grouping slip in its tail is indistinguishable from signal. **The position travels +2 160 px monotonically in the same capture and cannot fail those ways.** The port +made that argument and built `tools/port/fit-trajectory` for it; this is the same +measurement, run on my side against the raw stream. + +## The measurement + +`pteff03`'s declared leaf track is **linear at 4.000 px/unit**: +`x = −639 @ t=0`, `−39 @ t=150`, `1521 @ t=540`. + +The capture's sweep, converted from NDC centre to pixel left edge: + +``` +first segment frames 746 … 1913 x −641.1 → +1522.1 +declared t = 0 … 540 x −639 → +1521 + Δ −2.1 px +1.1 px +``` + +> **Both endpoints land within ~2 px on a 2 160 px travel — 0.1 %.** Two +> independent checks, not one fitted parameter. + +📌 **A single wrap** at frame **1914** (x jumps back > 500 px) confirms the +declared 600-unit loop, and it falls after the segment measured, so the segment is +clean. + +## What it answers + +* **Clock origin: the leaf's `t = 0` is its first drawn frame.** The −2.1 px start + says the game does not carry the leaf forward from the title's clock. ✅ This + **confirms the port's own correction** — they had earlier attributed ~135 units of + earliness to the leaf clock starting at title `t=0`, and withdrew it on two + relayed numbers; the full series says their withdrawal was right. +* **Rate here: 540 declared units in 1 167 presents = 0.463 units/present.** + +⚠️ **The rate is the weak half and I am flagging it rather than burying it.** It is +in *presents*, on one emulator run, and it does **not** match the 1 unit/present +the splash work established. Either the leaf runs on a slower clock than the +element timeline, or one of the two is not what I think it is. **The origin does +not depend on it** — that rests on the endpoints alone. + +## 🔴 A linear fit across the whole capture FAILS, and that is the useful part + +Fitting `x = a + b·frame` over all 1 754 samples gives **max residual 1 108 px on +1 402 px of travel — 79 %**. Read alone that says "the model is wrong". It is not: +the trajectory **wraps**, and a straight line through a sawtooth is meaningless. + +**A fit that had not been checked for residual would have reported a slope and a +plausible-looking origin from that same data.** The port's insistence that their +tool's selftest must *reject a wrong-shape series* is exactly this failure, and it +is why I segmented before fitting rather than after. + +## Reach + +⟨capture⟩ ×1, one boot, one segment, one element. The identification is now +sound — unit 2's correction established both size-keys are `pteff03` and it +travels left-to-right, which the declared track predicts and the measurement +matches at both ends. `pteff03a` does not appear in this capture and is untested.