From 7e79ec11e01e7ae144116bfdf6e290353dcdec9a Mon Sep 17 00:00:00 2001 From: iris <2+iris@noreply.localhost> Date: Mon, 7 Sep 2026 20:43:23 -0400 Subject: [PATCH] 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 --- docs/IRIS_TODO.md | 2 +- docs/RUST.md | 18 +++++++++++++++--- iris/src/sense.rs | 12 +++++++++--- iris/transcript-fixture/tests/phone_screen.rs | 2 +- 4 files changed, 26 insertions(+), 8 deletions(-) diff --git a/docs/IRIS_TODO.md b/docs/IRIS_TODO.md index 824a2b6..67273b0 100644 --- a/docs/IRIS_TODO.md +++ b/docs/IRIS_TODO.md @@ -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 diff --git a/docs/RUST.md b/docs/RUST.md index 78db7d2..f62831b 100644 --- a/docs/RUST.md +++ b/docs/RUST.md @@ -1028,19 +1028,31 @@ every number the tests assert. On the phone's own recording | sample set | shipped (average) | Compose (Lsq2) | | --- | --- | --- | -| `flick-120hz.touch` | 11750 px/s | **15250 px/s** | +| `flick-120hz.touch` | 12250 px/s | **15250 px/s** | | steady drag, 5px/10ms | 500 px/s | 500 px/s | | accelerating flick, deltas doubling | 1080 px/s | **2445 px/s** | | old fast burst then 1px/10ms | 9182 px/s | 100 px/s | | stopped 48ms, then released | 2533 px/s | 0 px/s | -| press + one move frame | 11750 px/s | 0 px/s | +| press + one move frame | 12500 px/s | 0 px/s | -The recording understates the change (1.30x) because it is only 16ms +The recording understates the change (1.24x) because it is only 16ms long; the accelerating set (2.26x) is the shape of a real finger flick and is what Iris was feeling. The last three rows are the cases an average gets not just low but *wrong*: it flings from a standstill, and it flings from two points that describe no curve. +**Corrected 2026-09-07** (docs/REVIEW-2026-09-07.md's D5): the first and +last rows of the "shipped" column, and the 1.30x, read 11750 px/s -- one +number in two rows for two different sample sets, which is the tell. The +script prints 12250 for the recording (196 px over its own 16 ms) and +12500 for the press-plus-one-move set (100 px over 8 ms). Where 11750 came +from is only half recoverable: it is 196 px over 16.68 ms, i.e. the +recording's travel divided by a **60 Hz** frame rather than by the span +the file itself records, which explains the flick row and does not explain +the other one -- that one was copied. The rule at the top of this section +stands: these numbers come from `velocity_reference.py`, and a +disagreement is fixed by running it, not by running the Rust. + **Tests.** Eight in `sense::velocity_tracker_tests`, two rewritten in `sense::drag_gesture_tests` (three samples is the fewest that can fling; one move frame answers 0, as Compose does), and `phone_screen.rs` now diff --git a/iris/src/sense.rs b/iris/src/sense.rs index 78df9e5..76d6082 100644 --- a/iris/src/sense.rs +++ b/iris/src/sense.rs @@ -1582,8 +1582,14 @@ mod velocity_tracker_tests { /// the release: Compose reads 2445px/s where the average reads 1080, /// so a flick started at 44% of the speed the finger asked for. This /// is the test the old estimator fails and the steady drag above does - /// not -- reverting `velocity` to `total / span` fails exactly this - /// one, the flick recording, and `phone_screen.rs`. + /// not. Reverting `velocity` to `(newest - oldest) / span` fails seven + /// -- this one, the flick recording, the horizon, the stopped finger, + /// the minimum sample count and both `drag_gesture` flick tests, plus + /// `phone_screen.rs`'s flick -- and leaves everything else green. Rerun + /// 2026-09-07 (docs/REVIEW-2026-09-07.md): this comment used to say + /// "exactly this one, the flick recording, and `phone_screen.rs`", + /// which disagreed with docs/RUST.md's count of the same experiment. + /// Seven is what the run prints; RUST.md was right. #[test] fn an_accelerating_flick_reads_its_speed_at_the_release() { const ACCELERATING: [(u64, f32); 6] = [ @@ -2186,7 +2192,7 @@ mod drag_gesture_tests { /// Compose answers 0 here (`minSampleSize = 3`) and so does this, so /// the release is a pan that flings nothing rather than a pan that /// flings at a guessed speed. Before 2026-09-07 the average answered - /// 11750px/s from the same gesture. + /// 12500px/s from the same gesture. #[test] fn a_flick_delivered_as_one_move_frame_carries_no_velocity_to_fit() { let mut ui = UiData::default(); diff --git a/iris/transcript-fixture/tests/phone_screen.rs b/iris/transcript-fixture/tests/phone_screen.rs index 009c3cf..2c354c9 100644 --- a/iris/transcript-fixture/tests/phone_screen.rs +++ b/iris/transcript-fixture/tests/phone_screen.rs @@ -52,7 +52,7 @@ fn a_recorded_flick_releases_with_a_velocity_and_flings_the_list() { // code. Negative because the flick runs *down* the screen and // `Selection::drag` flings the list by `-v` (see its `Released` arm). // The 2026-09-07 before/after: the old average estimator read - // -11750px/s here, which is the fling Iris reported as too slow. + // -12250px/s here, which is the fling Iris reported as too slow. assert!( (velocity + 15_250.0).abs() < 20.0, "expected ~-15250px/s from velocity_reference.py, got {velocity}"