diff options
| author | kennytm <kennytm@gmail.com> | 2018-09-12 12:17:38 +0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2018-09-12 12:17:38 +0800 |
| commit | 13ec061df42dfe52d0412297efcb3ce59d540240 (patch) | |
| tree | c86bc9f3044acb11eda37b1c60ef5b628b0edf26 /src/libstd | |
| parent | 28890152fee5cbf7c6140d56dde837080354bd25 (diff) | |
| parent | abe0f027ae23b47dfabeb217aaa56b155d565ae3 (diff) | |
| download | rust-13ec061df42dfe52d0412297efcb3ce59d540240.tar.gz rust-13ec061df42dfe52d0412297efcb3ce59d540240.zip | |
Rollup merge of #54107 - thevaleriemack:master, r=Mark-Simulacrum
Fix typos in libstd hash map modified growth algo description to read "the first table overflows into the second, and the second into the first." plus smaller typos
Diffstat (limited to 'src/libstd')
| -rw-r--r-- | src/libstd/collections/hash/map.rs | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/src/libstd/collections/hash/map.rs b/src/libstd/collections/hash/map.rs index 3e54b502234..804d43f4fc6 100644 --- a/src/libstd/collections/hash/map.rs +++ b/src/libstd/collections/hash/map.rs @@ -166,14 +166,14 @@ impl DefaultResizePolicy { // Our hash generation scheme consists of generating a 64-bit hash and // truncating the most significant bits. When moving to the new table, we // simply introduce a new bit to the front of the hash. Therefore, if an -// elements has ideal index i in the old table, it can have one of two ideal +// element has ideal index i in the old table, it can have one of two ideal // locations in the new table. If the new bit is 0, then the new ideal index // is i. If the new bit is 1, then the new ideal index is n + i. Intuitively, // we are producing two independent tables of size n, and for each element we // independently choose which table to insert it into with equal probability. -// However the rather than wrapping around themselves on overflowing their -// indexes, the first table overflows into the first, and the first into the -// second. Visually, our new table will look something like: +// However, rather than wrapping around themselves on overflowing their +// indexes, the first table overflows into the second, and the second into the +// first. Visually, our new table will look something like: // // [yy_xxx_xxxx_xxx|xx_yyy_yyyy_yyy] // |
