[libcxx-commits] [PATCH] D127834: [libc++][ranges] Implement `ranges::stable_sort`.

[Mark de Wever via Phabricator via libcxx-commits]

Mordante added inline comments.


================
Comment at: libcxx/test/std/algorithms/alg.sorting/alg.sort/stable.sort/ranges.stable.sort.pass.cpp:139
+      V{10, 101}, {12, 121}, {3, 31}, {5, 51}, {3, 32}, {3, 33}, {11, 111}, {12, 122}, {4, 41}, {4, 42}, {4, 43},
+      {1, 11}, {6, 61}, {3, 34}, {10, 102}, {8, 81}, {12, 123}, {1, 12}, {1, 13}, {5, 52}
+    };
----------------
var-const wrote:
> Mordante wrote:
> > I would suggest to make the `original_order` member a simple integer sequence: 1, 2, 3, etc. That makes it easier to verify whether the output is correct. Identical values will have incrementing values.
> I started with that, but then I had the idea of enumerating each duplicate value instead (read those `31`, `32`, `33` as `3.1`, `3.2`, `3.3`, etc.). I think it makes it more readable because following the numbering within a duplicate is much easier than following the numbering across all the elements. What do you think?
How do you feel about making the `original_order` a double and use `3.1`?

Since the same constants written the same in the source there shouldn't be an issue with floating point rounding.


================
Comment at: libcxx/test/std/algorithms/alg.sorting/alg.sort/stable.sort/ranges.stable.sort.pass.cpp:150
+      {11, 111},
+      {12, 121}, {12, 122}, {12, 123},
+    };
----------------
var-const wrote:
> Mordante wrote:
> > Is the trailing comma allowed?
> Yes. Removed it for redundancy.
TIL, fun that it's allowed in some places.


================
Comment at: libcxx/test/std/algorithms/alg.sorting/alg.sort/stable.sort/ranges.stable.sort.pass.cpp:168
+
+  { // A custom comparator works.
+    {
----------------
var-const wrote:
> Mordante wrote:
> > It would be good to validate stability in these tests too.
> To clarify, do you mean all the tests in `test()`? Or just the tests with a custom comparator?
I think it's mainly important for this test and the ones below.


================
Comment at: libcxx/test/std/algorithms/alg.sorting/alg.sort/stable.sort/ranges.stable.sort.pass.cpp:246
+  }
+
+  { // `std::ranges::dangling` is returned.
----------------
var-const wrote:
> Mordante wrote:
> > Here we can validate complexity. Obviously implementations can make different choices regarding when there's not "enough extra memory" but we can test the N log (N) for a small number of items.
> Similar to the `sort` patch, I don't think we have a great way of doing this:
> 
> - we can use the exact number of operations our implementation happens to perform (we have some precedent in e.g. `test/libcxx/algorithms/alg.sorting/alg.heap.operations/make.heap/complexity.pass.cpp`), but that would make it libc++-specific and, IMO, has limited usefulness;
> - simply testing for `num_operations < N*log(N)` isn't going to work because it's actually `k*N*log(N)`, where `k` is an arbitrary constant;
> - the "proper" way would be to test with increasingly large inputs and applying some math to calculate the growth factor, but that seems like a sizable project in itself, even assuming it's worth the implementation effort.
> 
Here http://eel.is/c++draft/stable.sort#5 lists the exact number of comparisons to do and that the number of projections is double of that. So I think we can use that value as an upper bound, for example with N = 10.


================
Comment at: libcxx/test/std/algorithms/alg.sorting/alg.sort/stable.sort/ranges.stable.sort.pass.cpp:255
+  test();
+  // Note: `stable_sort` is not `constexpr`.
+
----------------
var-const wrote:
> Mordante wrote:
> > Interesting since it's possible to allocate memory in `constexpr` functions.
> I know that [[ http://wg21.link/p0202 | P0202 ]] was adding `constexpr` to algorithms. At the time (in 2017), making `stable_sort` `constexpr` was infeasible:
> 
> > Algorithms `stable_partition`, `inplace_merge` and `stable_sort` allocate memory, construct variables using placement new, use `unique_ptr` and do other things not acceptable in constexpr expressions. Making those algorithms constexpr seems to be a hard task that would require a lot of intrinsics. Those algorithms are not marked with constexpr in this wording.
> 
> I don't know if there's been any work in that direction since then. Perhaps it's ripe for a new paper?
I didn't investigate the reason, but this is indeed what I expected :-)

Based on the unanimous consent in this poll https://github.com/cplusplus/papers/issues/1222#issuecomment-1159203566
the time is indeed ripe and a paper is already available.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127834/new/

https://reviews.llvm.org/D127834