re: count the in-range fallbacks -- and the control that failed is the answer
sylpheed-port pointed out that classifying defaults "by inspection" is exactly
the method that cannot see an in-range fallback, and that correction applies to
my own sweep from an hour ago: I waved 64 sites through by reading them.
Counted instead, disc-wide over 965 builds and 24 811 keyframes:
ui_layout.rs:1681 untimed poses (would fabricate t=0): 0
ui_layout.rs:1010 pose_at queries 168 264, None (reads a=0): 0
Two zeroes, which is the result this corpus now distrusts most, so the detector
was made to prove it can see a hit: ask pose_at for a time no build declares.
The control FAILED -- 10 906 out-of-range queries, 0 None -- so the detector was
blind and the :1010 zero measured nothing.
The failure is the finding. pose_at is TOTAL: reading the source, its only None
path is an `if ks.is_empty() { return None }` guard, and disc-wide there are 0
elements with zero keyframes out of 5 453. So :1010's unwrap_or(0) is unreachable
BY CONSTRUCTION, which is stronger than "0 in this corpus" -- and it was
established by the control failing rather than by the count passing. Without the
control this corpus would have recorded a true conclusion resting on a
meaningless number.
:1681 stands differently: 0 of 24 811, and time really is Option<u32> with the
stale reader demonstrably producing None (its screen info prints a trailing -),
so the state is representable and a detector would see it. :973 is not a hazard
-- guarded two lines later by `if tmax == 0 { return false; }`, where reading is
sufficient because the guard is the proof.
METHOD gains both: a zero is worth nothing until the detector is shown able to
report non-zero; and the habit under several of this week's errors, which is
reading a PROXY for the thing when the thing itself is one command away -- a line
count for an era, a type name's spelling for its default, an ordinal for an
entry, a fallback's text for its firing rate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
@@ -309,6 +309,28 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
|
||||
a literal that could pass for a measurement is the hazard. Build the sweep so it
|
||||
finds a **known** case as its positive control.
|
||||
|
||||
* **A zero from a detector is worth nothing until the detector is shown able to
|
||||
report non-zero — and when that control fails, the failure is often the
|
||||
answer.** Counting `ui_layout`'s two in-range fallbacks gave 0 and 0. The
|
||||
negative control — ask `pose_at` for a time no build declares — returned **0
|
||||
None across 10 906 queries**, so the detector was blind and one of those zeroes
|
||||
measured nothing. That failure produced the real result: `pose_at` is **total**,
|
||||
its only `None` path is an `is_empty()` guard, and disc-wide **0 of 5 453**
|
||||
elements have zero keyframes — so the fallback is unreachable *by construction*,
|
||||
which is a stronger statement than "it never fired here". ⚠️ Had the control not
|
||||
run, this corpus would have recorded a true conclusion supported by a
|
||||
meaningless number, which is the same defect as
|
||||
[agreeing by luck](#) and just as invisible.
|
||||
|
||||
* 📌 **The habit under several of these: reading a PROXY for the thing when the
|
||||
thing itself is one command away.** Inferring a decoder era from a **line
|
||||
count**; classifying a fallback as harmless by the **spelling** of its type
|
||||
name; calling a default a sentinel by **reading** it rather than counting how
|
||||
often it fires; taking a build's identity from an **ordinal** rather than the
|
||||
entry column. Each time the direct check existed and cost seconds. The tell is
|
||||
noticing that what you are about to look at merely *correlates* with what you
|
||||
want to know.
|
||||
|
||||
## Runtime / emulator
|
||||
|
||||
* **Look at the PNG** — and check its dimensions.
|
||||
|
||||
Reference in New Issue
Block a user