Applied requested changes

- typos and wording
- merged Sequence and Map performance cost tables

Author: root-goblin

library/std/src/collections/mod.rs

@@ -79,11 +79,11 @@
 //! see each type's documentation, and note that the names of actual methods may
 //! differ from the tables below on certain collections.
 //!
-//! Throughout the documentation, we will adhere to the following conventions for
-//! operation notation:
+//! Throughout the documentation, we will adhere to the following conventions
+//! for operation notation:
 //!
 //! * The collection's size is denoted by `n`.
-//! * If a second collection is involved, it's size is denoted by `m`.
+//! * If a second collection is involved, its size is denoted by `m`.
 //! * Item indices are denoted by `i`.
 //! * Operations which have an *amortized* cost are suffixed with a `*`.
 //! * Operations with an *expected* cost are suffixed with a `~`.
@@ -94,38 +94,35 @@
 //! *Amortized* costs are calculated to account for the time cost of such resize
 //! operations *over a sufficiently large series of operations*. An individual
 //! operation may be slower or faster due to the sporadic nature of collection
-//! resizing, however the average cost per operation will eventually equal the
-//! amortized cost.
+//! resizing, however the average cost per operation will approach the amortized
+//! cost.
 //!
 //! Rust's collections never automatically shrink, so removal operations aren't
 //! amortized.
 //!
-//! [`HashMap`] uses *expected* costs to denote that it is theoretically possible,
-//! though very unlikely, for [`HashMap`] to experience worse performance than
-//! the expected cost. This is due to the probablilistic nature of hashing -
-//! i.e. it is possible to generate a duplicate hash given some input key that
-//! requires extra computation to correct, but exceptionally unlikely.
+//! [`HashMap`] uses *expected* costs. It is theoretically possible, though very
+//! unlikely, for [`HashMap`] to experience significantly worse performance than
+//! the expected cost. This is due to the probabilistic nature of hashing - i.e.
+//! it is possible to generate a duplicate hash given some input key that will
+//! requires extra computation to correct.
 //!
-//! ## Cost of Sequence Operations
+//! ## Cost of Collection Operations
 //!
-//! |                | get(i)                 | insert(i)               | remove(i)              | append(Vec(m))    | split_off(i)           |
-//! |----------------|------------------------|-------------------------|------------------------|-------------------|------------------------|
-//! | [`Vec`]        | *O*(1)                 | *O*(*n*-*i*)*           | *O*(*n*-*i*)           | *O*(*m*)*         | *O*(*n*-*i*)           |
-//! | [`VecDeque`]   | *O*(1)                 | *O*(min(*i*, *n*-*i*))* | *O*(min(*i*, *n*-*i*)) | *O*(*m*)*         | *O*(min(*i*, *n*-*i*)) |
-//! | [`LinkedList`] | *O*(min(*i*, *n*-*i*)) | *O*(min(*i*, *n*-*i*))  | *O*(min(*i*, *n*-*i*)) | *O*(1)            | *O*(min(*i*, *n*-*i*)) |
 //!
-//! Note that where ties occur, [`Vec`] is generally going to be faster than [`VecDeque`], and
-//! [`VecDeque`] is generally going to be faster than [`LinkedList`].
+//! |                | get(i)                 | insert(i)               | remove(i)              | append(Vec(m))    | split_off(i)           | range           | append       |
+//! |----------------|------------------------|-------------------------|------------------------|-------------------|------------------------|-----------------|--------------|
+//! | [`Vec`]        | *O*(1)                 | *O*(*n*-*i*)*           | *O*(*n*-*i*)           | *O*(*m*)*         | *O*(*n*-*i*)           | N/A             | N/A          |
+//! | [`VecDeque`]   | *O*(1)                 | *O*(min(*i*, *n*-*i*))* | *O*(min(*i*, *n*-*i*)) | *O*(*m*)*         | *O*(min(*i*, *n*-*i*)) | N/A             | N/A          |
+//! | [`LinkedList`] | *O*(min(*i*, *n*-*i*)) | *O*(min(*i*, *n*-*i*))  | *O*(min(*i*, *n*-*i*)) | *O*(1)            | *O*(min(*i*, *n*-*i*)) | N/A             | N/A          |
+//! | [`HashMap`]    | *O*(1)~                | *O*(1)~*                | *O*(1)~                | N/A               | N/A                    | N/A             | N/A          |
+//! | [`BTreeMap`]   | *O*(log(*n*))          | *O*(log(*n*))           | *O*(log(*n*))          | N/A               | N/A                    | *O*(log(*n*))   | *O*(*n*+*m*) |
 //!
-//! ## Cost of Map Operations
+//! Note that where ties occur, [`Vec`] is generally going to be faster than
+//! [`VecDeque`], and [`VecDeque`] is generally going to be faster than
+//! [`LinkedList`].
 //!
 //! For Sets, all operations have the cost of the equivalent Map operation.
 //!
-//! |              | get           | insert        | remove        | range         | append       |
-//! |--------------|---------------|---------------|---------------|---------------|--------------|
-//! | [`HashMap`]  | *O*(1)~       | *O*(1)~*      | *O*(1)~       | N/A           | N/A          |
-//! | [`BTreeMap`] | *O*(log(*n*)) | *O*(log(*n*)) | *O*(log(*n*)) | *O*(log(*n*)) | *O*(*n*+*m*) |
-//!
 //! # Correct and Efficient Usage of Collections
 //!
 //! Of course, knowing which collection is the right one for the job doesn't