update indexes

Author: amejiarosario

book/chapters/array.adoc

@@ -1,5 +1,6 @@
 = Array
-
+(((Array)))
+(((Data Structures, Linear, Array)))
 Arrays are one of the most used data structures. You probably have used it a lot but are you aware of the runtimes of  `splice`, `shift`  and other operations? In this chapter, we are going deeper into the most common operations and their runtimes.
 
 == Array  Basics
@@ -184,4 +185,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]
+(((Linear)))
+(((Runtime, Linear)))

book/chapters/big-o-examples.adoc

@@ -23,7 +23,8 @@ image:image5.png[CPU time needed vs. Algorithm runtime as the input size increas
 The above chart shows how the running time of an algorithm is related to the amount of work the CPU has to perform. As you can see O(1) and O(log n) are very scalable. However, O(n^2^) and worst can make your computer run for years [big]#😵# on large datasets. We are going to give some examples so you can identify each one.
 
 == Constant
-
+(((Constant)))
+(((Runtime, Constant)))
 Represented as *O(1)*, it means that regardless of the input size the number of operations executed is always the same. Let’s see an example.
 
 [#constant-example]
 As you can see, in both examples (array and linked list) if the input is a collection of 10 elements or 10M it would take the same amount of time to execute. You can't get any more performance than this!
 
 == Logarithmic
-
+(((Logarithmic)))
+(((Runtime, Logarithmic)))
 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]
 
@@ -65,7 +67,8 @@ This binary search implementation is a recursive algorithm, which means that the
 Finding the runtime of recursive algorithms is not very obvious sometimes. It requires some tools like recursion trees or the https://adrianmejia.com/blog/2018/04/24/analysis-of-recursive-algorithms/[Master Theorem]. The `binarySearch` divides the input in half each time. As a rule of thumb, when you have an algorithm that divides the data in half on each call you are most likely in front of a logarithmic runtime: _O(log n)_.
 
 == Linear
-
+(((Linear)))
+(((Runtime, Linear)))
 Linear algorithms are one of the most common runtimes. It’s represented as *O(n)*. Usually, an algorithm has a linear running time when it iterates over all the elements in the input.
 
 [#linear-example]
@@ -90,7 +93,8 @@ As we learned before, the big O cares about the worst-case scenario, where we wo
 Space complexity is also *O(n)* since we are using an auxiliary data structure.  We have a map that in the worst case (no duplicates) it will hold every word.
 
 == Linearithmic
-
+(((Linearithmic)))
+(((Runtime, Linearithmic)))
 An algorithm with a linearithmic runtime is represented as _O(n log n)_. This one is important because it is the best runtime for sorting! Let’s see the merge-sort.
 
 [#linearithmic-example]
@@ -125,8 +129,8 @@ image:image11.png[Mergesort visualization,width=500,height=600]
 How do we obtain the running time of the merge sort algorithm? The mergesort divides the array in half each time in the split phase, _log n_, and the merge function join each splits, _n_. The total work we have *O(n log n)*. There more formal ways to reach to this runtime like using the https://adrianmejia.com/blog/2018/04/24/analysis-of-recursive-algorithms/[Master Method] and https://www.cs.cornell.edu/courses/cs3110/2012sp/lectures/lec20-master/lec20.html[recursion trees].
 
 == Quadratic
-
-indexterm:[Runtime, Quadratic]
+(((Quadratic)))
+(((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.
@@ -149,7 +153,8 @@ As you can see, we have two nested loops causing the running time to be quadrati
 Let’s say you want to find a duplicated middle name in a phone directory book of a city of ~1 million people. If you use this quadratic solution you would have to wait for ~12 days to get an answer [big]#🐢#; while if you use the <> you will get the answer in seconds! [big]#🚀#
 
 == Cubic
-
+(((Cubic)))
+(((Runtime, Cubic)))
 Cubic *O(n^3^)* and higher polynomial functions usually involve many nested loops. As an example of a cubic algorithm is a multi-variable equation solver (using brute force):
 
 [#cubic-example]
@@ -174,7 +179,8 @@ WARNING: This just an example, there are better ways to solve multi-variable equ
 As you can see three nested loops usually translates to O(n^3^). If you have a four variable equation and four nested loops it would be O(n^4^) and so on when we have a runtime in the form of _O(n^c^)_, where _c > 1_, we can refer as a *polynomial runtime*.
 
 == Exponential
-
+(((Exponential)))
+(((Runtime, Exponential)))
 Exponential runtimes, O(2^n^), means that every time the input grows by one the number of operations doubles. Exponential programs are only usable for a tiny number of elements (<100) otherwise it might not finish on your lifetime.  [big]#💀#
 
 Let’s do an example.
@@ -203,7 +209,8 @@ include::{codedir}/runtimes/07-sub-sets.js[tag=snippet]
 Every time the input grows by one the resulting array doubles. That’s why it has an *O(2^n^)*.
 
 == Factorial
-
+(((Factorial)))
+(((Runtime, Factorial)))
 Factorial runtime, O(n!), is not scalable at all. Even with input sizes of ~10 elements, it will take a couple of seconds to compute. It’s that slow! [big]*🍯🐝*
 
 .Factorial

book/chapters/bubble-sort.adoc

@@ -7,6 +7,8 @@ Bubble sort is a simple sorting algorithm that "bubbles up" the biggest values t
 It's also called _sinking sort_ because the most significant values "sink" to the right side of the array.
 This algorithm is adaptive, which means that if the array is already sorted, it will take only _O(n)_ to "sort".
 However, if the array is entirely out of order, it will require _O(n^2^)_ to sort.
+(((Quadratic)))
+(((Runtime, Quadratic)))
 
 == Bubble Sort Implementation
 

book/chapters/chapter3.adoc

@@ -11,20 +11,25 @@ include::tree.adoc[]
 
 
 // (g)
+<<<
 include::tree--binary-search-tree.adoc[]
 
+<<<
 include::tree--search.adoc[]
 
+<<<
 include::tree--self-balancing-rotations.adoc[]
 
 :leveloffset: +1
 
+<<<
 include::tree--avl.adoc[]
 
 :leveloffset: -1
 
 // (g)
 // include::map.adoc[]
+<<<
 include::map-intro.adoc[]
 
 :leveloffset: +1

book/chapters/divide-and-conquer--fibonacci.adoc

@@ -52,7 +52,8 @@ graph G {
 ....
 
 In the diagram, we see the two recursive calls needed to compute each number. So if we follow the _O(branches^depth^)_ we get O(2^n^). [big]#🐢#
-
+(((Exponential)))
+(((Runtime, Exponential)))
 NOTE: Fibonacci is not a perfect binary tree since some nodes only have one child instead of two. The exact runtime for recursive Fibonacci is _O(1.6^n^)_ (still exponential time complexity).
 
 Exponential time complexity is pretty bad. Can we do better?

book/chapters/dynamic-programming--fibonacci.adoc

@@ -23,7 +23,8 @@ graph G {
 ....
 
 This graph looks pretty linear now. It's runtime _O(n)_!
-indexterm:[Runtime, Linear]
+(((Linear)))
+(((Runtime, Linear)))
 
 (((Memoization)))
 TIP: Saving previous results for later is a technique called "memoization". This is very common to optimize recursive algorithms with overlapping subproblems. It can make exponential algorithms linear!

book/chapters/graph.adoc

@@ -1,5 +1,6 @@
 = Graph
-
+(((Graph)))
+(((Data Structures, Non-Linear, Graph)))
 Graphs are one of my favorite data structures.
 They have a lot of cool applications like optimizing routes, social network analysis to name a few. You are probably using apps that use graphs every day.
 First, let’s start with the basics.

book/chapters/insertion-sort.adoc

@@ -31,4 +31,6 @@ include::{codedir}/algorithms/sorting/insertion-sort.js[tag=sort, indent=0]
 - <>: [big]#✅# Yes
 - Time Complexity: [big]#⛔️# <> _O(n^2^)_
 - Space Complexity: [big]#✅# <> _O(1)_
-indexterm:[Runtime, Quadratic]
+
+(((Quadratic)))
+(((Runtime, Quadratic)))

book/chapters/linked-list.adoc

@@ -1,5 +1,7 @@
 = Linked List
-
+(((Linked List)))
+(((List)))
+(((Data Structures, Linear, Linked List)))
 A list (or Linked List) is a linear data structure where each node is linked to another one.
 
 Linked Lists can be:
@@ -248,8 +250,9 @@ So far, we have seen two liner data structures with different use cases. Here’
 | Linked List (singly) ^|O(n) ^|O(n) ^|O(1) ^|O(n) ^|O(1) ^|O(1) ^|O(n) ^|*O(n)* ^|O(n)
 | Linked List (doubly) ^|O(n) ^|O(n) ^|O(1) ^|O(n) ^|O(1) ^|O(1) ^|O(n) ^|*O(1)* ^|O(n)
 |===
+(((Linear)))
+(((Runtime, Linear)))
 
-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:

book/chapters/map-hashmap-vs-treemap.adoc

@@ -26,4 +26,7 @@ As we discussed so far, there are trade-off between the implementations
 |===
 {empty}* = Amortized run time. E.g. rehashing might affect run time to *O(n)*.
 
-indexterm:[Runtime, Logarithmic]
+(((Linear)))
+(((Runtime, Linear)))
+(((Logarithmic)))
+(((Runtime, Logarithmic)))