ReaperOfVeriod/Going-Commando
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

The 394 does not survive: 0xc0's rate rises with immediate-set size

Browse Source 
Ran the size-independent statistic db1e69c asked for, and it confirms the
confound. Bucketing level-0 functions by distinct-immediate count, the rate
containing 0xc0 is:

    0-15   72/1082    6.7%      64-79   31/59   52.5%
    16-31 119/713   16.7%      80-95   13/25   52.0%
    32-47 104/291   35.7%     112-127   3/7    42.9%
    48-63  39/119   32.8%     624+      1/1   100%

Monotone from 6.7% to over 50%. Pigeonhole: a function with hundreds of distinct
immediates has more chances to contain any particular value.

So the 394 is largely a list of large functions and '394 of 2,323' was never a
shortlist. db1e69c was right; 3ea5ab7's framing was wrong and is corrected here.

This does not retract the neighbour result. 0xc0 being enriched over 0xb8-0xc8,
and 0xc0 being enriched in bigger functions, are separate claims and both hold.
What it retracts is the inference that the 394 are candidates for anything.

The control that would settle it: 0xc0's rate against a specific neighbour's rate
within the same set-size bucket. Not measured, and named so the next attempt
starts there rather than re-ranking by size.

No test -- the bucket rates are the finding, and an assertion on any single
threshold would be arbitrary.
This commit is contained in:
ReaperOfVeriod
2026-10-14 05:32:34 +02:00
parent db1e69c0ab
commit 06531fb66c
1 changed files with 34 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plan/level-assets.md
+34
View File
@@ -2072,3 +2072,37 @@ been measured.
Recorded rather than claimed as progress: ranking by size is the wrong first cut,
and the reason is a confound that would have made the result look better than it
was.
### The size-independent statistic: the 394 does not survive
Run it, and the confound db1e69c predicted is confirmed. Bucketing every level-0
function by how many distinct immediates it carries, and taking the rate at which
each bucket contains `0xc0`:
distinct immediates with 0xc0 / total rate
0- 15 72 / 1,082 6.7%
16- 31 119 / 713 16.7%
32- 47 104 / 291 35.7%
48- 63 39 / 119 32.8%
64- 79 31 / 59 52.5%
80- 95 13 / 25 52.0%
112- 127 3 / 7 42.9%
624+ 1 / 1 100%
The rate rises monotonically with set size, from 6.7% to over 50%. That is
pigeonhole: a function with hundreds of distinct immediates has more chances to
contain any particular value. **The 394 is mostly a list of large functions**, and
"394 of 2,323" was never a shortlist. db1e69c was right and 3ea5ab7's framing was
wrong.
This does **not** retract the neighbour result. `0xc0` being enriched over
0xb8-0xc8 and `0xc0` being enriched in bigger functions are two different claims
and both can hold. What it retracts is the inference that the 394 are candidates
for anything.
**The control that would settle it, not yet run:** `0xc0`'s rate against a
*specific neighbour's* rate **within the same set-size bucket**. If `0xc0` runs at
35.7% in the 32-47 bucket while `0xb9` runs at 3% in that same bucket, the
enrichment is size-independent and real. Until that is measured the honest summary
is that the loader hunt has a robust *fact* (the constant is used far more than
adjacent constants) and no *shortlist*.