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

port: the 92.3-vs-49.6 gap is entirely the denominator, and my number lacked its population

Browse Source 
Reproducing my offset result, the Decoder reported the same discrimination over
3311 records against my 1781, with exactness 49.6% against my 92.3%, attributing
the difference to a scan that 'takes every pak and requires a timed keyframe'.
Both scans are described identically, so at least one was narrower than its own
description.

Counting my survivors per filter: 3311 records declared by parse_build, 3311
within bounds, 3311 carrying the RATC magic, 3311 parsing as nested builds, and
1781 with at least one timed keyframe. So 3311 is the count BEFORE the timed
filter.

The arithmetic closes it: 1643/1781 is 92.3% and 1643/3311 is 49.6%, their figure
exactly. Same numerator. Their denominator includes the 1530 records with no timed
keyframe, where 'does +0x08 equal the largest keyframe time' has no meaning --
max t is 0 and every one counts as not-exact by construction. So their stated
filter is not applied, and 49.6% is not a weaker version of 92.3% but 1643
successes over a denominator containing 1530 questions that were never asked.

The discrimination is untouched: +0x04 gives 0% under either denominator, so the
offset conclusion stands on both scans.

And my own number needed a qualifier it did not carry. 92.3% is 'of the records
where the question is meaningful', not 'of nested records', and I have quoted it
bare since 2026-08-30 including into screen.rs's doc comment -- a
population-scoped statistic reported without its population, the same shape as a
negative reported without its reach. Qualified in place.

Two agents, one number, and the disagreement was entirely in the denominator;
neither of us was wrong about the disc. A cheaper failure than the offset one and
a more common one: the numerator agreed to the unit, which is what makes a
denominator mismatch invisible.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-31 03:53:50 +00:00
parent 36a2f8345f
commit 7730f4737f
3 changed files with 103 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
docs/port/DECISIONS.md
View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
308 sections. Search this before re-deriving anything.
309 sections. Search this before re-deriving anything.
* [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
* [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -319,6 +319,7 @@ dies, which is what this file is for.
* [The backfill: 17 was 12, and 12 is now 0](#the-backfill-17-was-12-and-12-is-now-0)
* [🔴 Their record layout was wrong and I had copied it — fourth relayed aside](#their-record-layout-was-wrong-and-i-had-copied-it--fourth-relayed-aside)
* [🔴 My falsifier never identified the offset — the half I called a formality did](#my-falsifier-never-identified-the-offset--the-half-i-called-a-formality-did)
* [The 92.3 %-versus-49.6 % gap: same numerator, and their filter is not applied](#the-923--versus-496--gap-same-numerator-and-their-filter-is-not-applied)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -15210,3 +15211,50 @@ regular structure usually is.**
is worth keeping: **while clearing it, not while building the tool.** Clearing put
me in contact with the individual items; building had only put me in contact with
the rule.
## The 92.3 %-versus-49.6 % gap: same numerator, and their filter is not applied
Reproducing my offset result, they reported the same discrimination over a
**different population — 3 311 records against my 1 781** — with exactness at
**49.6 %** against my **92.3 %**, attributing the difference to *"this scan takes
every pak and requires a timed keyframe"*. Both scans are described identically,
so at least one was narrower than its own description. Counting my survivors at
each filter:
| filter | survivors |
|---|---|
| records declared by `parse_build` | **3 311** |
| within the entry's bounds | 3 311 |
| carrying the `RATC` magic | 3 311 |
| parsing as a nested build | 3 311 |
| **with at least one timed keyframe** | **1 781** |
📌 **3 311 is the count *before* the timed filter.** And the arithmetic closes it:
```
1643 / 1781 = 92.3 % (mine)
1643 / 3311 = 49.6 % (theirs, exactly)
```
**Same numerator.** So their denominator includes the **1 530 records with no
timed keyframe at all**, where *"does `+0x08` equal the largest keyframe time?"*
has no meaning — there is no largest keyframe time, `max t` is 0, and every one of
them counts as "not exact" by construction.
🔴 **So their stated filter is not applied**, and the 49.6 % is not a weaker
version of my 92.3 % — it is **1 643 successes divided by a denominator containing
1 530 questions that were never asked.**
✅ **The discrimination is untouched**, as they said: `+0x04` gives **0 %** under
either denominator, so the offset conclusion stands on both scans.
⚠️ **And my number needs its own qualifier, which it did not carry.** 92.3 % is
*"of the records where the question is meaningful"*, not *"of nested records"*.
I have been quoting it bare since 2026-08-30, including into `screen.rs`'s doc
comment — **a population-scoped statistic reported without its population**, which
is the same shape as a negative reported without its reach.
📌 Two agents, one number, and the disagreement was **entirely in the denominator**
— neither of us was wrong about the disc. That is a cheaper failure than the
offset one and a more common one: **the numerator agreed to the unit, which is
exactly what makes a denominator mismatch invisible.**