Files
Sylpheed/docs/re/data/settle-vs-rest-against-captures.txt
sylph-decoder f102cf9209 handoff+method: land the ordinal retraction where the claims live
Marks the two void splash rows in the capture-comparison data file, withdraws the
three claims in HANDOFF, and corrects the METHOD entry -- whose 'a gradient across
buckets is not a mechanism' near-miss was itself resolved by a counter-example
taken with the wrong index.

General form recorded: an index that silently means something else produces
well-formed output for the wrong object, and this project has now been bitten
twice from opposite directions with 'everything still validates' both times.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 12:59:58 +00:00

66 lines
3.4 KiB
Plaintext

# 🔴 THE TWO SPLASH ROWS BELOW ARE VOID (retracted 2026-08-30).
# They used `screen render --build 10/11`, which takes a BUILD ORDINAL:
# `screen list` says [10] entry 12, [11] entry 15. Those are the LOADING
# screens. The rows scored loading-screen renders against SPLASH captures.
# I discarded them at the time for a railed gamma fit; the real reason is
# that they were the wrong screens, and the railing was that mismatch
# surfacing in the only place the instrument could report it.
# The `title` row is unaffected -- ordinal 4 is entry 4.
# See splash-settle-window-retraction.txt.
#
# Does UiBuild::settle_time() itself beat rest() against the GAME?
#
# The port ran my PROPOSAL against captures and favoured it 3/3, but tested
# ITS OWN settled pose, not settle_time(). It said so, and that gap is mine.
#
# GEOMETRY, established first: a 1280x720 render matches a 1279x675 capture
# by CROP, not scale --
# crop rows 0..675 RMSE 14.07
# resize bilinear RMSE 68.89
# crop rows 45..720 RMSE 79.61
# crop rows 22..697 RMSE 74.92
# The 45-row offset holds for a full 1280x720 DISPLAY frame; these committed
# captures are already the game surface.
#
# Gamma is fitted PER POSE, so each candidate gets its own best case and the
# comparison cannot be won by the fit. Search widened to 0.30..3.00 after the
# first pass railed at a 0.80 floor.
#
# screen pose gamma RMSE %>8 %>16
# title settle 0.84 8.17 15.28 3.16
# title rest 1.04 20.92 70.84 21.14
# -> SETTLE closer: 15.28 % vs 70.84 % at >8
#
# publisher settle 0.30 36.38 2.36 2.34 <- RAILED at the search edge; not a fit
# publisher rest 0.30 36.69 2.74 2.63 <- RAILED at the search edge; not a fit
# -> SETTLE closer: 2.36 % vs 2.74 % at >8
#
# developer settle 0.30 33.07 6.16 6.01 <- RAILED at the search edge; not a fit
# developer rest 0.30 33.42 6.54 6.30 <- RAILED at the search edge; not a fit
# -> SETTLE closer: 6.16 % vs 6.54 % at >8
#
# ✅ settle_time() beats rest() on all three capture-backed screens, so the
# IMPLEMENTATION and not just the direction is supported.
#
# ⚠️ ABSOLUTE agreement is poor and much worse than the port's (its title
# settled row is 0.21 %; mine is an order of magnitude above). My renderer
# omits things its does not, and a single global gamma is a crude
# photometric model. Take the ORDERING from this table, not the values.
#
# 🔴 AND ON A WIDER SEARCH (0.30..3.00) THE SPLASHES RAIL AT THE NEW FLOOR TOO.
# A fit that sits on the edge of its range is not a fit -- the photometric model
# is wrong for those two, and with the gamma railed their margins collapse:
# publisher settle 2.36 % vs rest 2.74 % (1.16x)
# developer settle 6.16 % vs rest 6.54 % (1.06x)
# Those two rows DO NOT ADJUDICATE and are not counted.
#
# ✅ ONE SCREEN ADJUDICATES, and it does so decisively. `title` fits at an
# INTERIOR gamma (0.84 settle / 1.04 rest) and gives
# settle 15.28 % rest 70.84 % at >8 -- 4.6x
# settle RMSE 8.17 rest RMSE 20.92 -- 2.6x
#
# So: settle_time() ITSELF, not merely the direction, beats rest() against the
# game on the one screen where my instrument is valid. The port's three-screen
# result remains the stronger evidence; this closes the gap it named between
# "the port's settled pose" and "UiBuild::settle_time()".