Correct the sky control and the image extent
The 256-byte period in the sky region stands, but the evidence I gave for it was badly chosen and one figure in it was wrong. The control was uniform random bytes, which read flat at 0.0000 and made the 0.772 match rate look like an enormous signal. It is not: 91.8% of the region's bytes are the same value, 0x07, so a stride-256 comparison matches trivially wherever both positions are 0x07. The correct control is the same bytes shuffled, which keeps the value distribution and destroys only the ordering. It reads 0.512 at stride 256, not 0.0000. The real excess is +0.26 -- a genuine signal, and much smaller than reported. The extent was wrong for the same reason. Measured against the matched control, the excess over the value distribution is: +0 .. +49152 +0.38 .. +0.45 +53248 +0.26 +57344 +0.07 +61440 -0.13 so the periodic data ends between +53248 and +57344, rows 205 to 224, not at +60160. The earlier number came from a raw threshold with no distribution control, and a byte value covering 91.8% of the data drags such a threshold to wherever the dominant run happens to stop. So: the period is real and cross-checked, the image dimensions are not. Any "256x236" from the previous commit should be discarded. The general lesson is the one AGENTS.md asks for and this missed -- a control has to match the thing being controlled for. Uniform random was the wrong reference for data with a dominant byte value, and it made a weak result look like a strong one.
This commit is contained in:
@@ -254,16 +254,40 @@ control of the same size reads flat at 0.0000 for every stride tested.
|
||||
|
||||
**Result:**
|
||||
|
||||
- Peak stride in the first 64 KB is **256** at a 0.772 match rate, against a
|
||||
flat random control. Strides 255, 257 and 4 score nearly as high, which is
|
||||
what a true period looks like smeared by sampling.
|
||||
- Peak stride in the first 64 KB is **256** at a 0.772 match rate. Strides 255,
|
||||
257 and 4 score nearly as high, which is what a true period looks like
|
||||
smeared by sampling.
|
||||
- Across levels the peak is 256 on 21, 512 on 5 and 128 on 1. 512 and 128 are
|
||||
a harmonic and a sub-multiple, so the fundamental period is **256 bytes**.
|
||||
- The periodicity holds from `+0` to about `+60160` and then stops: **236 rows
|
||||
of 256 bytes**, i.e. a 256-wide, 236-tall image at one byte per pixel.
|
||||
- The remaining ~362,240 bytes of the sky region are *not* 256-periodic and
|
||||
remain unidentified. That is 86% of the region, and it is where the offset
|
||||
table seen at `+0x20` earlier points.
|
||||
|
||||
**Correction to the control.** The original comparison used uniform random
|
||||
bytes, which read flat at 0.0000 -- and made the 0.772 look like an enormous
|
||||
signal. It is not: 91.8% of the region's bytes are the same value (`0x07`), so
|
||||
a stride-256 comparison matches trivially wherever both positions are `0x07`.
|
||||
|
||||
The right control is the same bytes shuffled, which preserves the value
|
||||
distribution and destroys only the ordering. That control reads **0.512** at
|
||||
stride 256, not 0.0000. The true excess is 0.772 − 0.512 = **+0.26**, a real
|
||||
signal and a far smaller one than the original framing suggested.
|
||||
|
||||
**And the extent is wrong too.** Re-measured against the matched control, the
|
||||
excess over the value distribution is:
|
||||
|
||||
| offset | excess |
|
||||
|---|---|
|
||||
| +0 .. +49152 | +0.38 .. +0.45 |
|
||||
| +53248 | +0.26 |
|
||||
| +57344 | +0.07 |
|
||||
| +61440 | −0.13 |
|
||||
|
||||
So the 256-periodic data ends between `+53248` and `+57344` — somewhere in
|
||||
rows 205 to 224 — **not** at `+60160` as first reported. The original figure
|
||||
came from a raw threshold with no distribution control, and 91.8% of one byte
|
||||
value drags that threshold wherever the dominant run ends.
|
||||
|
||||
The 256-byte period itself stands, cross-checked on 21 of 27 levels with the
|
||||
remaining levels showing its harmonic and sub-multiple. The image dimensions
|
||||
do not: an earlier "256x236" is wrong and should not be used.
|
||||
|
||||
So the sky region is not one thing. Its first ~60 KB is an image; the rest is
|
||||
whatever the layer offsets address. Both halves still need work, and the
|
||||
|
||||
Reference in New Issue
Block a user