fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: CORRECT F6 unit 2 -- identification wrong, presentation misleading, claim downgraded to amber

Browse Source 
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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
This commit is contained in:
sylph-decoder
2026-09-02 18:27:21 +00:00
parent bc241f5d06
commit 796bc0420c
1 changed files with 45 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
docs/re/f6-unit2-parent-alpha-multiplies.md
View File

@@ -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.