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

The class-ID retraction goes further: the claim was wrong before the fix

Browse Source 
Pinned down the one slot that still cleared 100x after the record-boundary fix,
and it is the artifact this section was written to guard against.

The discriminator the original version lacked: a slot that really carries moby
class IDs must SPAN the ID space, so some of its values land above a level's moby
count. The artifact does the opposite.

    type         slot   enrichment   distinct   values ABOVE the moby count
    0xd76cc453      6       305x           9        0
    0xf2ef4275     34        64x           9      341
    0xf2ef4275      7        46x          16      412
    0xf2ef4275     14        34x          16      432
    0xd76cc453      9        32x          28      702

The 305x slot's nine values are 1, 3, 4, 5, 10, 11, 12, 13, 15 -- all under a
level's ~215 moby classes, so every one scores as a hit and 65536/215 = 305x.
Nine small numbers is not a class-ID array. Every slot that actually spans the ID
space scores 10x to 64x, which is chance.

So the original claim's own numbers gave it away and it was not read that way:
"5 to 42 distinct values at 153x to 289x" is exactly the artifact's shape -- a
handful of small values, none above the count. The record-boundary fix was never
what made this claim wrong. It was wrong when written, and the retraction is
complete rather than the partial one I committed two turns ago.

The test now separates the two quantities: slots clearing 100x (currently 1,
expected to remain the artifact) and slots clearing 100x WHILE ALSO having values
above the moby count (currently 0, must stay empty). That second number is the
one that means something, and a slot appearing in it would be the first genuine
evidence of a class-ID array anywhere in the container.

Worth noting the per-SLOT bookkeeping: the count of values above the moby count
is keyed by (type, slot), not by type. A first attempt keyed it by type and the
artifact type passed the check on the strength of its ordinary slots -- 783 of its
own values sat above the count at other slots. The check has to be about the
individual slot, or one good slot launders a bad one.

245 tests, clippy clean.
This commit is contained in:
ReaperOfVeriod
2026-10-13 08:11:35 +02:00
parent d159195510
commit 2d3880b624
2 changed files with 74 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/formats/core-data-regions.md
+32 -5
View File
@@ -986,13 +986,40 @@ With record boundaries measured against each record's successor, and ragged
chunks skipped, what survives is:
chunk types with a varying class-ID-like slot 2 (was >= 20)
of those, clearing 100x enrichment 1 (was >= 20)
of those, ALSO spanning the ID space 0
So the general claim -- one class-ID slot per chunk type, across the container --
does not hold and is withdrawn. One chunk type still shows a slot that varies in
the manner of a class ID at 100x enrichment over chance. That is asserted, and
the test also asserts the count has *not* returned to 20, so the retraction
cannot quietly lapse back into the claim.
does not hold and is withdrawn.
### And the flaw was there from the start
The discriminator the original version lacked is simple: **a slot that really
carries moby class IDs must span the ID space**, so some of its values land above
a level's moby count. The artifact does the opposite.
type slot enrichment distinct values ABOVE the moby count
0xd76cc453 6 305x 9 0
0xf2ef4275 34 64x 9 341
0xf2ef4275 7 46x 16 412
0xf2ef4275 14 34x 16 432
0xd76cc453 9 32x 28 702
The 305x slot's nine values are `1, 3, 4, 5, 10, 11, 12, 13, 15` -- all under a
level's ~215 moby classes, so every one scores as a hit and 65536/215 = 305x.
Every slot that actually spans the ID space scores 10x to 64x, which is chance.
So the original claim's own numbers gave it away and it was not read that way:
**"5 to 42 distinct values at 153x to 289x"** is exactly the artifact's shape --
a handful of small values, none above the count. The record-boundary fix was
never what made this claim wrong. It was wrong when written, and the retraction
is complete rather than partial.
The test now separates the two: it counts slots clearing 100x (currently 1) and
slots that clear 100x *while also* having values above the moby count (currently
0). The second must stay empty; the first is expected to be the artifact. The
count above the moby count is tracked per **slot**, not per type, because a type
with one artifact slot and several ordinary slots must not have the ordinary
ones vouch for it.
The `distinct >= 4` filter this section introduced is still load-bearing and is
unaffected: without it the top slots are constants that read as 305x, because any