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

port: escalation resolved -- a uniform black hold is positively excluded

Browse Source 
Their measurement orders the four gaps by the screen being LEFT: menu 0 and 1
frames, EXTRAS 2, title 3. Direction, button and incoming screen are each
positively ruled out -- the same pair both ways differs, (B) gives 0 and 2 while
(A) gives 1 and 3, and an incoming menu takes 3 from the title and 2 from EXTRAS.

That resolves the escalation I raised: a uniform value is not merely unsupported
but excluded, so 0 is no longer one option among several. It is the only honest
uniform choice, because it models the gap as absent rather than as constant.
black_hold_units is unchanged at 0; its justification is replaced.

And my own rule is now refuted rather than unadopted. Gap plus the incoming
screen's opening black-clear held at 16/16/18 on three transitions; their fourth
gives 16, 14, 16, 18, and decisively the two transitions with the same incoming
screen have different gaps, so the incoming screen cannot determine it. A fourth
point did to a three-point fit exactly what it should.

Not keying per outgoing screen: three screens with one value each restates the
data, which is the objection I raised against my own 16/16/18. BLOCKED row
rewritten to ask for a second value on any one outgoing screen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 18:35:00 +00:00
parent 1e02008f55
commit 51d8c4cdfd
2 changed files with 36 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
authored/timing.json
View File

@@ -145,38 +145,30 @@
],
"black_hold_units": 0,
"black_hold_why": [
"0, RE-DERIVED against FOUR measurements, not inherited from three.",
"0 = NOT MODELLED. The escalation is resolved: a uniform value is positively",
"EXCLUDED, so 0 is no longer one option among several -- it is the only honest",
"uniform choice, because it is the one that does not claim a constant exists.",
"",
"The Decoder's measured black gaps are now 0, 6, 4, 6 units across four",
"transitions. When this was set to 0 the multiset was (0, 4, 6), and they held",
"me to re-stating the choice against the new data rather than carrying it --",
"the same standard I applied to check-all's stale allowance.",
"The Decoder ordered the gaps by the screen being LEFT (frames): menu 0 and 1,",
"EXTRAS 2, title 3. Three hypotheses are positively ruled out, not merely",
"unsupported. DIRECTION: EXTRAS->menu (2) and menu->EXTRAS (1) are the same",
"pair both ways and differ. BUTTON: (B) gives 0 and 2, (A) gives 1 and 3.",
"INCOMING SCREEN: an incoming menu takes 3 from the title and 2 from EXTRAS.",
"",
"The arithmetic moved AGAINST 0 and it is worth writing down rather than",
"burying: a uniform 6 is wrong on 2 of 4 transitions for a total error of 8;",
"0 is wrong on 3 of 4 for a total of 16. Choosing 0 cost 1.7x the best fit on",
"three measurements and costs 2.0x on four. 0 is now the MINORITY outcome --",
"three of four transitions do have a gap.",
"So the quantity varies 0-3 frames by outgoing screen, and any uniform non-zero",
"value is wrong as a MODEL rather than merely off in magnitude. 0 models the",
"gap as absent; 6 would model it as constant, which the data excludes.",
"",
"IT IS STILL 0, and the reason is unchanged because it was never the fit: 0",
"adds no black the game does not have, which is the tie-breaker",
"input_during_transition already uses in this file, and it is measured-correct",
"for a real transition rather than for an average of them. Picking 6 because",
"it appears twice is choosing a mode from four samples with no rule behind it.",
"MY OWN RULE IS REFUTED, not just unadopted. It was gap + the incoming",
"screen's opening black-clear = a constant, holding at 16/16/18 on three",
"transitions. Their fourth gives 16, 14, 16, 18 -- and decisively, the two",
"transitions with the SAME incoming screen (main_menu) have different gaps,",
"so the incoming screen cannot determine it. A fourth point did to a",
"three-point fit exactly what it should.",
"",
"ALSO CHANGED: the gap is NOT machine-dependent. It was defensible to hold 0",
"partly because the quantity might be a load and therefore unauthorable; the",
"Decoder has now shown it is deterministic to the frame -- bundle size runs the",
"wrong way, and a repeat run moved press-to-first-change by ~12 frames while",
"the gap did not move at all. So this is a real game quantity with a rule",
"nobody has found, not noise. That REMOVES an excuse for 0 without supplying a",
"value.",
"",
"TRIPWIRE, because 'invent nothing' can stop being conservative: if the gap is",
"non-zero in most transitions and no rule emerges, systematically omitting a",
"real quantity is no longer the cautious choice -- it is a different invention.",
"Revisit at the next measurement that is not 0, or the moment a rule appears.",
"The port is currently wrong by 4-6 units on three of four known transitions",
"and says so here rather than in a number that looks decided."
"DO NOT key this per outgoing screen yet. Three outgoing screens with one",
"value each restates the data rather than predicting it -- the same objection",
"I raised against my own 16/16/18. Key it when a screen has more than one",
"measured value, and key it on the screen being LEFT."
]
}

16
docs/port/BLOCKED.md
View File

@@ -863,7 +863,7 @@ units/frame simply not apply to them? And note the two-strip agreement constrain
the strips to each other, not the absolute rate -- both ratios come from one
capture under one fps assumption, and 1 unit per 1/30 s at 28.5 fps gives 1.053.
### `black_hold_units`: 0 is now wrong on 4 of 5 transitions, and every alternative is a fit
### ~~`black_hold_units`: 0 is now wrong on 4 of 5 transitions~~ — RESOLVED: uniform is excluded
**Derived from Decoder `auto/build-ordinal-audit` plus my own `verify-dwell`.**
@@ -885,3 +885,17 @@ ever measured, that would test the constant-black-period idea properly.
Value stays 0 meanwhile; `verify-dwell` reports the shortfall rather than
absorbing it.
### When there is more than one gap measurement per outgoing screen
**Derived from Decoder `auto/build-ordinal-audit`.**
They ordered the gaps by the screen being LEFT: menu 0 and 1 frames, EXTRAS 2,
title 3 -- ruling out direction, button and incoming screen positively. That
resolves the earlier escalation: **a uniform value is excluded**, so
`black_hold_units` stays 0 meaning *not modelled*.
**The ask, low priority:** a second measurement for any one outgoing screen. Three
screens with one value each restates the data; two values for one screen would
make "keyed on the outgoing screen" predictive rather than descriptive. Nothing
ships on it -- the port omits the gap and says so in `verify-dwell`.