fix: replace hand-rolled quickselect with select_nth_unstable_by

[agene0001]

select_inplace implements the Numerical Recipes quickselect by hand. With NaN in the slice, its partition loop walks past the end of the array — the crash reported in #163 (a segfault under the pre-0.13 unsafe version, an index-out-of-bounds panic today). Reproducer that panics on main:

let mut v: Vec<f64> = (0..1000).map(|i| (i as f64 * 0.7).sin()).collect();
for i in (0..1000).step_by(7) { v[i] = f64::NAN; }
Data::new(v).quantile(0.5); // panicked at src/statistics/slice_statistics.rs:106:28

Replacing it with <[T]>::select_nth_unstable_by(rank, f64::total_cmp) fixes it two ways:

• NaN gets a defined position in a total order, so the search stays in bounds (previous behaviour with NaN was arbitrary).
• Worst case is O(n) (introselect) instead of the NR quickselect's quadratic worst case.

Performance

The first version of this PR claimed ~4.4x. That was measured on large random input only, and it was wrong as a general statement — thanks @day01 for asking for a reproducible benchmark, which is what surfaced it.

Shape matters as much as size. The NR quickselect took its pivot from a median of three, which on sorted or reverse-sorted input lands on the true median and finishes in a single partition, so it beat plain introselect on exactly those shapes. This PR therefore checks for order first, which recovers that and improves on it — the answer becomes an index rather than a partition.

benches/order_statistics.rs gains a selection scaling group sweeping size against shape, written against only the public Data API so it compiles on any branch and --save-baseline works across a checkout. Against main, medians of the Criterion intervals:

shape	1024	65536	1048576
random	+12%	−36%	−76%
sorted	−3%	−0%	+15%
reversed	−37%	−29%	−26%
organ_pipe	−46%	−64%	−71%
duplicates	−19%	−64%	−79%

Twelve of fifteen improve. Sorted input is roughly a wash below a million elements and 15% slower at a million, where the total_cmp scan costs more per element than the median-of-three pivot it replaces. Small random input is 12% slower, where introselect's setup costs more than the old quickselect's.

Keeping the fast paths still beats dropping them: without them, sorted is +75% to +89% and reversed +13% to +30% against main.

Tests

The regression test covers NaN scattered through a large slice, all-NaN input, and NaN at the exact positions the old partition tripped on.

Added on review: every order statistic, the median, and the quantile endpoints checked against a sorted reference over eight shapes and nine sizes, plus permutation invariance. These compare bit patterns, not values, so a wrong sign of zero is a failure — which is how the signed_zeros shape pins @day01's catch that <= considers [-1.0, +0.0, -0.0, 1.0] sorted and returns the wrong zero.

Existing order-statistic/median/quantile tests (including test_median_robust_on_infinities) pass unchanged.

Closes #163

🤖 Generated with Claude Code

[day01]

Could you extend the existing benches/order_statistics.rs benchmark and include a reproducible Criterion between main and this branch? The PR reports a 4.4x improvement, but currently there is no benchmark setup or i cannot find it.

[day01]

additionally, based ontest, is focused on edge case, can you test positive scenario with values?

[day01]

it shouldnt be here, i asked only for results of benches. like in one other of your prs I prepared.

[day01]

<= does not define the same ordering as total_cmp for signed zero. For [-1.0, +0.0, -0.0, 1.0], order_statistic(2) returns +0.0, while the total_cmp reference is -0.0. Please use total_cmp consistently for both fast paths or remove them.

[day01]

same as up

[day01]

claude things :)

[day01]

may we make it more human desc?

[day01]

this desc is needed r u sure?

[day01]

we have rand, i dont know why we have to forget about rand in tests, deps are welcome especially in tests

[day01]

iter_batched excludes data.clone() from the measurement. Are the numbers in the PR description from a different benchmark?

[agene0001]

Good catch on the signed zero — that's a real bug and you gave the exact counterexample. <= reports [-1.0, +0.0, -0.0, 1.0] as sorted because +0.0 <= -0.0 holds, so the fast path indexed straight in and returned +0.0 where the total_cmp reference gives -0.0. My reasoning for <= covered NaN and missed signed zero completely.

Both fast paths now use total_cmp. The value tests gained a signed_zeros shape and now compare bit patterns rather than values, since -0.0 == +0.0 would have hidden it — restoring <= fails with signed_zeros/3: order_statistic(2) = 0, want -0.

On iter_batched: yes, the clone is excluded, and that's intended — the measurement should be selection, not allocation. The numbers came from this benchmark via --baseline main, but the ones in the description were from the <= version, so they were stale. total_cmp costs more per element; current figures (medians of the Criterion intervals), and I've updated the description to match:

shape	1024	65536	1048576
random	+12%	−36%	−76%
sorted	−3%	−0%	+15%
reversed	−37%	−29%	−26%
organ_pipe	−46%	−64%	−71%
duplicates	−19%	−64%	−79%

Twelve of fifteen improve. Sorted input is roughly a wash below a million elements and 15% slower at a million, where the total_cmp scan costs more than the median-of-three pivot it replaces. Keeping the fast paths still beats dropping them, which would put sorted back at +75% to +89% and reversed at +13% to +30% — but if you'd rather have the simpler code, say so and I'll drop them.

Also removed the run instructions from the bench file and trimmed the commentary, and switched the tests to rand.