Skip to content

Commit d7b07d6

Browse files
committed
Merge pull request #293 from btakashi/master
More minor fixes to collections overview
2 parents eb55c5a + 7f96ed9 commit d7b07d6

File tree

3 files changed

+12
-13
lines changed

3 files changed

+12
-13
lines changed

overviews/collections/concrete-immutable-collection-classes.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -98,7 +98,7 @@ Here are some simple operations performed on a stack:
9898
scala> hasOne.pop
9999
res19: scala.collection.immutable.Stack[Int] = Stack()
100100

101-
Immutable stacks are used rarely in Scala programs because their functionality is subsumed by lists: A `push` on an immutable stack is the same as a `::` on a list and a `pop` on a stack is the same a `tail` on a list.
101+
Immutable stacks are used rarely in Scala programs because their functionality is subsumed by lists: A `push` on an immutable stack is the same as a `::` on a list and a `pop` on a stack is the same as a `tail` on a list.
102102

103103
## Immutable Queues
104104

@@ -150,11 +150,11 @@ Ranges are represented in constant space, because they can be defined by just th
150150

151151
Hash tries are a standard way to implement immutable sets and maps efficiently. They are supported by class [immutable.HashMap](http://www.scala-lang.org/api/{{ site.scala-version }}/scala/collection/immutable/HashMap.html). Their representation is similar to vectors in that they are also trees where every node has 32 elements or 32 subtrees. But the selection of these keys is now done based on hash code. For instance, to find a given key in a map, one first takes the hash code of the key. Then, the lowest 5 bits of the hash code are used to select the first subtree, followed by the next 5 bits and so on. The selection stops once all elements stored in a node have hash codes that differ from each other in the bits that are selected up to this level.
152152

153-
Hash tries strike a nice balance between reasonably fast lookups and reasonably efficient functional insertions (`+`) and deletions (`-`). That's why they underly Scala's default implementations of immutable maps and sets. In fact, Scala has a further optimization for immutable sets and maps that contain less than five elements. Sets and maps with one to four elements are stored as single objects that just contain the elements (or key/value pairs in the case of a map) as fields. The empty immutable set and the empty immutable map is in each case a single object - there's no need to duplicate storage for those because and empty immutable set or map will always stay empty.
153+
Hash tries strike a nice balance between reasonably fast lookups and reasonably efficient functional insertions (`+`) and deletions (`-`). That's why they underly Scala's default implementations of immutable maps and sets. In fact, Scala has a further optimization for immutable sets and maps that contain less than five elements. Sets and maps with one to four elements are stored as single objects that just contain the elements (or key/value pairs in the case of a map) as fields. The empty immutable set and the empty immutable map is in each case a single object - there's no need to duplicate storage for those because an empty immutable set or map will always stay empty.
154154

155155
## Red-Black Trees
156156

157-
Red-black trees are a form of balanced binary trees where some nodes are designated "red" and others designated "black." Like any balanced binary tree, operations on them reliably complete in time logarithmic to the size of the tree.
157+
Red-black trees are a form of balanced binary tree where some nodes are designated "red" and others designated "black." Like any balanced binary tree, operations on them reliably complete in time logarithmic to the size of the tree.
158158

159159
Scala provides implementations of immutable sets and maps that use a red-black tree internally. Access them under the names [TreeSet](http://www.scala-lang.org/api/{{ site.scala-version }}/scala/collection/immutable/TreeSet.html) and [TreeMap](http://www.scala-lang.org/api/{{ site.scala-version }}/scala/collection/immutable/TreeMap.html).
160160

@@ -164,7 +164,7 @@ Scala provides implementations of immutable sets and maps that use a red-black t
164164
scala> res11 + 1 + 3 + 3
165165
res12: scala.collection.immutable.TreeSet[Int] = TreeSet(1, 3)
166166

167-
Red black trees are the standard implementation of `SortedSet` in Scala, because they provide an efficient iterator that returns all elements in sorted order.
167+
Red-black trees are the standard implementation of `SortedSet` in Scala, because they provide an efficient iterator that returns all elements in sorted order.
168168

169169
## Immutable BitSets
170170

@@ -185,7 +185,7 @@ Operations on bit sets are very fast. Testing for inclusion takes constant time.
185185

186186
## List Maps
187187

188-
A [ListMap](http://www.scala-lang.org/api/{{ site.scala-version }}/scala/collection/immutable/ListMap.html) represents a map as a linked list of key-value pairs. In general, operations on a list map might have to iterate through the entire list. Thus, operations on a list map take time linear in the size of the map. In fact there is little usage for list maps in Scala because standard immutable maps are almost always faster. The only possible difference is if the map is for some reason constructed in such a way that the first elements in the list are selected much more often than the other elements.
188+
A [ListMap](http://www.scala-lang.org/api/{{ site.scala-version }}/scala/collection/immutable/ListMap.html) represents a map as a linked list of key-value pairs. In general, operations on a list map might have to iterate through the entire list. Thus, operations on a list map take time linear in the size of the map. In fact there is little usage for list maps in Scala because standard immutable maps are almost always faster. The only possible exception to this is if the map is for some reason constructed in such a way that the first elements in the list are selected much more often than the other elements.
189189

190190
scala> val map = scala.collection.immutable.ListMap(1->"one", 2->"two")
191191
map: scala.collection.immutable.ListMap[Int,java.lang.String] =

overviews/collections/maps.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -74,7 +74,7 @@ Mutable maps support in addition the operations summarized in the following tabl
7474
| **Cloning:** | |
7575
| `ms.clone` |Returns a new mutable map with the same mappings as `ms`.|
7676

77-
The addition and removal operations for maps mirror those for sets. As is the for sets, mutable maps also support the non-destructive addition operations `+`, `-`, and `updated`, but they are used less frequently because they involve a copying of the mutable map. Instead, a mutable map `m` is usually updated "in place", using the two variants `m(key) = value` or `m += (key -> value)`. There are is also the variant `m put (key, value)`, which returns an `Option` value that contains the value previously associated with `key`, or `None` if the `key` did not exist in the map before.
77+
The addition and removal operations for maps mirror those for sets. Like sets, mutable maps also support the non-destructive addition operations `+`, `-`, and `updated`, but they are used less frequently because they involve a copying of the mutable map. Instead, a mutable map `m` is usually updated "in place", using the two variants `m(key) = value` or `m += (key -> value)`. There is also the variant `m put (key, value)`, which returns an `Option` value that contains the value previously associated with `key`, or `None` if the `key` did not exist in the map before.
7878

7979
The `getOrElseUpdate` is useful for accessing maps that act as caches. Say you have an expensive computation triggered by invoking a function `f`:
8080

@@ -85,7 +85,7 @@ The `getOrElseUpdate` is useful for accessing maps that act as caches. Say you h
8585

8686
Assume further that `f` has no side-effects, so invoking it again with the same argument will always yield the same result. In that case you could save time by storing previously computed bindings of argument and results of `f` in a map and only computing the result of `f` if a result of an argument was not found there. One could say the map is a _cache_ for the computations of the function `f`.
8787

88-
val cache = collection.mutable.Map[String, String]()
88+
scala> val cache = collection.mutable.Map[String, String]()
8989
cache: scala.collection.mutable.Map[String,String] = Map()
9090

9191
You can now create a more efficient caching version of the `f` function:
@@ -110,7 +110,7 @@ Note that the second argument to `getOrElseUpdate` is "by-name", so the computat
110110

111111
### Synchronized Sets and Maps ###
112112

113-
To get a thread-safe mutable map, you can mix the `SynchronizedMap` trait trait into whatever particular map implementation you desire. For example, you can mix `SynchronizedMap` into `HashMap`, as shown in the code below. This example begins with an import of two traits, `Map` and `SynchronizedMap`, and one class, `HashMap`, from package `scala.collection.mutable`. The rest of the example is the definition of singleton object `MapMaker`, which declares one method, `makeMap`. The `makeMap` method declares its result type to be a mutable map of string keys to string values.
113+
To get a thread-safe mutable map, you can mix the `SynchronizedMap` trait into whatever particular map implementation you desire. For example, you can mix `SynchronizedMap` into `HashMap`, as shown in the code below. This example begins with an import of two traits, `Map` and `SynchronizedMap`, and one class, `HashMap`, from package `scala.collection.mutable`. The rest of the example is the definition of singleton object `MapMaker`, which declares one method, `makeMap`. The `makeMap` method declares its result type to be a mutable map of string keys to string values.
114114

115115
import scala.collection.mutable.{Map,
116116
SynchronizedMap, HashMap}

overviews/collections/sets.md

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -13,12 +13,11 @@ languages: [ja]
1313

1414
* **Tests** `contains`, `apply`, `subsetOf`. The `contains` method asks whether a set contains a given element. The `apply` method for a set is the same as `contains`, so `set(elem)` is the same as `set contains elem`. That means sets can also be used as test functions that return true for the elements they contain.
1515

16-
For example
16+
For example:
1717

1818

19-
val fruit = Set("apple", "orange", "peach", "banana")
20-
fruit: scala.collection.immutable.Set[java.lang.String] =
21-
Set(apple, orange, peach, banana)
19+
scala> val fruit = Set("apple", "orange", "peach", "banana")
20+
fruit: scala.collection.immutable.Set[java.lang.String] = Set(apple, orange, peach, banana)
2221
scala> fruit("peach")
2322
res0: Boolean = true
2423
scala> fruit("potato")
@@ -134,7 +133,7 @@ If you create new sets from a tree-set (for instance by concatenation or filteri
134133
scala> res2 + ("one", "two", "three", "four")
135134
res3: scala.collection.immutable.TreeSet[String] = TreeSet(four, one, three, two)
136135

137-
Sorted sets also support ranges of elements. For instance, the `range` method returns all elements from a starting element up to, but excluding, and end element. Or, the `from` method returns all elements greater or equal than a starting element in the set's ordering. The result of calls to both methods is again a sorted set. Examples:
136+
Sorted sets also support ranges of elements. For instance, the `range` method returns all elements from a starting element up to, but excluding, an end element. Or, the `from` method returns all elements greater or equal than a starting element in the set's ordering. The result of calls to both methods is again a sorted set. Examples:
138137

139138
scala> res3 range ("one", "two")
140139
res4: scala.collection.immutable.TreeSet[String] = TreeSet(one, three)

0 commit comments

Comments
 (0)