From 7b952feca9eafb758db2ee458c3a1f9195f9b671 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Wed, 2 Sep 2026 18:27:21 +0000 Subject: [PATCH] re: CORRECT F6 unit 2 -- identification wrong, presentation misleading, claim downgraded to amber The port challenged the by-size identification: both sweep sprites are the same size, so size cannot separate pteff03 from pteff03a, and the two leaves floor at 128 and 0. They were right, and it is broken a third way. Their discriminator -- the leaves travel in opposite directions -- is in the capture I already had. Both rows drift +2.19 and +2.18 in x, i.e. BOTH LEFT TO RIGHT, so both are pteff03. The 0.7% size difference is per-frame rounding splitting one element across two keys, not two elements. pteff03a does not appear in this capture at all. And my own presentation misled. The "alphas 8 24 33 50 58" I quoted were sorted(set(...))[:9] -- the nine LOWEST DISTINCT values, not the series. Read as a trajectory they look like a ramp from 8. They are a tail. The counts: 9 of 1140 and 5 of 614 samples below 128, so 14 sub-floor samples out of 1754. The bound argument survives in shape and collapses in weight. A sample below 128 is still unexplainable by a leaf flooring at 128, but 14 of 1754 is a thin tail and a tail is where a vertex-grouping slip or a partial frame would show up. Downgraded to amber: not refuted, not established. Settling it needs the same capture read as a SERIES rather than a set -- alpha against frame across t=70..100, where a multiplying parent must produce a monotone ramp on nearly every frame rather than 14 stragglers. One more read of data already on disk. The port was right to hold the renderer. Adopting this would have changed a rendering rule on every screen with a leaf, on 14 samples I had presented as a trajectory. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t --- docs/re/f6-unit2-parent-alpha-multiplies.md | 46 ++++++++++++++++++++- 1 file changed, 45 insertions(+), 1 deletion(-) diff --git a/docs/re/f6-unit2-parent-alpha-multiplies.md b/docs/re/f6-unit2-parent-alpha-multiplies.md index b139fc02..9dbcf2e8 100644 --- a/docs/re/f6-unit2-parent-alpha-multiplies.md +++ b/docs/re/f6-unit2-parent-alpha-multiplies.md @@ -1,4 +1,48 @@ -# F6 unit 2 β€” the parent's alpha **IS** multiplied into the sweep leaf +# F6 unit 2 β€” parent alpha multiplying in: 🟑 WEAKENED, not established + +> ## πŸ”΄ CORRECTION, same day β€” the identification was wrong, and so was my presentation +> +> The port challenged the by-size identification: both sweep sprites are the same +> size, so size cannot separate `pteff03` from `pteff03a`, and the two leaves have +> different alpha floors (128 and 0). **They were right that it was broken, and it +> is broken in a third way neither of us named.** +> +> Their proposed discriminator β€” the leaves travel in opposite directions β€” is in +> the capture, and it says: +> +> ``` +> 1.38x3.15 n=1140 x centre -1.690 -> +0.500 drift +2.190 LEFT->RIGHT +> 1.39x3.15 n= 614 x centre -1.685 -> +0.495 drift +2.180 LEFT->RIGHT +> ``` +> +> **Both rows travel the same way, so both are `pteff03`.** The 0.7 % size +> difference is per-frame rounding splitting ONE element across two keys β€” not two +> elements. `pteff03a` (declared right-to-left, 800 % scale, AABB β‰ˆ 3.62 NDC) does +> **not appear in this capture at all.** +> +> πŸ”΄ **And my own presentation misled.** The "alphas 8 24 33 50 58 …" I quoted were +> `sorted(set(...))[:9]` β€” the nine **lowest distinct** values, not the series. Read +> as a trajectory they look like a ramp from 8. They are a tail. The actual counts: +> +> ``` +> below 128: 9 of 1140 and 5 of 614 = 14 sub-floor samples out of 1754 +> ``` +> +> **So the bound argument survives in shape and collapses in weight.** Every sample +> below 128 is still unexplainable by a leaf that floors at 128 β€” but 14 of 1754 is +> a thin tail, and a tail is exactly where a vertex-grouping slip or a partial frame +> would show up. **Downgraded to 🟑: not refuted, not established.** +> +> **What would settle it:** the same capture read as a *series* rather than a set β€” +> alpha against frame across `t=70…100`, where a multiplying parent must produce a +> monotone ramp on nearly every frame, not 14 stragglers. That is one more read of +> data already on disk, and it is the next unit. +> +> The port was right to hold the renderer. Adopting this would have changed a +> rendering rule on every screen with a leaf, on 14 samples I had presented as a +> trajectory. + + **Status: βœ… measured ⟨capture⟩.** 2026-09-02.