Merge branch 'master' into patch-3

Author: Parva9eh

AVL Tree/README.markdown

@@ -53,7 +53,7 @@ For the rotation we're using the terminology:
 * *RotationSubtree* - subtree of the *Pivot* upon the side of rotation
 * *OppositeSubtree* - subtree of the *Pivot* opposite the side of rotation
 
-Let take an example of balancing the unbalanced tree using *Right* (clockwise direction) rotation: 
+Let take an example of balancing the unbalanced tree using *Right* (clockwise direction) rotation:
 
 ![Rotation1](Images/RotationStep1.jpg) ![Rotation2](Images/RotationStep2.jpg) ![Rotation3](Images/RotationStep3.jpg)
 
@@ -76,7 +76,7 @@ Insertion never needs more than 2 rotations. Removal might require up to __log(n
 
 ## The code
 
-Most of the code in [AVLTree.swift](AVLTree.swift) is just regular [binary search tree](../Binary Search Tree/) stuff. You'll find this in any implementation of a binary search tree. For example, searching the tree is exactly the same. The only things that an AVL tree does slightly differently are inserting and deleting the nodes.
+Most of the code in [AVLTree.swift](AVLTree.swift) is just regular [binary search tree](../Binary%20Search%20Tree/) stuff. You'll find this in any implementation of a binary search tree. For example, searching the tree is exactly the same. The only things that an AVL tree does slightly differently are inserting and deleting the nodes.
 
 > **Note:** If you're a bit fuzzy on the regular operations of a binary search tree, I suggest you [catch up on those first](../Binary%20Search%20Tree/). It will make the rest of the AVL tree easier to understand.
 

Binary Search Tree/README.markdown

@@ -195,7 +195,7 @@ For convenience, let's add an init method that calls `insert()` for all the elem
     precondition(array.count > 0)
     self.init(value: array.first!)
     for v in array.dropFirst() {
-      insert(v, parent: self)
+      insert(value: v)
     }
   }
 ```

Bounded Priority Queue/README.markdown

@@ -26,7 +26,7 @@ Suppose that we wish to insert the element `G` with priority 0.1 into this BPQ.
 
 ## Implementation
 
-While a [heap](../Heap/) may be a really simple implementation for a priority queue, a sorted [linked list](../Linked List/) allows for **O(k)** insertion and **O(1)** deletion, where **k** is the bounding number of elements.
+While a [heap](../Heap/) may be a really simple implementation for a priority queue, a sorted [linked list](../Linked%20List/) allows for **O(k)** insertion and **O(1)** deletion, where **k** is the bounding number of elements.
 
 Here's how you could implement it in Swift:
 

Count Occurrences/README.markdown

@@ -36,7 +36,7 @@ func countOccurrencesOfKey(_ key: Int, inArray a: [Int]) -> Int {
     }
     return low
   }
-  
+
   func rightBoundary() -> Int {
     var low = 0
     var high = a.count
@@ -50,12 +50,12 @@ func countOccurrencesOfKey(_ key: Int, inArray a: [Int]) -> Int {
     }
     return low
   }
-  
+
   return rightBoundary() - leftBoundary()
 }
 ```
 
-Notice that the helper functions `leftBoundary()` and `rightBoundary()` are very similar to the [binary search](../Binary Search/) algorithm. The big difference is that they don't stop when they find the search key, but keep going.
+Notice that the helper functions `leftBoundary()` and `rightBoundary()` are very similar to the [binary search](../Binary%20Search/) algorithm. The big difference is that they don't stop when they find the search key, but keep going.
 
 To test this algorithm, copy the code to a playground and then do:
 

Depth-First Search/README.markdown

@@ -40,7 +40,7 @@ func depthFirstSearch(_ graph: Graph, source: Node) -> [String] {
 }
 ```
 
-Where a [breadth-first search](../Breadth-First Search/) visits all immediate neighbors first, a depth-first search tries to go as deep down the tree or graph as it can.
+Where a [breadth-first search](../Breadth-First%20Search/) visits all immediate neighbors first, a depth-first search tries to go as deep down the tree or graph as it can.
 
 Put this code in a playground and test it like so:
 
@@ -71,13 +71,13 @@ print(nodesExplored)
 ```
 
 This will output: `["a", "b", "d", "e", "h", "f", "g", "c"]`
-   
+
 ## What is DFS good for?
 
 Depth-first search can be used to solve many problems, for example:
 
 * Finding connected components of a sparse graph
-* [Topological sorting](../Topological Sort/) of nodes in a graph
+* [Topological sorting](../Topological%20Sort/) of nodes in a graph
 * Finding bridges of a graph (see: [Bridges](https://en.wikipedia.org/wiki/Bridge_(graph_theory)#Bridge-finding_algorithm))
 * And lots of others!
 

Deque/README.markdown

@@ -9,43 +9,43 @@ Here is a very basic implementation of a deque in Swift:
 ```swift
 public struct Deque<T> {
   private var array = [T]()
-  
+
   public var isEmpty: Bool {
     return array.isEmpty
   }
-  
+
   public var count: Int {
     return array.count
   }
-  
+
   public mutating func enqueue(_ element: T) {
     array.append(element)
   }
-  
+
   public mutating func enqueueFront(_ element: T) {
     array.insert(element, atIndex: 0)
   }
-  
+
   public mutating func dequeue() -> T? {
     if isEmpty {
       return nil
     } else {
       return array.removeFirst()
     }
   }
-  
+
   public mutating func dequeueBack() -> T? {
     if isEmpty {
       return nil
     } else {
       return array.removeLast()
     }
   }
-  
+
   public func peekFront() -> T? {
     return array.first
   }
-  
+
   public func peekBack() -> T? {
     return array.last
   }
@@ -73,7 +73,7 @@ deque.dequeue()       // 5
 This particular implementation of `Deque` is simple but not very efficient. Several operations are **O(n)**, notably `enqueueFront()` and `dequeue()`. I've included it only to show the principle of what a deque does.
 
 ## A more efficient version
-  
+
 The reason that `dequeue()` and `enqueueFront()` are **O(n)** is that they work on the front of the array. If you remove an element at the front of an array, what happens is that all the remaining elements need to be shifted in memory.
 
 Let's say the deque's array contains the following items:
@@ -92,7 +92,7 @@ Likewise, inserting an element at the front of the array is expensive because it
 
 First, the elements `2`, `3`, and `4` are moved up by one position in the computer's memory, and then the new element `5` is inserted at the position where `2` used to be.
 
-Why is this not an issue at for `enqueue()` and `dequeueBack()`? Well, these operations are performed at the end of the array. The way resizable arrays are implemented in Swift is by reserving a certain amount of free space at the back. 
+Why is this not an issue at for `enqueue()` and `dequeueBack()`? Well, these operations are performed at the end of the array. The way resizable arrays are implemented in Swift is by reserving a certain amount of free space at the back.
 
 Our initial array `[ 1, 2, 3, 4]` actually looks like this in memory:
 
@@ -120,26 +120,26 @@ public struct Deque<T> {
   private var head: Int
   private var capacity: Int
   private let originalCapacity:Int
-  
+
   public init(_ capacity: Int = 10) {
     self.capacity = max(capacity, 1)
     originalCapacity = self.capacity
     array = [T?](repeating: nil, count: capacity)
     head = capacity
   }
-  
+
   public var isEmpty: Bool {
     return count == 0
   }
-  
+
   public var count: Int {
     return array.count - head
   }
-  
+
   public mutating func enqueue(_ element: T) {
     array.append(element)
   }
-  
+
   public mutating func enqueueFront(_ element: T) {
     // this is explained below
   }
@@ -155,15 +155,15 @@ public struct Deque<T> {
       return array.removeLast()
     }
   }
-  
+
   public func peekFront() -> T? {
     if isEmpty {
       return nil
     } else {
       return array[head]
     }
   }
-  
+
   public func peekBack() -> T? {
     if isEmpty {
       return nil
@@ -176,7 +176,7 @@ public struct Deque<T> {
 
 It still largely looks the same -- `enqueue()` and `dequeueBack()` haven't changed -- but there are also a few important differences. The array now stores objects of type `T?` instead of just `T` because we need some way to mark array elements as being empty.
 
-The `init` method allocates a new array that contains a certain number of `nil` values. This is the free room we have to work with at the beginning of the array. By default this creates 10 empty spots. 
+The `init` method allocates a new array that contains a certain number of `nil` values. This is the free room we have to work with at the beginning of the array. By default this creates 10 empty spots.
 
 The `head` variable is the index in the array of the front-most object. Since the queue is currently empty, `head` points at an index beyond the end of the array.
 
@@ -219,7 +219,7 @@ Notice how the array has resized itself. There was no room to add the `1`, so Sw
 	                          |
 	                          head
 
-> **Note:** You won't see those empty spots at the back of the array when you `print(deque.array)`. This is because Swift hides them from you. Only the ones at the front of the array show up. 
+> **Note:** You won't see those empty spots at the back of the array when you `print(deque.array)`. This is because Swift hides them from you. Only the ones at the front of the array show up.
 
 The `dequeue()` method does the opposite of `enqueueFront()`, it reads the value at `head`, sets the array element back to `nil`, and then moves `head` one position to the right:
 
@@ -250,7 +250,7 @@ There is one tiny problem... If you enqueue a lot of objects at the front, you'r
   }
 ```
 
-If `head` equals 0, there is no room left at the front. When that happens, we add a whole bunch of new `nil` elements to the array. This is an **O(n)** operation but since this cost gets divided over all the `enqueueFront()`s, each individual call to `enqueueFront()` is still **O(1)** on average. 
+If `head` equals 0, there is no room left at the front. When that happens, we add a whole bunch of new `nil` elements to the array. This is an **O(n)** operation but since this cost gets divided over all the `enqueueFront()`s, each individual call to `enqueueFront()` is still **O(1)** on average.
 
 > **Note:** We also multiply the capacity by 2 each time this happens, so if your queue grows bigger and bigger, the resizing happens less often. This is also what Swift arrays automatically do at the back.
 
@@ -302,7 +302,7 @@ This way we can strike a balance between fast enqueuing and dequeuing at the fro
 
 ## See also
 
-Other ways to implement deque are by using a [doubly linked list](../Linked List/), a [circular buffer](../Ring Buffer/), or two [stacks](../Stack/) facing opposite directions.
+Other ways to implement deque are by using a [doubly linked list](../Linked%20List/), a [circular buffer](../Ring%20Buffer/), or two [stacks](../Stack/) facing opposite directions.
 
 [A fully-featured deque implementation in Swift](https://github.com/lorentey/Deque)
 

Graph/README.markdown

@@ -28,7 +28,7 @@ The following are also graphs:
 
 ![Tree and linked list](Images/TreeAndList.png)
 
-On the left is a [tree](../Tree/) structure, on the right a [linked list](../Linked List/). Both can be considered graphs, but in a simpler form. After all, they have vertices (nodes) and edges (links).
+On the left is a [tree](../Tree/) structure, on the right a [linked list](../Linked%20List/). Both can be considered graphs, but in a simpler form. After all, they have vertices (nodes) and edges (links).
 
 The very first graph I showed you contained *cycles*, where you can start off at a vertex, follow a path, and come back to the original vertex. A tree is a graph without such cycles.
 
@@ -42,15 +42,15 @@ Like a tree this does not have any cycles in it (no matter where you start, ther
 
 Maybe you're shrugging your shoulders and thinking, what's the big deal? Well, it turns out that graphs are an extremely useful data structure.
 
-If you have some programming problem where you can represent some of your data as vertices and some of it as edges between those vertices, then you can draw your problem as a graph and use well-known graph algorithms such as [breadth-first search](../Breadth-First Search/) or [depth-first search](../Depth-First Search) to find a solution.
+If you have some programming problem where you can represent some of your data as vertices and some of it as edges between those vertices, then you can draw your problem as a graph and use well-known graph algorithms such as [breadth-first search](../Breadth-First%20Search/) or [depth-first search](../Depth-First%20Search) to find a solution.
 
 For example, let's say you have a list of tasks where some tasks have to wait on others before they can begin. You can model this using an acyclic directed graph:
 
 ![Tasks as a graph](Images/Tasks.png)
 
 Each vertex represents a task. Here, an edge between two vertices means that the source task must be completed before the destination task can start. So task C cannot start before B and D are finished, and B nor D can start before A is finished.
 
-Now that the problem is expressed using a graph, you can use a depth-first search to perform a [topological sort](../Topological Sort/). This will put the tasks in an optimal order so that you minimize the time spent waiting for tasks to complete. (One possible order here is A, B, D, E, C, F, G, H, I, J, K.)
+Now that the problem is expressed using a graph, you can use a depth-first search to perform a [topological sort](../Topological%20Sort/). This will put the tasks in an optimal order so that you minimize the time spent waiting for tasks to complete. (One possible order here is A, B, D, E, C, F, G, H, I, J, K.)
 
 Whenever you're faced with a tough programming problem, ask yourself, "how can I express this problem using a graph?" Graphs are all about representing relationships between your data. The trick is in how you define "relationship".
 

Heap Sort/README.markdown

@@ -40,7 +40,7 @@ And fix up the heap to make it valid max-heap again:
 
 As you can see, the largest items are making their way to the back. We repeat this process until we arrive at the root node and then the whole array is sorted.
 
-> **Note:** This process is very similar to [selection sort](../Selection Sort/), which repeatedly looks for the minimum item in the remainder of the array. Extracting the minimum or maximum value is what heaps are good at.
+> **Note:** This process is very similar to [selection sort](../Selection%20Sort/), which repeatedly looks for the minimum item in the remainder of the array. Extracting the minimum or maximum value is what heaps are good at.
 
 Performance of heap sort is **O(n lg n)** in best, worst, and average case. Because we modify the array directly, heap sort can be performed in-place. But it is not a stable sort: the relative order of identical elements is not preserved.