Closed
Description
Feature gate: #![feature(partition_point)]
This is a tracking issue for [T]::partition_point
.
See also rust-lang/rfcs#2184
Public API
impl<T> [T] {
pub fn partition_point<P>(&self, mut pred: P) -> usize
where
P: FnMut(&T) -> bool;
}
Steps / History
- Implementation: Add partition_point #73577Final commenting period (FCP): Tracking Issue for
partition_point
#73831 (comment)Stabilization PR: Stabilize the partition_point feature #81012Update documentation ofbinary_search
(and/orbinary_search_by
) to point out the existence of this function too.
Unresolved Questions
- Is there a better name?
partition_point
matches C++, but might be hard to recognize as a binary search.
Metadata
Metadata
Assignees
Labels
Area: `[T]`Blocker: Implemented in the nightly compiler and unstable.Category: An issue tracking the progress of sth. like the implementation of an RFCLibs issues that are considered "small" or self-containedLibs issues that are tracked on the team's project board.Relevant to the library API team, which will review and decide on the PR/issue.This issue / PR is in PFCP or FCP with a disposition to merge it.The final comment period is finished for this PR / Issue.
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
timvermeulen commentedon Jul 12, 2020
In order to deduplicate this code with
binary_search_by
's implementation, I think we can simply implementpartition_point
in terms ofbinary_search_by
like so:VillSnow commentedon Jul 13, 2020
@timvermeulen
I prefer my
partition_point
code than currentbinary_search_by
code.I found current
binary_search_by
has a problem that it usually calls one extra comparison.I tried
binary_search_by
logic (=logic1),binary_search_by
logic (=logic2), andpartition_point
logic (=logic3).In addition, I also tried to
partition_point
(logic4).I'm not sure succeeded to remove, or possibly already done from current code.
https://github.com/VillSnow/compare-binary-searches/blob/master/src/main.rs
You can find logic1, 3, 4 need 3 comparisons to find from 0..7, while logic2 needs 4 calls.
I think this causes significant cost more than optimization trick if users can pass their own predictions.
Here is a typical result of bench. Find 0 from 0..65536 and find 0 from 7 but inserted sleep(1ms) in comparison.
Logic2 is much slower than others in case of custom predication.
timvermeulen commentedon Jul 13, 2020
I believe this is intended, it is not optimized for doing the minimum number of comparisons. Make sure to run the benchmarks in https://github.com/rust-lang/rust/blob/master/src/libcore/benches/slice.rs before drawing any conclusions.
And regardless of what the ideal implementation of
binary_search_by
looks like,partition_point
should probably still be implemented in terms of it in the way I outlined above 🙂VillSnow commentedon Jul 14, 2020
@timvermeulen
AFAIK, this bench is written when logic1 is replaced into logic2, not after logic3. The bench tries to find random element from usize slice, not user type which needs large cost to compare.
If it does not optimize for minimum number of comparisons, itself is a problem, I think.
If user need 1ns faster binary search, they can write by themselves or use 3rd party crate, as well as
HashMap
.Is it means
partition_point
should callbinary_search_by
instead ofbinary_search_by
callspartition_point
?I agree because binary_search_by has more information and the cost would be small.
scottmcm commentedon Aug 26, 2020
I noticed in passing that this is using
FnMut
. That seems strange to me, since there's no guarantee which items will be looked at or in which order by this API, so actually mutating in the closure would seem an anti-pattern. Should it maybe useFn
instead? (People could always use interior mutability if they really really really want to update things in the closure, but this would discourage it.)Though I guess
sort_by
takesFnMut
...VillSnow commentedon Aug 27, 2020
@scottmcm memoization or exterior (web/DB) API access using mut handle?
matklad commentedon Jan 10, 2021
@VillSnow this has been baking in the nightly for a while, I think this is ready for stabilization. Would like to send a stabilization PR?
VillSnow commentedon Jan 10, 2021
If the team think all right, I'm glad.
I still concern about code duplication, and I'm watching this PR #74024.
However, how predicate is called is not documented, so even if the algorithm was changed, it never change the stable branch.
I have no objection to merge this.
matklad commentedon Jan 11, 2021
Submitting a stabilization PR is a way to figure that out! I am not on the libs team, but this seems stabilization-worthy to me.
I wouldn't worry about impl details -- they can be adjusted after stabilization.
20 remaining items
m-ou-se commentedon Jan 30, 2021
Sounds like this is the best name we can come up with.
So, let's make sure the documentation of the
binary_search
functions point topartition_point
as an alternative, and maybe add adoc(alias)
for it as well.If anybody feels like updating the documentation here: PRs welcome. ^^
Let's kick off the FCP for stabilizing this:
@rfcbot resolve name
rfcbot commentedon Jan 30, 2021
🔔 This is now entering its final comment period, as per the review above. 🔔
VillSnow commentedon Jan 30, 2021
I don't know much about
doc(alias)
, but does it show this?It looks like to make a flow from other names. For example, some languages has
reduce
, so type 'reduce' at the search box, then hitIterator::fold
.However, Rust already has
binary_search
for who want to find any item by value. It seems a bit different usage to suggest similar methods.rfcbot commentedon Feb 9, 2021
The final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
The RFC will be merged soon.
Rollup merge of rust-lang#81012 - VillSnow:stabilize_partition_point,…
matklad commentedon Feb 15, 2021
Closed by #81012
Thanks @VillSnow for bringing this all the way from an idea to the stabilization!
VillSnow commentedon Feb 16, 2021
Thanks for much assistance.