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

re: the +0x08 falsifier does not identify +0x08 -- the value is right, my argument was wrong

Browse Source 
sylpheed-port aimed my own boundary finding at my loop-length control. Reproduced
from my reader over every pak: +0x04 has 0 violations too, so the falsifier rejects
+0x0c and accepts +0x04 and never discriminated. What identifies +0x08 is the
exactness statistic the page presents as secondary -- exact match in half the
records against 0 % for +0x04.

Population differs from theirs, 3311 records against 1781, because this scan takes
every pak and requires a timed keyframe, so the percentage moves but the
discrimination does not.

Second time this week with the weight on the wrong leg: a count taking credit for an
exclusion argument, now a falsifier taking credit for an exactness statistic, and
both times the real discriminator sat beside it described as a formality.

Their general form is sharper than my boundary rule: an interior consistency check
is satisfied by any internally consistent reading, and that is what a wrong offset
into a regular structure usually is.

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-31 03:52:09 +00:00
parent 91c808d4e5
commit 1adb4e2ee7
3 changed files with 118 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
docs/re/METHOD.md
View File

@@ -3206,3 +3206,32 @@ published alignment survives at both edges, both shifts fail.
📌 **The general rule: for any repeated structure, the evidence for the field order
lives at the first and last record.** Everything in between is compatible with every
phase, and checking it is the reassurance that feels like verification.
## An interior consistency check is satisfied by any internally consistent reading
`sylpheed-port` aimed my boundary finding at a control of mine and it landed. My
`+0x08` loop-length page rests on a falsifier: *an animation cannot restart before
its own last pose, so a wrong reading should produce violations, and none exist*.
🔴 **It does not identify `+0x08`.** Reproduced from my own reader over every pak:
| offset | violations | exact `== max t` |
|---|---|---|
| `+0x04` | **0 — passes** | **0.0 %** |
| `+0x08` | 0 | 49.6 % |
| `+0x0c` | 1 287 | 11.8 % |
A wrong reading one word left produces no violations either. **The discriminator is
the exactness statistic the page presents as secondary** — `+0x08` matches exactly
in half the records, `+0x04` in none.
📌 **Second time this week with the weight on the wrong leg**, and both have the
same shape: a *count* taking credit for an exclusion argument, then a *falsifier*
taking credit for an exactness statistic. **In both, the real discriminator was
sitting beside it, described as a formality.**
⚠️ Their statement of the general rule is sharper than my boundary version, which
does not transfer to a per-record header: **an interior consistency check is
satisfied by any reading that is internally consistent — and "internally
consistent" is what a wrong offset into a regular structure usually is.** The
boundary rule is the special case where the structure's edges break that regularity.