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}"