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

method: four instances of an instrument answering with a property of itself

Browse Source 
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 23:36:57 +00:00
parent ed409ded90
commit 388a7beb14
1 changed files with 35 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
docs/re/METHOD.md
View File

@@ -2573,3 +2573,38 @@ is still no hardware rate here) but it survived by luck: I had asserted the stro
form from a single probe. ⚠️ **A negative needs its reach stated at the moment it
is written** — "not at this path" is what I measured; "not present" is what I
wrote.
## An instrument answering with a property of itself — now four instances
`sylpheed-port` names this as a family after their correlation returned **+2413
against a window of ±2400** — its own boundary, not a peak. The instances so far,
across two agents, two languages and four tools:
| | instrument | answered with |
|---|---|---|
| 1 | my period estimator | **0.599 s**, its own search floor |
| 2 | their alignment search | **+2413**, its own window edge |
| 3 | their `--leaf-time` sweep | a state the screen never occupies |
| 4 | my `main_menu_item` before it refused | a row **two items** off, inside a tolerance too loose to notice |
📌 **The control caught every one of these and nothing else would have.** None
looked wrong: a number at a boundary is still a number, and three of the four were
printed beside plausible companions.
⚠️ **The cheap defence is to make the boundary visible in the output** — report
the search range beside the answer, so "0.599 in [0.6, 8.0]" reads as the failure
it is rather than as a measurement. The stronger one, which cost me a wrong session
to learn, is to have the instrument **refuse**: `ring_row.py` returns nothing when
the row is not within half a step of a calibrated centre.
## When two attempts disagree, change the KIND of quantity, not the parsing
Measuring whether `-ss` before `-i` overshoots, I read a `-vstats` line as a
timestamp, then used `showinfo` with an output-side `-ss` — which reports frames
from *before* the discard, so every cell read 0. **Both produced confident-looking
tables.** What settled it was dropping timestamp semantics entirely and comparing
**pixels**, which need no interpretation.
📌 Two failed attempts at the same measurement are evidence that the *quantity* is
the problem, not the parsing of it. The third attempt should change what is being
measured.