Rollup merge of #77969 - ryan-scott-dev:bigo-notation-consistency, r=m-ou-se
Doc formating consistency between slice sort and sort_unstable, and big O notation consistency Updated documentation for slice sorting methods to be consistent between stable and unstable versions, which just ended up being minor formatting differences. I also went through and updated any doc comments with big O notation to be consistent with #74010 by italicizing them rather than having them in a code block.
This commit is contained in:
commit
39f8289e38
5 changed files with 18 additions and 18 deletions
|
@ -167,7 +167,7 @@ mod hack {
|
|||
impl<T> [T] {
|
||||
/// Sorts the slice.
|
||||
///
|
||||
/// This sort is stable (i.e., does not reorder equal elements) and `O(n * log(n))` worst-case.
|
||||
/// This sort is stable (i.e., does not reorder equal elements) and *O*(*n* \* log(*n*)) worst-case.
|
||||
///
|
||||
/// When applicable, unstable sorting is preferred because it is generally faster than stable
|
||||
/// sorting and it doesn't allocate auxiliary memory.
|
||||
|
@ -202,7 +202,7 @@ impl<T> [T] {
|
|||
|
||||
/// Sorts the slice with a comparator function.
|
||||
///
|
||||
/// This sort is stable (i.e., does not reorder equal elements) and `O(n * log(n))` worst-case.
|
||||
/// This sort is stable (i.e., does not reorder equal elements) and *O*(*n* \* log(*n*)) worst-case.
|
||||
///
|
||||
/// The comparator function must define a total ordering for the elements in the slice. If
|
||||
/// the ordering is not total, the order of the elements is unspecified. An order is a
|
||||
|
@ -256,8 +256,8 @@ impl<T> [T] {
|
|||
|
||||
/// Sorts the slice with a key extraction function.
|
||||
///
|
||||
/// This sort is stable (i.e., does not reorder equal elements) and `O(m * n * log(n))`
|
||||
/// worst-case, where the key function is `O(m)`.
|
||||
/// This sort is stable (i.e., does not reorder equal elements) and *O*(*m* \* *n* \* log(*n*))
|
||||
/// worst-case, where the key function is *O*(*m*).
|
||||
///
|
||||
/// For expensive key functions (e.g. functions that are not simple property accesses or
|
||||
/// basic operations), [`sort_by_cached_key`](#method.sort_by_cached_key) is likely to be
|
||||
|
@ -299,8 +299,8 @@ impl<T> [T] {
|
|||
///
|
||||
/// During sorting, the key function is called only once per element.
|
||||
///
|
||||
/// This sort is stable (i.e., does not reorder equal elements) and `O(m * n + n * log(n))`
|
||||
/// worst-case, where the key function is `O(m)`.
|
||||
/// This sort is stable (i.e., does not reorder equal elements) and *O*(*m* \* *n* + *n* \* log(*n*))
|
||||
/// worst-case, where the key function is *O*(*m*).
|
||||
///
|
||||
/// For simple key functions (e.g., functions that are property accesses or
|
||||
/// basic operations), [`sort_by_key`](#method.sort_by_key) is likely to be
|
||||
|
@ -944,7 +944,7 @@ where
|
|||
/// 1. for every `i` in `1..runs.len()`: `runs[i - 1].len > runs[i].len`
|
||||
/// 2. for every `i` in `2..runs.len()`: `runs[i - 2].len > runs[i - 1].len + runs[i].len`
|
||||
///
|
||||
/// The invariants ensure that the total running time is `O(n * log(n))` worst-case.
|
||||
/// The invariants ensure that the total running time is *O*(*n* \* log(*n*)) worst-case.
|
||||
fn merge_sort<T, F>(v: &mut [T], mut is_less: F)
|
||||
where
|
||||
F: FnMut(&T, &T) -> bool,
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue