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 09af29f1dd
commit 5e2dd62732
2 changed files with 58 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
docs/port/HANDOFF.md
View File

@@ -39,10 +39,27 @@ archive gives **1**, `EXTRAS` → another archive gives **3**. Same kind of
destination, gap set by the outgoing screen — the strongest support for that
dependence, since it removes the destination as the variable.
🔴 **But the clean ordering is gone.** `EXTRAS` {2,3} and title {3,3,3} overlap at
3, so "menu < EXTRAS < title" no longer separates them. What survives is weaker:
the outgoing screen constrains the gap to a ~2-wide band, and the bands are not
disjoint.
🔴 **Superseded again, and this time sharpened.** With 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 → another archive | 1 | 1 | — |
| `EXTRAS` → another archive | 3 | 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 but the pair determines.
📌 **For `black_hold_units`:** a constant is excluded, and keying on the outgoing
screen is excluded too. Any keyed version would have to be keyed on the **ordered
pair**, with a measured value for each — six pairs known, two of them replicated,
and nothing declared predicting any of them.
📌 **The gap tracks the screen being LEFT — but CONSTRAINS rather than determines
it.** ⚠️ Corrected the same day, prompted by `sylpheed-port` asking for *"a second

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.