adding index terms

amejiarosario · amejiarosario · commit 286438045124 · 2019-03-22T17:46:44.000-04:00
diff --git a/book/chapters/algorithms-analysis.adoc b/book/chapters/algorithms-analysis.adoc
@@ -59,6 +59,8 @@ To give you a clearer picture of how different algorithms perform as the input s
 |Find all permutations of a string |4 sec. |> vigintillion years |> centillion years |∞ |∞
 |=============================================================================================
 
+indexterm:[Permutation]
+
 However, if you keep the input size constant, you can notice the difference between an efficient algorithm and a slow one. An excellent sorting algorithm is `mergesort` for instance, and inefficient algorithm for large inputs is `bubble sort` .
 Organizing 1 million elements with merge sort takes 20 seconds while bubble sort takes 12 days, ouch!
 The amazing thing is that both programs are measured on the same hardware with the same data!
diff --git a/book/chapters/array.adoc b/book/chapters/array.adoc
@@ -184,3 +184,5 @@ To sum up, the time complexity on an array is:
 ^|_Index/Key_ ^|_Value_ ^|_beginning_ ^|_middle_ ^|_end_ ^|_beginning_ ^|_middle_ ^|_end_
 | Array ^|O(1) ^|O(n) ^|O(n) ^|O(n) ^|O(1) ^|O(n) ^|O(n) ^|O(1) ^|O(n)
 |===
+
+indexterm:[Runtime, Linear]
diff --git a/book/chapters/backtracking.adoc b/book/chapters/backtracking.adoc
@@ -43,6 +43,8 @@ Let's do an exercise to explain better how backtracking works.
 
 > Return all the permutations (without repetitions) of a given word.
 
+indexterm:[Permutation]
+
 For instace, if you are given the word `art` these are the possible permutations:
 
 ----
diff --git a/book/chapters/big-o-examples.adoc b/book/chapters/big-o-examples.adoc
@@ -47,6 +47,8 @@ As you can see, in both examples (array and linked list) if the input is a colle
 
 Represented in Big O notation as *O(log n)*, when an algorithm has this running time it means that as the size of the input grows the number of operations grows very slowly. Logarithmic algorithms are very scalable. One example is the *binary search*.
 
+indexterm:[Runtime, Logarithmic]
+
 [#logarithmic-example]
 === Searching on a sorted array
 
@@ -102,17 +104,18 @@ The ((Merge Sort)), like its name indicates, has two functions merge and sort. L
 .Sort part of the mergeSort
 [source, javascript]
 ----
-include::{codedir}/runtimes/04-merge-sort.js[tag=sort]
+include::{codedir}/algorithms/sorting/merge-sort.js[tag=splitSort]
 ----
-
-Starting with the sort part, we divide the array into two halves and then merge them (line 16) recursively with the following function:
+<1> If the array only has two elements we can sort them manually.
+<2> We divide the array into two halves.
+<3> Merge the two parts recursively with the `merge` function explained below
 
 // image:image10.png[image,width=528,height=380]
 
 .Merge part of the mergeSort
 [source, javascript]
 ----
-include::{codedir}/runtimes/04-merge-sort.js[tag=merge]
+include::{codedir}/algorithms/sorting/merge-sort.js[tag=merge]
 ----
 
 The merge function combines two sorted arrays in ascending order. Let’s say that we want to sort the array `[9, 2, 5, 1, 7, 6]`. In the following illustration, you can see what each function does.
@@ -124,6 +127,8 @@ How do we obtain the running time of the merge sort algorithm? The mergesort div
 
 == Quadratic
 
+indexterm:[Runtime, Quadratic]
+
 Running times that are quadratic, O(n^2^), are the ones to watch out for. They usually don’t scale well when they have a large amount of data to process.
 
 Usually, they have double-nested loops that where each one visits all or most elements in the input. One example of this is a naïve implementation to find duplicate words on an array.
@@ -219,6 +224,8 @@ A factorial is the multiplication of all the numbers less than itself down to 1.
 
 One classic example of an _O(n!)_ algorithm is finding all the different words that can be formed with a given set of letters.
 
+indexterm:[Permutation]
+
 .Word's permutations
 // image:image15.png[image,width=528,height=377]
 [source, javascript]
diff --git a/book/chapters/bubble-sort.adoc b/book/chapters/bubble-sort.adoc
@@ -72,3 +72,5 @@ Bubble sort has a <<Quadratic>> running time, as you might infer from the nested
 - <<Adaptive>>: [big]#✅# Yes, _O(n)_ when already sorted
 - Time Complexity: [big]#⛔️# <<Quadratic>> _O(n^2^)_
 - Space Complexity: [big]#✅# <<Constant>> _O(1)_
+
+indexterm:[Runtime, Quadratic]
diff --git a/book/chapters/divide-and-conquer--fibonacci.adoc b/book/chapters/divide-and-conquer--fibonacci.adoc
@@ -2,6 +2,8 @@
 
 To illustrate how we can solve a problem using divide and conquer, let's write a program to find the n-th fibonacci number.
 
+indexterm:[Fibonacci]
+
 .Fibonacci Numbers
 ****
 Fibancci sequence is a serie of numbers that starts with `0, 1`, the next values are calculated as the sum of the previous two. So, we have:
diff --git a/book/chapters/divide-and-conquer--intro.adoc b/book/chapters/divide-and-conquer--intro.adoc
@@ -1,6 +1,8 @@
 Divide and conquer is an strategy for solving algorithmic problems.
 It splits the input into manageble parts recursively and finally join solved pieces to form the end result.
 
+indexterm:[Divide and Conquer]
+
 We have already done some divide and conquer algorithms. This list will refresh you the memory.
 
 .Examples of divide and conquer algorithms:
diff --git a/book/chapters/dynamic-programming--fibonacci.adoc b/book/chapters/dynamic-programming--fibonacci.adoc
@@ -4,6 +4,8 @@ Let's solve the same Fibonacci problem but this time with dynamic programming.
 
 When we have recursive functions doing duplicated work is the perfect place for a dynamic programming optimization. We can save (or cache) the results of previous operations and speed up future computations.
 
+indexterm:[Fibonacci]
+
 .Recursive Fibonacci Implemenation using Dynamic Programming
 [source, javascript]
 ----
@@ -24,4 +26,6 @@ graph G {
 
 This looks pretty linear now. It's runtime _O(n)_!
 
+indexterm:[Runtime, Linear]
+
 TIP: Saving previous results for later is a technique called "memoization" and is very common to optimize recursive algorithms with exponential time complexity.
diff --git a/book/chapters/insertion-sort.adoc b/book/chapters/insertion-sort.adoc
@@ -36,3 +36,5 @@ include::{codedir}/algorithms/sorting/insertion-sort.js[tag=sort, indent=0]
 - <<Adaptive>>: [big]#✅# Yes
 - Time Complexity: [big]#⛔️# <<Quadratic>> _O(n^2^)_
 - Space Complexity: [big]#✅# <<Constant>> _O(1)_
+
+indexterm:[Runtime, Quadratic]
diff --git a/book/chapters/linked-list.adoc b/book/chapters/linked-list.adoc
@@ -249,6 +249,8 @@ So far, we have seen two liner data structures with different use cases. Here’
 | Linked List (doubly) ^|O(n) ^|O(n) ^|O(1) ^|O(n) ^|O(1) ^|O(1) ^|O(n) ^|*O(1)* ^|O(n)
 |===
 
+indexterm:[Runtime, Linear]
+
 If you compare the singly linked list vs. doubly linked list, you will notice that the main difference is deleting elements from the end. For a singly list is *O(n)*, while for a doubly list is *O(1)*.
 
 Comparing an array with a doubly linked list, both have different use cases:
diff --git a/book/chapters/map-hashmap-vs-treemap.adoc b/book/chapters/map-hashmap-vs-treemap.adoc
@@ -25,3 +25,5 @@ As we discussed so far, there are trade-off between the implementations
 | Tree Map (Red-Black Tree) ^|O(log n) ^|O(n) ^|O(log n) ^|O(log n) ^|O(log n)
 |===
 {empty}* = Amortized run time. E.g. rehashing might affect run time to *O(n)*.
+
+indexterm:[Runtime, Logarithmic]
diff --git a/book/chapters/map-hashmap.adoc b/book/chapters/map-hashmap.adoc
@@ -295,4 +295,6 @@ Hash Map it’s very optimal for searching values by key in constant time *O(1)*
 |===
 {empty}* = Amortized run time. E.g. rehashing might affect run time.
 
+indexterm:[Runtime, Linear]
+
 As you can notice we have amortized times since, in the unfortunate case of a rehash, it will take O(n) while it resizes. After that, it will be *O(1)*.
diff --git a/book/chapters/map-treemap.adoc b/book/chapters/map-treemap.adoc
@@ -9,6 +9,8 @@ Implementing a Map with a tree, TreeMap, has a couple of advantages over a HashM
 * Collisions are not a concern so in the worst case is still *O(log n)*.
 * Trees are more space efficient and don’t need to allocate memory beforehand (e.g. `HashMap`’s initial capacity) nor you have to rehash when is getting full.
 
+indexterm:[Runtime, Logarithmic]
+
 Ok, now that you know the advantages, let’s implement it!
 For a full comparison read the <<HashMap vs TreeMap>> section.
 
diff --git a/book/chapters/merge-sort.adoc b/book/chapters/merge-sort.adoc
@@ -1,6 +1,8 @@
 = Merge Sort
 
-((Merge sort)) is an efficient sorting algorithm that uses <<Divide and Conquer, divide and conquer>> paradigm to accomplish its task faster. It uses auxiliary memory in the process of sorting.
+((Merge Sort)) is an efficient sorting algorithm that uses <<Divide and Conquer, divide and conquer>> paradigm to accomplish its task faster. It uses auxiliary memory in the process of sorting.
+
+indexterm:[Divide and Conquer]
 
 Merge sort algorithm splits the array in halves until 2 or less elements are left. It sorts these two elements and then merge back all halves until the whole array is sorted.
 
@@ -35,8 +37,8 @@ As you can see this function is just a wrapper to transform things to array. The
 ----
 include::{codedir}/algorithms/sorting/merge-sort.js[tag=splitSort, indent=0]
 ----
-<1> Recursively divide the array in half until two or less elements are left.
-<2> Sort two or less elements.
+<1> Sort two elements manually.
+<2> Recursively divide the array in half until two or less elements are left.
 <3> Merge back the sorted halves in ascending order.
 
 Let's now take a look at the merge function:
@@ -60,4 +62,4 @@ Merge sort has a _O(n log n)_  running time. For more details about the how to e
 - <<Adaptive>>: [big]#️❌# No, mostly sorted array takes the same time O(n log n).
 - Recursive: Yes
 - Time Complexity: [big]#✅# <<Linearithmic>> _O(n log n)_
-- Space Complexity: [big]#⚠️# <<Linear>> _O(n)_
+- Space Complexity: [big]#⚠️# <<Linear>> _O(n)_, use auxiliary memory
diff --git a/book/chapters/queue.adoc b/book/chapters/queue.adoc
@@ -70,6 +70,7 @@ As an experiment, we can see in the following table that if we had implemented t
 | Queue (w/list) ^|- ^|- ^|- ^|- ^|O(1) ^|- ^|- ^|O(1) ^|O(n)
 |===
 
+indexterm:[Runtime, Linear]
 
 = Summary
 
diff --git a/book/chapters/quick-sort.adoc b/book/chapters/quick-sort.adoc
@@ -1,6 +1,8 @@
 = Quicksort
 
-Quicksort is an efficient recursive sorting algorithm that uses "divide and conquer" paradigm to sort faster. It can be implemented in-place so it doesn't require additonal memory.
+Quicksort is an efficient recursive sorting algorithm that uses <<Divide and Conquer, divide and conquer>> paradigm to sort faster. It can be implemented in-place so it doesn't require additonal memory.
+
+indexterm:[Divide and Conquer]
 
 In practice quicksort outperforms efficient sorting algorithms like <<Merge Sort>>. And, of course, It also outperforms simple sorting algorithms like <<Selection Sort>>, <<Insertion Sort>> and <<Bubble Sort>>.
 
@@ -51,6 +53,7 @@ Merge sort has a _O(n log n)_ running time. For more details about the how to ex
 - Time Complexity: [big]#✅# <<Linearithmic>> _O(n log n)_
 - Space Complexity: [big]#⚠️# <<Linear>> _O(n)_
 
+indexterm:[Space Complexity, Linear]
 
 // Resources:
 // https://www.khanacademy.org/computing/computer-science/algorithms/quick-sort/a/linear-time-partitioning
diff --git a/book/chapters/sample.adoc b/book/chapters/sample.adoc
@@ -287,6 +287,8 @@ digraph G {
 
 === Graphviz with svg
 
+indexterm:[Fibonacci]
+
 [graphviz, Recursive Fibonacci call tree with dp (sample), svg]
 ....
 graph G {
diff --git a/book/chapters/selection-sort.adoc b/book/chapters/selection-sort.adoc
@@ -38,3 +38,5 @@ One index is for the position in question (selection/left) and another one for f
 - Space Complexity: [big]#✅# <<Constant>> _O(1)_
 
 CAUTION: Selection sort is the worst compared <<Bubble Sort>> and <<Insertion Sort>>. The only advantage of selection sort is that it minimizes the number of swaps. In case, that swapping is expensive then it could make sense to use this one over the others.
+
+indexterm:[Runtime, Quadratic]
diff --git a/book/chapters/set.adoc b/book/chapters/set.adoc
@@ -211,6 +211,8 @@ rehash happens, it will take *O(n)* instead of *O(1)*. A `TreeSet` is always *O(
 |===
 {empty}* = Amortized run time. E.g. rehashing might affect run time to *O(n)*.
 
+indexterm:[Runtime, Linear]
+
 To recap, HashSet and TreeSet will keep data without duplicates. The
 difference besides runtime is that:
 
diff --git a/book/chapters/timsort.adoc b/book/chapters/timsort.adoc
@@ -1,7 +1,9 @@
-= tim Sort
+= Tim Sort
 
 tim sort is an efficient recursive sorting algorithm that uses "divide and conquer" paradigm to sort faster. It can be implemented in-place so it doesn't require additonal memory.
 
+indexterm:[Divide and Conquer]
+
 In practice timsort outperforms efficient sorting algorithms like <<Merge Sort>>. And, of course, It also outperforms simple sorting algorithms like <<Selection Sort>>, <<Insertion Sort>> and <<Bubble Sort>>.
 
 tim sort basically picks a "pivot" element (preferably random) and move all the elements that are smaller than the pivot to the right and the ones that are bigger to the left. It does this recursively until all the array is sorted.
diff --git a/book/chapters/tree--binary-search-tree.adoc b/book/chapters/tree--binary-search-tree.adoc
@@ -170,3 +170,6 @@ We can sum up the tree operations using Big O notation:
 | BST (**un**balanced) ^|- ^|O(n) ^|O(n) ^|O(n) ^|O(n)
 | BST (balanced) ^|- ^|O(log n) ^|O(log n) ^|O(log n) ^|O(n)
 |===
+
+indexterm:[Runtime, Linear]
+indexterm:[Runtime, Logarithmic]
diff --git a/book/chapters/tree.adoc b/book/chapters/tree.adoc
@@ -96,3 +96,5 @@ image:image35.png[image,width=258,height=169]
 ****
 Heap is better at finding max or min values in constant time *O(1)*, while a balanced BST is good a finding any element in *O(log n)*. Heaps are often used to implement priority queues while BST is used when you need every value sorted.
 ****
+
+indexterm:[Runtime, Logarithmic]
diff --git a/src/algorithms/sorting/merge-sort.js b/src/algorithms/sorting/merge-sort.js
@@ -1,13 +1,19 @@
 // tag::merge[]
 /**
  * Merge two arrays in ascending order
- * @param {Array} array1
- * @param {Array} array2
+ *
+ * @param {array} array1
+ * @param {array} array2
+ * @returns {array} merged arrays in asc order
+ *
+ * @example
+ *    merge([2,5,9], [1,6,7]) => [1, 2, 5, 6, 7, 9]
  */
 function merge(array1, array2 = []) {
   const mergedLength = array1.length + array2.length;
   const mergedArray = Array(mergedLength);
 
+  // merge elements on a and b in asc order. Run-time O(a + b)
   for (let index = 0, i1 = 0, i2 = 0;
     index < mergedLength; index += 1) { // <1>
     if (i2 >= array2.length ||
@@ -29,21 +35,25 @@ function merge(array1, array2 = []) {
  * Split array in half recursively until two or less elements are left.
  * Sort these two elements and combine them back using the merge function.
  * @param {Array} array
+ * @example
+ *    splitSort([3, 2, 1]) => [1, 2, 3]
+ *    splitSort([3]) => [3]
+ *    splitSort([3, 2]) => [2, 3]
  */
 function splitSort(array) {
   const size = array.length;
   // base case
   if (size < 2) {
     return array;
   } else if (size === 2) {
-    return array[0] < array[1] ? array : [array[1], array[0]]; // <2>
+    return array[0] < array[1] ? array : [array[1], array[0]]; // <1>
   }
 
   // recursive split in half and merge back
   const half = Math.ceil(size / 2);
   return merge( // <3>
-    splitSort(array.slice(0, half)), // <1>
-    splitSort(array.slice(half)), // <1>
+    splitSort(array.slice(0, half)), // <2>
+    splitSort(array.slice(half)), // <2>
   );
 }
 // end::splitSort[]

-Original file line number
+Diff line change
 - <>: [big]#✅# Yes, _O(n)_ when already sorted
 - Time Complexity: [big]#⛔️# <> _O(n^2^)_
 - Space Complexity: [big]#✅# <> _O(1)_
++
 +indexterm:[Runtime, Quadratic]