Remove verge_sorter

Author: Morwenn

docs/Original-research.md

@@ -14,7 +14,7 @@ Now, those observations/claims are there to be challenged: if you know a stable
 
 ### Vergesort
 
-The vergesort is a new sorting algorithm which combines merge operations on almost sorted data, and falls back to another sorting algorithm when the data is not sorted enough. Somehow it can be considered as a cheap preprocessing step to take advantage of almost-sorted data when possible. Just like TimSort, it achieves linear time on some patterns, generally for almost sorted data, and should never be worse than O(n log n log log n) in the worst case - though no in-depth formal analysis has been performed.
+Vergesort is a sorting algorithm which combines merge operations on almost sorted data, and falls back to another sorting algorithm when the data is not sorted enough. Somehow it can be considered as a cheap preprocessing step to take advantage of almost-sorted data when possible. Just like TimSort, it achieves linear time on some patterns, generally for almost sorted data, and should never be worse than O(n log n log log n) in the worst case - though no in-depth formal analysis has been performed.
 
     Best        Average     Worst                 Memory      Stable
     n           n log n     n log n log log n     n           No
@@ -24,7 +24,7 @@ The two variations in space and time complexity depend on whether enough memory
 
 While vergesort has been designed to work with random-access iterators, there also exists a version that works with bidirectional iterators. The algorithm is slightly different and a bit slower because it can't as easily jump through the collection. The complexity of that bidirectional iterators algorithm can get down to the same time as the random-access one when `quick_merge_sort` is used as the fallback algorithm.
 
-The actual complexity of the algorithm is O(n log n log log n), but interestingly it is only reached in one of its paths that is among the fastest in practice. It is also possible to make vergesort stable but tweaking its reverse runs detection algorithm and making it fallback to a stable sorting algorithm.
+The actual complexity of the algorithm is O(n log n log log n), but interestingly it is only reached in one of its paths that is among the fastest in practice. It is also possible to make vergesort stable by tweaking its reverse runs detection algorithm and making it fallback to a stable sorting algorithm.
 
 This sorting algorithm also exists as a [standalone repository][vergesort].
 

docs/Sorter-adapters.md

@@ -283,7 +283,6 @@ struct stable_adapter;
 `stable_adapter` is the main customization point of those stable sorting facilities, and as such can be specialized to provide stable versions of your own unstable sorters or adapters. **cpp-sort** itself provides `stable_adapter` specializations for the following components:
 
 * [`std_sorter`][std-sorter] (calls [`std::stable_sort`][std-stable-sort] instead of [`std::sort`][std-sort])
-* [`verge_sorter`][verge-sorter]
 * [`hybrid_adapter`][hybrid-adapter]
 * [`self_sort_adapter`][self-sort-adapter]
 * `stable_adapter` itself (automatic unnesting)
@@ -318,13 +317,19 @@ This little dance sometimes allows to reduce the nesting of function calls and t
 #include <cpp-sort/adapters/verge_adapter.h>
 ```
 
-The complexity analysis is a bit too complicated to be included in this documentation. Additionally, the space and time complexity changes depending on whether the merging algorithm has enough space to run in O(n) time or whether it needs to fall back to an O(n log n) algorithm. Assuming that the *adapted sorter* works in O(n log n) time and O(1) space, the complexity of the *resulting sorter* is as follows:
+Vergesort is a [*Mono*-adaptive][probe-mono] algorithm as long as the size of those runs is greater than *n / log n*; when the runs are smaller, it falls back to the *adapted sorted* to sort them.
+
+The space and time complexities of this adapter change depending on whether the merging algorithm has enough space to run in O(n) time or whether it needs to fall back to an O(n log n) algorithm for merging. Assuming that the *adapted sorter* works in O(n log n) time and O(1) space, the complexity of the *resulting sorter* is as follows:
 
 | Best        | Average     | Worst             | Memory      | Stable      | Iterators     |
 | ----------- | ----------- | ----------------- | ----------- | ----------- | ------------- |
 | n           | n log n     | n log n log log n | n           | No          | Bidirectional |
 | n           | n log n     | n log n           | log n       | No          | Bidirectional |
 
+We can understand that complexity as being bound by either the vergesort optimization layer or, by the *adapted sorter*'s complexity:
+* When vergesort doesn't find big enough runs, the complexity is bound by that of the *adapted sorter*.
+* When it does find big enough runs, the complexity is bound by the merging phase of the optimization layer. In such a case, `inplace_merge` is used to merge the runs: it uses additional memory if any is available, in which case vergesort is O(n log n). If there isn't much extra memory available, it may still require O(log n) extra memory (and thus raise an `std::bad_alloc` if there isn't that much memory available) in which case the complexity falls to O(n log n log log n).
+
 The *resulting sorter* is always unstable, no matter the stability of the *adapted sorter*. It accepts bidirectional ranges.
 
 ```cpp
@@ -367,5 +372,4 @@ When wrapped into [`stable_adapter`][stable-adapter], it has a slightly differen
   [std-stable-sort]: https://en.cppreference.com/w/cpp/algorithm/stable_sort
   [std-true-type]: https://en.cppreference.com/w/cpp/types/integral_constant
   [verge-adapter]: Sorter-adapters.md#verge_adapter
-  [verge-sorter]: Sorters.md#verge_sorter
   [vergesort-fallbacks]: https://github.com/Morwenn/vergesort/blob/trunk/fallbacks.md

docs/Sorters.md

@@ -380,33 +380,6 @@ While the sorting algorithm is stable and the complexity guarantees are good eno
 
 *Changed in version 1.5.0:* `tim_sorter` now handles comparison and projection objects that aren't default-constructible.
 
-### `verge_sorter`
-
-```cpp
-#include <cpp-sort/sorters/verge_sorter.h>
-```
-
-Implements a [vergesort][vergesort] algorithm backed by a quicksort derivative.
-
-| Best        | Average     | Worst             | Memory      | Stable      | Iterators     |
-| ----------- | ----------- | ----------------- | ----------- | ----------- | ------------- |
-| n           | n log n     | n log n log log n | n           | No          | Random-access |
-| n           | n log n     | n log n           | log n       | No          | Random-access |
-| n           | n log n     | n log n log log n | n           | No          | Bidirectional |
-| n           | n log n     | n log n           | log² n      | No          | Bidirectional |
-
-Vergesort is a [*Runs*-adaptive][probe-runs] algorithm (including descending runs) as long as the size of those runs is greater than *n / log n*; when the runs are smaller, it falls back to another sorting algorithm to sort them (pdqsort for random-access iterators, QuickMergesort otherwise).
-
-Vergesort's complexity is bound either by its optimization layer or by the fallback sorter's complexity:
-* When it doesn't find big runs, the complexity is bound by the fallback sorter: depending on the category of iterators you can refer to the tables of either `pdq_sorter` or `quick_merge_sorter`.
-* When it does find big runs, vergesort's complexity is bound by the merging phase of its optimization layer. In such a case, `inplace_merge` is used to merge the runs: it will use additional memory if any is available, in which case vergesort is O(n log n). If there isn't much extra memory available, it may still require O(log n) extra memory (and thus raise an `std::bad_alloc` if there isn't that much memory available) in which case the complexity falls to O(n log n log log n). It should not happen that much, and the additional *log log n* factor is likely irrelevant for most real-world applications.
-
-When wrapped into [`stable_adapter`][stable-adapter], it has a slightly different behaviour: it detects strictly descending runs instead of non-ascending ones, and wraps the fallback sorter with `stable_t`. This make the specialization stable, and faster than just using `make_stable`.
-
-*Changed in version 1.6.0:* when sorting a collection made of bidirectional iterators, `verge_sorter` falls back to `quick_merge_sorter` instead of `quick_sorter`.
-
-*New in version 1.9.0:* explicit specialization for `stable_adapter<verge_sorter>`.
-
 ### `wiki_sorter<>`
 
 ```cpp
@@ -537,7 +510,6 @@ struct spread_sorter:
   [merge-sort]: https://en.wikipedia.org/wiki/Merge_sort
   [pdq-sorter]: Sorters.md#pdq_sorter
   [pdqsort]: https://github.com/orlp/pdqsort
-  [probe-runs]: Measures-of-presortedness.md#runs
   [quick-mergesort]: https://arxiv.org/abs/1307.3033
   [quicksort]: https://en.wikipedia.org/wiki/Quicksort
   [schwartz-adapter]: Sorter-adapters.md#schwartz_adapter
@@ -556,7 +528,6 @@ struct spread_sorter:
   [std-stable-sort]: https://en.cppreference.com/w/cpp/algorithm/stable_sort
   [std-vector-bool]: https://en.cppreference.com/w/cpp/container/vector_bool
   [timsort]: https://en.wikipedia.org/wiki/Timsort
-  [vergesort]: https://github.com/Morwenn/vergesort
   [wiki-sort]: https://github.com/BonzaiThePenguin/WikiSort
   [wiki-sorter]: Sorters.md#wiki_sorter
   [writing-a-sorter]: Writing-a-sorter.md

include/cpp-sort/fwd.h

@@ -50,7 +50,6 @@ namespace cppsort
     struct std_sorter;
     struct string_spread_sorter;
     struct tim_sorter;
-    struct verge_sorter;
     template<typename BufferProvider>
     struct wiki_sorter;
 

include/cpp-sort/sorters.h

@@ -31,7 +31,6 @@
 #include <cpp-sort/sorters/spread_sorter.h>
 #include <cpp-sort/sorters/std_sorter.h>
 #include <cpp-sort/sorters/tim_sorter.h>
-#include <cpp-sort/sorters/verge_sorter.h>
 #include <cpp-sort/sorters/wiki_sorter.h>
 
 #endif // CPPSORT_SORTERS_H_

include/cpp-sort/sorters/verge_sorter.h

@@ -132,14 +132,4 @@ TEST_CASE( "test most adapters with a pointer to member function comparison",
         sorter{}(collection, &internal_compare<int>::compare_to);
         CHECK( std::is_sorted(collection.begin(), collection.end()) );
     }
-
-    SECTION( "verge_adapter" )
-    {
-        using sorter = cppsort::verge_adapter<
-            cppsort::poplar_sorter
-        >;
-
-        sorter{}(collection, &internal_compare<int>::compare_to);
-        CHECK( std::is_sorted(collection.begin(), collection.end()) );
-    }
 }

tests/adapters/every_adapter_internal_compare.cpp

@@ -139,14 +139,4 @@ TEST_CASE( "test adapters extended compatibility with LWG 3031", "[adapters]" )
         sorter{}(vec, non_const_compare);
         CHECK( std::is_sorted(vec.begin(), vec.end()) );
     }
-
-    SECTION( "verge_adapter" )
-    {
-        using sorter = cppsort::verge_adapter<
-            cppsort::poplar_sorter
-        >;
-
-        sorter{}(vec, non_const_compare);
-        CHECK( std::is_sorted(vec.begin(), vec.end()) );
-    }
 }

tests/adapters/every_adapter_non_const_compare.cpp

@@ -41,7 +41,7 @@ TEMPLATE_TEST_CASE( "every random-access sorter with indirect adapter", "[indire
                     cppsort::std_sorter,
                     cppsort::stable_adapter<cppsort::std_sorter>,
                     cppsort::tim_sorter,
-                    cppsort::verge_sorter,
+                    old_verge_sorter,
                     cppsort::wiki_sorter<> )
 {
     std::vector<double> collection; collection.reserve(412);
@@ -65,7 +65,7 @@ TEMPLATE_TEST_CASE( "every bidirectional sorter with indirect_adapter", "[indire
                     cppsort::selection_sorter,
                     cppsort::slab_sorter,
                     cppsort::splay_sorter,
-                    cppsort::verge_sorter )
+                    old_verge_sorter )
 {
     std::list<double> collection;
     auto distribution = dist::shuffled{};

tests/adapters/indirect_adapter_every_sorter.cpp

@@ -47,7 +47,7 @@ TEMPLATE_TEST_CASE( "every random-access sorter with Schwartzian transform adapt
                     cppsort::splay_sorter,
                     old_split_sorter,
                     cppsort::tim_sorter,
-                    cppsort::verge_sorter,
+                    old_verge_sorter,
                     cppsort::wiki_sorter<cppsort::utility::fixed_buffer<0>> )
 {
     std::vector<wrapper<>> collection;
@@ -71,7 +71,7 @@ TEMPLATE_TEST_CASE( "every bidirectional sorter with Schwartzian transform adapt
                     cppsort::selection_sorter,
                     cppsort::slab_sorter,
                     cppsort::splay_sorter,
-                    cppsort::verge_sorter )
+                    old_verge_sorter )
 {
     std::list<wrapper<>> collection;
     auto distribution = dist::shuffled{};