Add 'partition_at_index/_by/_by_key' for slices.

[Mokosha]

This is an analog to C++'s std::nth_element (a.k.a. quickselect).

Corresponds to tracking bug #55300.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @bluss (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[TimNN]

Ping from triage @bluss / @rust-lang/libs: This PR requires your review.

[SimonSapin]

@Mokosha, can you say more about why this is useful? What’s an example of a situation where you’d use this?

@rust-lang/libs, thoughts on having this feature in the standard library? It’s apparently already available on crates.io rust-lang/rfcs#1470 (comment)

[abonander]

@SimonSapin I have two separate use-cases in my own projects, both involving selecting the median of a dataset.

• In my implementation of the Blockhash.io algorithm in img_hash: https://github.com/abonander/img_hash/blob/master/src/block.rs#L156

• In picking the parent element by median distance in mvp_tree: https://github.com/abonander/mvp-tree-rs/blob/master/src/node.rs#L352

In the former I implemented quickselect myself because I couldn't find any crate implementing quickselect or any other kth-element algorithm when I wrote the code back in 2016. I didn't discover order-stat until much later because it didn't have the keywords I was searching for.

That's a major issue with saying "just use something from crates.io", sometimes people don't know what they're actually looking for or what keywords to search to find it. This is a fundamental enough operation that it should reside in the stdlib, where people are most likely to look first for solutions.

In the latter because the dataset is a small, constant size and I needed to copy it to preserve the original ordering (potentially not necessary, I already see a possible optimization), I decided to just use the stdlib's sort and index the set directly.

In both cases I would prefer a stdlib-provided implementation if it was available. In both cases it would probably be more optimal than the solutions I ended up going with, and importing an external crate just for one function at one use site in each case seemed like overkill (though in img_hash's case I wanted to try implementing it myself anyway).

[alexcrichton]

This seems reasonable to me to add, pending bikeshedding the name/returns/etc

[Mark-Simulacrum]

@Mokosha It looks like there's been a few review comments, can you take a look at those?

[Mokosha]

@Mokosha It looks like there's been a few review comments, can you take a look at those?

Yes. My apologies. I will take a look at these over the weekend.

[Mokosha]

I haven't tested the changes, as I'm running into an issue building rust_llvm. Based on the fact that there isn't a bug filed for it yet, I'm willing to bet it has to do with my setup. Making sure first before feeling confident about this PR, but I felt like I should address the comments here in the meantime.

[Mokosha]

All tests pass. :) Waiting for additional feedback.

[abonander]

@Mokosha they'll want the commits to be squashed before they merge. I don't have review permissions.

[Mokosha]

Is this something I'm in charge of? (Do I create a new PR that squashes the commits?) I thought that was an option when doing the merge...

[abonander]

Merges aren't done directly through Github, I don't think bors will squash.

You can do an interactive rebase against the parent commit of your first one, mark all subsequent commits as "fixup" and then force-push to your branch when the rebase is complete. The change in commits will be immediately reflected on the PR.

[bluss]

This seems good! The name doesn't feel intuitive to me (but not the operation either, so maybe I haven't used it anywhere). Name was discussed in rust-lang/rfcs/issues/1470. I think I understand this operation better as partition_at_nth or similar than as a sort. Any drawback I missed with that name?

[Mokosha]

I don't know which name is the most intuitive, honestly. The reason I didn't choose anything with partition was because it doesn't convey the fact that the list is somewhat sorted around the point that's being partitioned. I would expect partition_at_nth to do the same thing that split_at does. If people prefer a different name, though, I don't have any strong feelings about it (within reason 😉).

[Mark-Simulacrum]

Perhaps sort_until? If I understand this correctly, it sorts the first N elements -- so either sort_until or perhaps sort_first would make sense?

[Mokosha]

@Mark-Simulacrum It doesn't quite sort the first N elements. Rather, it chooses an index i of the slice, and makes sure that:

• The element at index i is the same as if the slice was sorted.
• All elements at positions [0, i) are "less than" the element at index i, in no particular order.
• All elements at positions [i + 1, n) are "greater than" the element at index i, in no particular order.

[Mark-Simulacrum]

Ah, okay. Then I think the partition naming is probably the best that I can think of -- and seems to jive okay with the other partition method on slices (https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.partition_dedup).

If we do rename to the partition naming though I think changing the return type to (&mut [T], &mut T, &mut [T]) might be a good idea to provide immediate access to those three "parts" of the array. If the user doesn't want that, they can just not use the return type -- it should be essentially free to give it to them. It could also provide a good way of explaining the API.

[Mokosha]

OK -- good point about consistency. How about partition_at_index ?

[RalfJung]

Looks like there's another config that doesn't support entropy (miri)-- are there suggestions for how to have a more robust test, or should I add the same cfg to the test here, too?

Would there be anything lost by using a fixed seed instead? IMO non-deterministic tests are an antipattern anyway.

If you use something like rand::rngs::StdRng::seed_from_u64(0xdeadcafe) or rand::StdRng::from_seed(&[0xdeadcafe]), then it'll work fine in Miri.

[Mokosha]

@RalfJung Probably not, but I'm matching the code already written in the test for sort_unstable above it. Seems like they should both be changed?

[RalfJung]

IMO they should, but that's up to @rust-lang/libs

[Centril]

Ping from triage, @scottmcm

[scottmcm]

@bors r=bluss

[bors]

📌 Commit 3f306db has been approved by bluss

[bors]

⌛ Testing commit 3f306db with merge 8be24b37d498dbf7b85aef82b1007522a4b73cbc...

[bors]

💥 Test timed out

[kennytm]

@bors retry

Double scheduling in two Travis builds.

[Mokosha]

Thank you to everyone who helped review this change and get it merged!