don't specify log base in big-O
This commit is contained in:
parent
88612e3657
commit
818bef5558
|
@ -622,7 +622,7 @@ impl<T: Ord> BinaryHeap<T> {
|
|||
|
||||
// `rebuild` takes O(len1 + len2) operations
|
||||
// and about 2 * (len1 + len2) comparisons in the worst case
|
||||
// while `extend` takes O(len2 * log_2(len1)) operations
|
||||
// while `extend` takes O(len2 * log(len1)) operations
|
||||
// and about 1 * len2 * log_2(len1) comparisons in the worst case,
|
||||
// assuming len1 >= len2.
|
||||
#[inline]
|
||||
|
@ -643,7 +643,7 @@ impl<T: Ord> BinaryHeap<T> {
|
|||
/// The remaining elements will be removed on drop in heap order.
|
||||
///
|
||||
/// Note:
|
||||
/// * `.drain_sorted()` is `O(n * lg(n))`; much slower than `.drain()`.
|
||||
/// * `.drain_sorted()` is `O(n * log(n))`; much slower than `.drain()`.
|
||||
/// You should use the latter for most cases.
|
||||
///
|
||||
/// # Examples
|
||||
|
|
|
@ -40,7 +40,7 @@ use UnderflowResult::*;
|
|||
/// performance on *small* nodes of elements which are cheap to compare. However in the future we
|
||||
/// would like to further explore choosing the optimal search strategy based on the choice of B,
|
||||
/// and possibly other factors. Using linear search, searching for a random element is expected
|
||||
/// to take O(B * log<sub>B</sub>(n)) comparisons, which is generally worse than a BST. In practice,
|
||||
/// to take O(B * log(n)) comparisons, which is generally worse than a BST. In practice,
|
||||
/// however, performance is excellent.
|
||||
///
|
||||
/// It is a logic error for a key to be modified in such a way that the key's ordering relative to
|
||||
|
|
Loading…
Reference in New Issue