lorenzoracca / swift-binary-search

Binary search imply that will presented as proposal to swift-evolution

Swift/SR-368

This repo contains the work for bug Swift/SR-368. Initially based on copying C++'s binary search functions, this project now aims to implement binary search algorithms in Swift in a simpler and more powerful way, including predicates and sorting methods.

Contents

• SE-0000: New proposal created after feedback from the Swift commmunity.

TODO

Current work involves:

• Reviewing the proposal following the guidelines of the Swift team
• Sending the new proposal to swift-evolution
• Officially presenting the proposal

swift-binary-search's Issues

Add implementations

Do we want to add implementations and tests to this repo as well? I'll create another PR with an initial implementation and corresponding tests to get things started unless there is any opposition.

Opened proposal on Swift-evolution as 0066-binary-search

Good news guys,
I just opened a pull request to swift-evolution and presented the proposal.
You can find the pull here!

Hope it will get accepted. Stay tuned on the email discussion and the pull in case we get any news!

Thank you all for your support.

Binary vs unary predicates

With respect to Dave, I think focusing on unary predicates over binary ones is a mistake for a few different reasons:

1. The standard library uses a consistent binary predicate for ordering collections. You can use the exact same binary predicate when calling sort, partition, minElement, and maxElement. Requiring a different predicate would make it harder to use these new APIs and inconsistent with what's there.

2. Using a binary predicate makes the Comparable and predicate versions parallel. Like the existing methods described above, using a binary predicate would make these versions the same, allowing easy reversal of the direction of the sort and interoperation between methods.

   var a = [5, 3, 2, 6, 4, 1]
   // This is equivalent to 'a.sort(isOrderedBefore: <)':
   a.sort()                               // [1, 2, 3, 4, 5, 6]
   a.binarySearch(2)                      // Optional(1)
   
   a.sort(isOrderedBefore: >)             // [6, 5, 4, 3, 2, 1]
   a.binarySearch(2, isOrderedBefore: >)  // Optional(4)

3. Using a unary predicate requires flipping the semantics for upperBound. This is a problem, since equalRange can be implemented in terms of lowerBound and upperBound if the two methods use the same predicate, but not if one uses isOrderedBefore and one uses isOrderedAfter. The same problem is seen in the implementation of binarySearch: without a binary predicate, there's no way to test the equivalence of the lower bound.

What do you think? In my view the most appropriate method signatures would be:

// where Generator.Element: Comparable
func lowerBound(value: Generator.Element) -> Index
func upperBound(value: Generator.Element) -> Index
func equalRange(value: Generator.Element) -> Range<Index>
func binarySearch(value: Generator.Element) -> Index?

// general case
func lowerBound(
    value: Generator.Element,
    isOrderedBefore isOrderedBefore: (Generator.Element, Generator.Element) -> Bool
    ) -> Index
func upperBound(
    value: Generator.Element,
    isOrderedBefore isOrderedBefore: (Generator.Element, Generator.Element) -> Bool
    ) -> Index
func equalRange(
    value: Generator.Element,
    isOrderedBefore isOrderedBefore: (Generator.Element, Generator.Element) -> Bool
    ) -> Range<Index>
func binarySearch(
    value: Generator.Element,
    isOrderedBefore isOrderedBefore: (Generator.Element, Generator.Element) -> Bool
    ) -> Index?