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

re: the gap is a property of the ORDERED PAIR -- and the guard verified in a run

Browse Source 
Two things in one run, on the screen that motivated both.

First, the effective-config guard I had flagged as "not yet verified" -- leaving a
doubt in my own file, which is the shape sylpheed-port had just caught themselves
in. Verified now:

    arming on       = menu  [screen_id: cannot separate menu/EXTRAS]
    discriminator   = extras  rmse=18.94  (other main_menu 30.09, margin 11.15)

Before the fix this run would have announced "arming on = menu" while armed on
EXTRAS. The ambiguity is visible instead of hidden.

Second, a replicate of the table's weakest cell. Second EXTRAS -> menu: outgoing
quad 229, 255, 255 across frames 29-31, then TWO empty frames at 32 and 33. Gap =
2, identical to the first.

Eight transitions now say something sharper than the outgoing-screen story, which
is superseded a second time:

  title  -> menu    3, 3, 3   n=3   repeats agree
  EXTRAS -> menu    2, 2      n=2   repeats agree
  menu   -> title   0         n=1
  menu   -> EXTRAS  1         n=1
  menu   -> other   1         n=1
  EXTRAS -> other   3         n=1

Every repeated pair is identical -- five replicates, no variation -- and every
differing value comes from a different pair. The same origin gives different
values to different destinations (menu 0 vs 1, EXTRAS 2 vs 3). So the origin
CONSTRAINS the gap and the ORDERED PAIR determines it, reproducibly.

For the port: a constant black_hold_units is excluded and keying on the outgoing
screen is excluded too. Any keyed version must be keyed on the ordered pair, with
a measured value per pair -- six known, two replicated, none predicted by anything
declared.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 19:02:19 +00:00
parent 040b2a7855
commit ac1ee549f3
2 changed files with 58 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
docs/re/data/fade-four-transitions.txt
View File

@@ -246,3 +246,40 @@ frame untextured full-screen textured (distinct) draws tex
# the outgoing screen constrains the gap to a 2-wide band, and different outgoing
# screens have different bands that are not disjoint. Still not predictive, and
# now not even cleanly ordered.
################################################################################
# EIGHTH TRANSITION: a SECOND EXTRAS -> menu, via (B). 2026-08-30.
# Taken to verify the fixed effective-config guard on the one screen screen_id.py
# cannot resolve, and to replicate the table's weakest cell at the same time.
#
# ✅ THE GUARD WORKS, verified in a run rather than asserted:
# arming on = menu [screen_id: cannot separate menu/EXTRAS]
# discriminator = extras rmse=18.94 (other main_menu 30.09, margin 11.15)
# Before the fix this run would have announced "arming on = menu" while armed on
# EXTRAS. The ambiguity is now visible instead of hidden.
#
# frames 29-31 outgoing quad 229, 255, 255
# frames 32, 33 EMPTY: 3 draws, 0 textured
# frames 34-38 incoming menu's quad decaying 169, 148, 106, 63, 21
# GAP = 2, identical to the first EXTRAS -> menu.
#
################################################################################
# 📌 EIGHT TRANSITIONS: THE GAP IS A PROPERTY OF THE ORDERED PAIR, NOT THE ORIGIN
#
# transition gaps n repeats agree?
# title -> menu 3, 3, 3 3 YES
# EXTRAS -> menu 2, 2 2 YES
# menu -> title 0 1 -
# menu -> EXTRAS 1 1 -
# menu -> other 1 1 -
# EXTRAS -> other 3 1 -
#
# EVERY repeated pair is identical -- 3/3 and 2/2, five replicates, no variation.
# EVERY differing value comes from a DIFFERENT pair. And the same origin gives
# different values to different destinations: menu 0 vs 1, EXTRAS 2 vs 3.
#
# 🔴 So "the outgoing screen determines the gap" is superseded a second time. The
# origin CONSTRAINS it (menu {0,1}, EXTRAS {2,3}, title {3}); the ORDERED PAIR
# determines it, reproducibly. Still nothing declared predicts which value a pair
# gets, so this remains a description with five replicates behind it rather than a
# rule.