docs: the fling's "before" velocity is what velocity_reference.py prints, 12250 and 12500

docs/REVIEW-2026-09-07.md's D5. Four places quoted 11750 px/s as the old
average estimator's answer -- for `flick-120hz.touch` *and* for the
press-plus-one-move-frame set, which are different sample sets, and one
number in both rows is the tell. `iris/benches/velocity_reference.py`,
which the same section says every number below it comes from, prints
12250 for the recording and 12500 for the two-sample set, and
`sense.rs:1406` already had the 12250.

Half of where 11750 came from is recoverable and is written down beside
the table: it is the recording's 196 px over 16.68 ms, a 60 Hz frame
rather than the 16 ms span the file itself records. That explains the
flick row; the other row was copied from it. The 1.30x ratio derived from
it becomes 1.24x.

Also settles the second disagreement about the same experiment (the
review's rule finding on the negative control): `sense.rs`'s doc comment
claimed reverting `velocity` to total-over-span fails "exactly this one,
the flick recording, and phone_screen.rs" while RUST.md said seven. Run
again today with the revert in place: seven in `-p iris` (the flick
recording, the accelerating flick, the horizon, the stopped finger, the
minimum sample count, both `drag_gesture` flick tests) plus
`phone_screen.rs`'s flick, everything else green. RUST.md was right and
the comment now says the same thing.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
irisandClaude Fable 5.1 committed 2026-09-07 20:43:23 -04:00
1 parent 2ec0fee84c
commit 7e79ec11e0
4 files changed
+26 -8

No files matched your search

+1 -1
View File
@@ -1023,7 +1023,7 @@ do not duplicate it there.
immediately after releasing the flick (the slow down seems
correct)."** Done; RUST.md's "The fling started too slow" has the
derivation and the table. On `flick-120hz.touch` the release velocity
goes from **11750px/s to 15250px/s**, and on an accelerating flick --
goes from **12250px/s to 15250px/s**, and on an accelerating flick --
the shape a real finger makes, and what the recording is too short to
show -- from 1080 to 2445px/s. The curve was right; `VelocityTracker`
was averaging total motion over the sample span, which cannot tell an