diff --git a/authored/timing.json b/authored/timing.json index cc038168..ab66ca6c 100644 --- a/authored/timing.json +++ b/authored/timing.json @@ -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." ] } diff --git a/docs/port/BLOCKED.md b/docs/port/BLOCKED.md index 6a02c617..098e8ebc 100644 --- a/docs/port/BLOCKED.md +++ b/docs/port/BLOCKED.md @@ -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`.