The implementation of the estimates library in estimates.h doesn't support strict weak ordering, which may result in problems while used with std::sort, and other std functions that expect this property. For reference:

https://github.com/Voultapher/sort-research-rs/blob/main/writeup/sort_safety/text.md#ord-safety

and this discussion.

For operators to implement strict weak ordering, they must satisfy these properties:

1. Irreflexivity of < (not (x < x))
2. Asymmetry of < (if x < y then not (y < x))
3. Transitivity of < (if x < y and y < z then x < z)
4. Transitivity of equivalence (if x ≡ y and y ≡ z then x ≡ z, where a ≡ b means neither a < b nor b < a)

hese operators do not implement strict weak ordering. Here's why:

1. The use of in the equality comparison combined with the implementation of < operator can violate transitivity. For example: nearlyEqual

• • If we have three values a, b, c where:

  • a - b

    < epsilon (so a == b is true)

  • b - c

    < epsilon (so b == c is true)

  • But |a - c| >= epsilon
  • This breaks transitivity of equivalence because a ≡ b and b ≡ c but not a ≡ c

1. The implementation of < using != and then a direct comparison can lead to inconsistent results when dealing with nearly equal values. The fact that it first checks for inequality using the approximate equality test and then does a direct comparison can create situations where the transitivity property is violated.

To fix this and implement proper strict weak ordering, the operators should be modified to use consistent comparison logic that doesn't mix approximate equality with direct comparison. One approach would be to implement the comparison based purely on the numeric values with a consistent epsilon-based comparison throughout.

A corrected version might look like:

bool operator<(const OptimizerEstimate<ValueType, EstimateType>& e) const {
    // Use a consistent epsilon-based comparison
    return (this->_estimate._v + ValueType::epsilon()) < e._estimate._v;
}