From 06531fb66c7cd1c07e62cc1304e864b28ee3ba00 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Wed, 14 Oct 2026 05:32:34 +0200 Subject: [PATCH] The 394 does not survive: 0xc0's rate rises with immediate-set size 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. --- docs/plan/level-assets.md | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md index 78b0c55..c3da0bb 100644 --- a/docs/plan/level-assets.md +++ b/docs/plan/level-assets.md @@ -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*.