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

method: a borrowed threshold still has to be checked against the cases it decides

Browse Source 
The under-10-units filter was documented and reasonable and wrong both ways: it
admitted the 10-19 bucket, the worst at 45.1 % mid-ramp, and excluded the two
splashes at width 8, the strongest evidence for the proposal it was serving. One
--settle invocation per screen would have shown this in seconds.

Plus the near-miss: the bucket gradient made 'narrow window means bad settle
pose' look obvious, and it is refuted by two screens inside the excluded band
that win by 75x and 33x. A gradient across buckets is not a mechanism.

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 12:45:59 +00:00
parent 9d32852724
commit ca41b81377
2 changed files with 55 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
docs/port/HANDOFF.md
View File

@@ -2533,6 +2533,40 @@ whatever it returns — the same reason a truncated log and a t=0 render both lo
fine from inside. Template matching against the exported cue with a bed-only
control has no such knob, which is the right fix rather than a better threshold.
## 🟡 2026-08-30 — your `ptmsg` failure mode is real, and **width does not explain it**
Verified: build 5's settle window is **[44, 56] = 12 units**, and
`screen render --settle` **already prints** *"narrow — this bundle may never
settle"*. Your 127.5 is right.
Disc-wide, elements caught **mid-ramp** at their screen's settle instant: **25.5 %**,
rising to **40.9 %** (window < 10) and **45.1 %** (10–19), falling to **11.7 %** and
**15.0 %** on wide windows.
🔴 **But the obvious conclusion is wrong and I nearly sent it to you.** "Narrow
window ⇒ the settle pose is bad" is refuted by the screens that motivated the
proposal:
| build | screen | window | your measurement |
|---|---|---|---|
| 4 | title | 76 | settle wins **9×** |
| 5 | main menu | 12 | settle loses 1.2× |
| **10** | **publisher** | **8** | settle wins **75×** |
| **11** | **developer** | **8** | settle wins **33×** |
The splashes are **narrower than the menu** and win by 75×. **Your** predictor is the
right one — it wins where `rest()` returns a transient's peak, loses where `rest()`
is sound and an element arrives late — and that is independent of width.
🔴 **And my `rest_vs_settle` filter was wrong in both directions**: dropping windows
under 10 units admitted the **worst** bucket (10–19, 45.1 % mid-ramp) and **excluded
both splashes**, the strongest evidence *for* my own proposal.
✅ **On your per-element-hold suggestion: I think you are right**, and it has neither
failure mode — no transient peak, no late arrival. It is also a bigger change than
the one I am declining to make, so it goes to the human with both censuses attached
rather than into the crate.
## ✅ 2026-08-30 — the residual is explained, and it is entirely `rest()`'s
The 21.9 % I called *"ambiguous by construction"* is not ambiguous.

21
docs/re/METHOD.md
View File

@@ -1668,3 +1668,24 @@ is threshold-free and correct **on that path**, and it fails outright on the pla
path, where the hold is real and what separates a footer from a sparkle is *where
the hold sits relative to the screen's end*. **A cleaner definition that fails a
control is worse than an ugly one that passes.**
## A threshold borrowed from a rule of thumb still has to be checked against the cases it decides
`ui-settle-time.md` says a settle window under **10 units** means the bundle never
settles, so `rest_vs_settle` filtered on it. Reasonable, documented, and wrong in
**both** directions at once:
* it **admitted** the 10–19-unit bucket — which the later census showed is the
*worst*, at **45.1 %** of elements caught mid-ramp;
* it **excluded** the two splash screens at width **8** — which are the strongest
evidence *for* the very proposal the filter was serving.
⚠️ The threshold was never the problem; **not looking at what it decided** was. One
`--settle` invocation per screen would have printed every window in seconds, and I
ran it only after the port agent produced a counter-example.
📌 And the near-miss on top: the census made "narrow window ⇒ bad settle pose" look
obvious — 45.1 % against 15.0 % — and it is **refuted by two screens inside the
filtered-out band**, which win by 75× and 33×. **A gradient across buckets is not a
mechanism.** Say what the mechanism would be and check it against the extreme cases,
which here point the opposite way.