From 2dfc20bc0f7ca6499e5a2aa6ae08f91008d4aced Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 17:28:00 +0000 Subject: [PATCH] re: WITHDRAW the 8.5 % dwell systematic -- I measured one element, not the screen sylpheed-port said the port plays the full group (255 and 210 units) rather than my 240/195, and they are right for a reason sharper than either of us first had. The _eff elements ramp alpha 0 -> 255 over t=0..15 while the main logo is still fully transparent: palogo_sqex.t32 0:a=0 15:a=0 30:a=255 ... 255:a=0 palogo_sqex_eff.t32 0:a=0 15:a=255 30:a=212 45:a=0 So the SCREEN is visible from within t=0..15 and its visible span is the full group. My "240 units visible" was ONE ELEMENT's visible span, computed while another element of the same build was already on screen -- which is exactly the error class I was writing up when I made it. Recomputed against the screen: publisher 1.011/1.083/1.028, developer 1.002/1.001/0.962, mean 1.0146 with one measurement BELOW unity, against my 1.085 with none below. That is not a clock at 54 u/s. The systematic is gone and Q1 stands unqualified. The consequence was wrong too: "a port playing 240 units at 60 shows the splash 0.42 s less" -- it plays 255, so the gap is 0.174 s, and on the developer splash the port runs longer than my mean. No direction to correct in. What survives weakly: against the full group the publisher runs long in all three boots while the developer sits at unity. Three boots per screen is thin and it is not a systematic. METHOD: state the number, and state what it is a number OF. Four instances of this family now -- pivot anchor as extent, centre track as bounding box, cycle length as motion duration, one element's visible span as the screen's -- and two of the four arose because the PUBLISHER of the number never said what it spanned. The reader reasoned correctly from the only definition available each time. Publishing a quantity's extent in the same breath is cheaper than every check in that file. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/re/METHOD.md | 15 ++++++++++ docs/re/boot-order-and-splash-dwell.md | 41 +++++++++++++++++++++++++- 2 files changed, 55 insertions(+), 1 deletion(-) diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index ab4260e8..a193fba6 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -409,6 +409,21 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the and where the latency is unknown, sample repeatedly rather than once, so a slow effect is distinguishable from no effect. +* 📌 **State the number, and state what it is a number OF.** This corpus has now + produced four instances of one family, and they cost more than any other class of + error here: a **pivot anchor** read as a drawn extent (a zero measured where + nothing moves), a **centre track** read as a bounding box, a **cycle length** read + as a motion duration (a rate 10 % wrong), and **one element's visible span** read + as the screen's (an 8.5 % "systematic" that did not exist). ⚠️ Two of the four + arose because the *publisher* of the number never said what it spanned — + `sylpheed-port` quoted a dwell of 4.28 s across two messages without once saying + which span it covered, and I quoted 240 units without saying it was one element's. + Each time the reader reasoned correctly from the only definition available. + **The fix is cheaper than every check in this file: when you publish a quantity, + publish its extent in the same breath.** It is the same shape as an observation + window shorter than the effect — a mismatch between what you are looking at and + what you believe you are looking at. + ## Runtime / emulator * **Look at the PNG** — and check its dimensions. diff --git a/docs/re/boot-order-and-splash-dwell.md b/docs/re/boot-order-and-splash-dwell.md index bccf7b67..9c508de0 100644 --- a/docs/re/boot-order-and-splash-dwell.md +++ b/docs/re/boot-order-and-splash-dwell.md @@ -89,7 +89,46 @@ title — [`ui-keyframe-time-unit.md`](ui-keyframe-time-unit.md)). ✅ **Classified decoded.** The port reads **240 units** for the publisher and **195 units** for the developer and authors nothing. -## 🟡 But the game runs them ~8.5 % LONG, six times out of six +## 🔴 WITHDRAWN — "the game runs them ~8.5 % long". I measured one element's span and called it the screen's. + +**Retracted the same day.** `sylpheed-port` said the port plays the **full group** +— 255 and 210 units — not my 240/195, and they are right for a reason sharper than +either of us first had. The `_eff` elements ramp **α 0 → 255 over t=0..15**, while +the main logo is still fully transparent there: + +``` +palogo_sqex.t32 0:a=0 15:a=0 30:a=255 235:a=255 239:a=232 251:a=32 255:a=0 +palogo_sqex_eff.t32 0:a=0 15:a=255 30:a=212 45:a=0 +``` + +So **the screen is visible from within t=0..15**, and its visible span is 0→255 +and 0→210 — the full group. My "240 units visible" was **one element's** visible +span, computed while another element of the same build was already on screen. + +Recomputed against the screen: + +| | ratios | | +|---|---|---| +| publisher (255 u = 4.250 s) | 1.011, 1.083, 1.028 | | +| developer (210 u = 3.500 s) | 1.002, 1.001, **0.962** | one **below** unity | +| **mean** | **1.0145** | against 1.085 before | + +A 1.5 % mean with a measurement below unity is not a clock running at 54 u/s. +**The systematic is gone and Q1 stands unqualified.** + +⚠️ **And the consequence I drew was wrong too.** "A port playing 240 units at 60 +shows the publisher splash 0.42 s less" — it plays 255, so the gap is 0.174 s, and +on the developer splash the port runs *longer* than my mean. There is no direction +to correct in, and nothing here supports moving `keyframe_units_per_second`. + +🟡 **What survives, weakly:** against the full group the publisher still runs long +in all three boots (1.011, 1.083, 1.028) while the developer sits at unity. Three +boots per screen is thin and it is not a systematic. + +📌 **This is the fourth instance of one family** — pivot anchor read as drawn +extent, centre track as bounding box, cycle length as motion duration, and now +**one element's visible span read as the screen's**. Every one is a number used as +though it described the thing beside it. `sylpheed-port` reported their `verify-dwell` at 4.28 s / 3.58 s and called it agreement with these boots. Checking the arithmetic rather than the impression: