epub completed!!!!!

Author: amejiarosario

book-pro/A-time-complexity-cheatsheet.asc

@@ -12,13 +12,15 @@ include::content/part01/algorithms-analysis.asc[tag=table]
 
 === Linear Data Structures
 
-include::part02-linear-data-structures.asc[tag=table]
+// <<part02-linear-data-structures#linear-data-structures-table>>
+
+include::content/part02/array-vs-list-vs-queue-vs-stack.asc[tag=table]
 
 === Trees and Maps Data Structures
 
 This section covers Binary Search Tree (BST) time complexity (Big O).
 
-include::part03-graph-data-structures.asc[tag=table]
+include::content/part03/time-complexity-graph-data-structures.asc[tag=table]
 
 include::content/part03/graph.asc[tag=table]
 

book-pro/B-self-balancing-binary-search-trees.asc

@@ -1,4 +1,5 @@
 [appendix]
+[[b-self-balancing-binary-search-trees]]
 == Self-balancing Binary Search Trees
 
 Binary Search Trees (BST) are an excellent data structure to find elements very fast _O(log n)_.
@@ -27,6 +28,7 @@ As you might notice, we balanced the tree in the example by doing a rotation.
 To be more specific we rotated node `1` to the left to balance the tree.
 Let's examine all the possible rotation we can do to balance a tree.
 
+[[tree-rotations]]
 === Tree Rotations
 (((Tree Rotations)))
 We can do single rotations left and right and also we can do double rotations.

book-pro/C-AVL-tree.asc

@@ -1,4 +1,5 @@
 [appendix]
+[[c-avl-tree]]
 == AVL Tree
 (((AVL Tree)))
 (((Tree, AVL)))
@@ -59,4 +60,4 @@ include::../src/data-structures/trees/avl-tree.js[tag=balance]
 The first thing we do is to see if one subtree is longer than the other.
 If so, then we check the children balance to determine if need a single or double rotation and in which direction.
 
-You can review <<Tree Rotations>> in case you want a refresher.
+You can review <<b-self-balancing-binary-search-trees#tree-rotations>> in case you want a refresher.

book-pro/config/Rakefile

@@ -32,18 +32,18 @@ namespace :book do
       puts `#{cmd}`
       puts "\t-- HTML output at progit.html"
 
-      puts "\r\nConverting to PDF... (this one takes a while)"
-      cmd = "bundle exec asciidoctor-pdf #{require} #{require_pdf} #{params} #{input} 2>&1"
-      puts cmd
-      puts `#{cmd}`
-      puts " -- PDF output at progit.pdf"
-
-      # puts "\r\n>> Converting to EPub..."
-      # # cmd = "bundle exec asciidoctor-epub3 #{require} -a ebook-validate #{params} #{input} 2>&1"
-      # cmd = "bundle exec asciidoctor-epub3 -a ebook-validate #{require} #{params} #{input} 2>&1"
+      # puts "\r\nConverting to PDF... (this one takes a while)"
+      # cmd = "bundle exec asciidoctor-pdf #{require} #{require_pdf} #{params} #{input} 2>&1"
       # puts cmd
       # puts `#{cmd}`
-      # puts "\t-- Epub output at progit.epub"
+      # puts " -- PDF output at progit.pdf"
+
+      puts "\r\n>> Converting to EPub..."
+      # cmd = "bundle exec asciidoctor-epub3 #{require} -a ebook-validate #{params} #{input} 2>&1"
+      cmd = "bundle exec asciidoctor-epub3 #{require} #{params} #{input} 2>&1"
+      puts cmd
+      puts `#{cmd}`
+      puts "\t-- Epub output at progit.epub"
 
       # puts "\r\nConverting to Mobi (kf8)..."
       # puts `bundle exec asciidoctor-epub3 #{params} -a ebook-format=kf8 #{input} 2>&1`

book-pro/content/colophon.asc

@@ -1,5 +1,5 @@
 [colophon#colophon%nonfacing]
-== {doctitle}
+== Data Structures & Algorithms in JavaScript
 
 Copyright © {docyear} Adrian Mejia
 

book-pro/content/part01/algorithms-analysis.asc

@@ -60,27 +60,15 @@ 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 |∞ |∞
 |=============================================================================================
 
-Most algorithms are affected by the size of the input (`n`). Let's say you need to arrange numbers in ascending order. Sorting ten items will naturally take less time than sorting out 2 million. But, how much longer? As the input size grow, some algorithms take proportionally more time, we classify them as <<linear, linear>> runtime [or `O(n)`]. Others might take power two longer; we call them <<quadratic, quadratic>> running time [or `O(n^2^)`].
+Most algorithms are affected by the size of the input (`n`). Let's say you need to arrange numbers in ascending order. Sorting ten items will naturally take less time than sorting out 2 million. But, how much longer? As the input size grow, some algorithms take proportionally more time, we classify them as <<part01-algorithms-analysis#linear, linear>> runtime [or `O(n)`]. Others might take power two longer; we call them <<part01-algorithms-analysis#quadratic, quadratic>> running time [or `O(n^2^)`].
 
-<<part04#merge-sort>>
-
-// <<part04#>>
-// <<part04#_algorithms_toolbox>>
-// <<part04#algorithms_toolbox>>
-
-// <<part04-algorithmic-toolbox#_algorithms_toolbox>>
-// <<part04-algorithmic-toolbox#algorithms_toolbox>>
-
-// <<ch04-git-on-the-server#_getting_git_on_a_server>>
-
-
-From another perspective, if you keep the input size the same and run different algorithms implementations, you would notice the difference between an efficient algorithm and a slow one. For example, a good sorting algorithm is <<chapter-4#merge-sort>>, and an inefficient algorithm for large inputs is <<chapter-4#selection-sort>>.
+From another perspective, if you keep the input size the same and run different algorithms implementations, you would notice the difference between an efficient algorithm and a slow one. For example, a good sorting algorithm is <<part04-algorithmic-toolbox#merge-sort>>, and an inefficient algorithm for large inputs is <<part04-algorithmic-toolbox#selection-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 solving the same problem with equal data and hardware; and yet, there's a big difference in time!
 
 After completing this book, you are going to _think algorithmically_.
 You will be able to scale your programs while you are designing them.
-Find bottlenecks of existing software and have an <<Algorithmic Toolbox>> to optimize algorithms and make them faster without having to pay more for cloud computing (e.g., AWS EC2 instances). [big]#💸#
+Find bottlenecks of existing software and have an <<part04-algorithmic-toolbox#algorithms-toolbox>> to optimize algorithms and make them faster without having to pay more for cloud computing (e.g., AWS EC2 instances). [big]#💸#
 
 <<<
 ==== Increasing your code performance

book-pro/content/part01/big-o-examples.asc

@@ -21,6 +21,7 @@ image:images/image5.png[CPU time needed vs. Algorithm runtime as the input size
 
 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
 (((Constant)))
 (((Runtime, Constant)))
@@ -39,17 +40,18 @@ Let's implement a function that finds out if an array is empty or not.
 include::{codedir}/runtimes/01-is-empty.js[tag=isEmpty]
 ----
 
-Another more real life example is adding an element to the begining of a <<Linked List>>. You can check out the implementation <<linked-list-inserting-beginning, here>>.
+Another more real life example is adding an element to the begining of a <<part02-linear-data-structures#linked-list>>. You can check out the implementation <<part02-linear-data-structures#linked-list-inserting-beginning, here>>.
 
 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
 (((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]
 
-[#logarithmic-example]
+[[logarithmic-example]]
 ===== Searching on a sorted array
 
 The binary search only works for sorted lists. It starts searching for an element on the middle of the array and then it moves to the right or left depending if the value you are looking for is bigger or smaller.
@@ -71,7 +73,7 @@ Finding the runtime of recursive algorithms is not very obvious sometimes. It re
 (((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]
+[[linear-example]]
 ===== Finding duplicates in an array using a map
 
 Let’s say that we want to find duplicate elements in an array. What’s the first implementation that comes to mind? Check out this implementation:
@@ -92,12 +94,13 @@ 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
 (((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]
+[[linearithmic-example]]
 ===== Sorting elements in an array
 
 The ((Merge Sort)), like its name indicates, has two functions merge and sort. Let’s start with the sort function:
@@ -136,10 +139,10 @@ Running times that are quadratic, O(n^2^), are the ones to watch out for. They u
 
 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.
 
-[#quadratic-example]
+[[quadratic-example]]
 ===== Finding duplicates in an array (naïve approach)
 
-If you remember we have solved this problem more efficiently on the <<Linear, Linear>> section. We solved this problem before using an _O(n)_, let’s solve it this time with an _O(n^2^)_:
+If you remember we have solved this problem more efficiently on the <<part01-algorithms-analysis#linear, Linear>> section. We solved this problem before using an _O(n)_, let’s solve it this time with an _O(n^2^)_:
 
 // image:images/image12.png[image,width=527,height=389]
 
@@ -151,14 +154,15 @@ include::{codedir}/runtimes/05-has-duplicates-naive.js[tag=hasDuplicates]
 
 As you can see, we have two nested loops causing the running time to be quadratic. How much different is a linear vs. quadratic algorithm?
 
-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 <<Linear, linear solution>> you will get the answer in seconds! [big]#🚀#
+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 <<part01-algorithms-analysis#linear, linear solution>> you will get the answer in seconds! [big]#🚀#
 
+[[cubic]]
 ==== 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]
+[[cubic-example]]
 ===== Solving a multi-variable equation
 
 Let’s say we want to find the solution for this multi-variable equation:
@@ -179,14 +183,15 @@ 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
 (((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.
 
-[#exponential-example]
+[[exponential-example]]
 ===== Finding subsets of a set
 
 Finding all distinct subsets of a given set can be implemented as follows:
@@ -209,6 +214,7 @@ 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
 (((Factorial)))
 (((Runtime, Factorial)))
@@ -225,7 +231,7 @@ A factorial is the multiplication of all the numbers less than itself down to 1.
 - 11! = 39,916,800
 ****
 
-[#factorial-example]
+[[factorial-example]]
 ===== Getting all permutations of a word
 (((Permutations)))
 (((Words permutations)))
@@ -257,35 +263,35 @@ We went through 8 of the most common time complexities and provided examples for
 |Example(s)
 
 |O(1)
-|<<Constant>>
-|<<constant-example>>
+|<<part01-algorithms-analysis#constant>>
+|<<part01-algorithms-analysis#constant-example>>
 
 |O(log n)
-|<<Logarithmic>>
-|<<logarithmic-example>>
+|<<part01-algorithms-analysis#logarithmic>>
+|<<part01-algorithms-analysis#logarithmic-example>>
 
 |O(n)
-|<<Linear>>
-|<<linear-example>>
+|<<part01-algorithms-analysis#linear>>
+|<<part01-algorithms-analysis#linear-example>>
 
 |O(n log n)
-|<<Linearithmic>>
-|<<linearithmic-example>>
+|<<part01-algorithms-analysis#linearithmic>>
+|<<part01-algorithms-analysis#linearithmic-example>>
 
 |O(n^2^)
-|<<Quadratic>>
-|<<quadratic-example>>
+|<<part01-algorithms-analysis#quadratic>>
+|<<part01-algorithms-analysis#quadratic-example>>
 
 |O(n^3^)
-|<<Cubic>>
-|<<cubic-example>>
+|<<part01-algorithms-analysis#cubic>>
+|<<part01-algorithms-analysis#cubic-example>>
 
 |O(2^n^)
-|<<Exponential>>
-|<<exponential-example>>
+|<<part01-algorithms-analysis#exponential>>
+|<<part01-algorithms-analysis#exponential-example>>
 
 |O(n!)
-|<<Factorial>>
-|<<factorial-example>>
+|<<part01-algorithms-analysis#factorial>>
+|<<part01-algorithms-analysis#factorial-example>>
 |===
 // end::table[]

book-pro/content/part02/array-vs-list-vs-queue-vs-stack.asc

@@ -0,0 +1,36 @@
+=== Array vs. Linked List & Queue vs. Stack
+
+In this part of the book, we explored the most used linear data structures such as Arrays, Linked Lists, Stacks and Queues. We implemented them and discussed the runtime of their operations.
+
+.Use Arrays when…
+* You need to access data in random order fast (using an index).
+* Your data is multi-dimensional (e.g., matrix, tensor).
+
+.Use Linked Lists when:
+* You will access your data sequentially.
+* You want to save memory and only allocate memory as you need it.
+* You want constant time to remove/add from extremes of the list.
+
+.Use a Queue when:
+* You need to access your data in a first-come, first served basis (FIFO).
+* You need to implement a <<part03-graph-data-structures#bfs-tree, Breadth-First Search>>
+
+.Use a Stack when:
+* You need to access your data as last-in, first-out (LIFO).
+* You need to implement a <<part03-graph-data-structures#dfs-tree, Depth-First Search>>
+(((Tables, Linear DS, Array/Lists/Stack/Queue complexities)))
+
+[[linear-data-structures-table]]
+// tag::table[]
+.Time/Space Complexity of Linear Data Structures (Array, LinkedList, Stack & Queues)
+|===
+.2+.^s| Data Structure 2+^s| Searching By 3+^s| Inserting at the 3+^s| Deleting from .2+.^s| Space
+^|_Index/Key_ ^|_Value_ ^|_beginning_ ^|_middle_ ^|_end_ ^|_beginning_ ^|_middle_ ^|_end_
+| <<part02-linear-data-structures#array>> ^|O(1) ^|O(n) ^|O(n) ^|O(n) ^|O(1) ^|O(n) ^|O(n) ^|O(1) ^|O(n)
+| <<part02-linear-data-structures#singly-linked-list>> ^|O(n) ^|O(n) ^|O(1) ^|O(n) ^|O(1) ^|O(1) ^|O(n) ^|*O(n)* ^|O(n)
+| <<part02-linear-data-structures#doubly-linked-list>> ^|O(n) ^|O(n) ^|O(1) ^|O(n) ^|O(1) ^|O(1) ^|O(n) ^|*O(1)* ^|O(n)
+| <<part02-linear-data-structures#stack>> ^|- ^|- ^|- ^|- ^|O(1) ^|- ^|- ^|O(1) ^|O(n)
+| Queue (w/array) ^|- ^|- ^|- ^|- ^|*O(n)* ^|- ^|- ^|O(1) ^|O(n)
+| <<part02-linear-data-structures#queue>> (w/list) ^|- ^|- ^|- ^|- ^|O(1) ^|- ^|- ^|O(1) ^|O(n)
+|===
+// end::table[]

book-pro/content/part02/array.asc

@@ -3,6 +3,7 @@
 // :codedir: ../../src
 // endif::[]
 
+[[array]]
 === Array
 (((Array)))
 (((Data Structures, Linear, Array)))
@@ -119,6 +120,7 @@ The `push()` method adds one or more elements to the end of an array and returns
 Runtime: O(1).
 ****
 
+[[array-search-by-value]]
 ==== Searching by value and index
 
 Searching by index is very easy using the `[]` operator:

book-pro/content/part02/linked-list.asc

@@ -2,7 +2,7 @@
 // :imagesdir: ../images
 // :codedir: ../../src
 // endif::[]
-
+[[linked-list]]
 === Linked List
 (((Linked List)))
 (((List)))
@@ -14,7 +14,7 @@ A list (or Linked List) is a linear data structure where each node is "linked" t
 - Doubly: every node has a reference to the next and previous object
 - Circular: the last element points to the first one.
 
-
+[[singly-linked-list]]
 ==== Singly Linked List
 
 Each element or node is *connected* to the next one by a reference. When a node only has one connection it's called *singly linked list*:
@@ -24,6 +24,7 @@ image:images/image19.png[image,width=498,height=97]
 
 Usually, a Linked List is referenced by the first element in called *head* (or *root* node). For instance, if you want to get the `cat` element from the example above, then the only way to get there is using the `next` field on the head node. You would get `art` first, then use the next field recursively until you eventually get the `cat` element.
 
+[[doubly-linked-list]]
 ==== Doubly Linked List
 
 When each node has a connection to the `next` item and also the `previous` one, then we have a *doubly linked list*.
@@ -123,7 +124,7 @@ image:images/image23.png[image,width=498,height=217]
 
 To insert at the beginning, we create a new node with the next reference to the current first node. Then we make first the new node. In code, it would look something like this:
 
-[#linked-list-inserting-beginning]
+[[linked-list-inserting-beginning]]
 
 .Add item to the beginning of a Linked List
 [source, javascript]
@@ -278,9 +279,9 @@ Use arrays when:
 
 Use a doubly linked list when:
 
-* You want to access elements in a *sequential* manner only like <<Stack>> or <<Queue>>.
+* You want to access elements in a *sequential* manner only like <<part02-linear-data-structures#stack>> or <<part02-linear-data-structures#queue>>.
 
 * You want to insert elements at the start and end of the list. The linked list has O(1) while array has O(n).
 * You want to save some memory when dealing with possibly large data sets. Arrays pre-allocate a large chunk of contiguous memory on initialization. Lists are more “grow as you go”.
 
-For the next two linear data structures <<Stack>> and <<Queue>>, we are going to use a doubly linked list to implement them. We could use an array as well, but since inserting/deleting from the start perform better on linked-list, we are going use that.
+For the next two linear data structures <<part02-linear-data-structures#stack>> and <<part02-linear-data-structures#queue>>, we are going to use a doubly linked list to implement them. We could use an array as well, but since inserting/deleting from the start perform better on linked-list, we are going use that.

book-pro/content/part02/queue.asc

@@ -3,6 +3,7 @@
 // :codedir: ../../src
 // endif::[]
 
+[[queue]]
 === Queue
 (((Queue)))
 (((Data Structures, Linear, Queue)))

book-pro/content/part02/stack.asc

@@ -3,6 +3,7 @@
 // :codedir: ../../src
 // endif::[]
 
+[[stack]]
 === Stack
 (((Stack)))
 (((Data Structures, Linear, Stack)))
@@ -83,4 +84,4 @@ Implementing the stack with an array and linked list would lead to the same time
 |===
 // end::table[]
 
-It's not very common to search for values on a stack (other Data Structures are better suited for this). Stacks especially useful for implementing <<Depth-First Search for Binary Tree, Depth-First Search>>.
+It's not very common to search for values on a stack (other Data Structures are better suited for this). Stacks especially useful for implementing <<part03-graph-data-structures#dfs-tree, Depth-First Search>>.

book-pro/content/part03/graph-search.asc

@@ -76,9 +76,9 @@ DFS and BFS can implementation can be almost identical; the difference is the un
 include::{codedir}/data-structures/graphs/graph.js[tag=graphSearch,indent=0]
 ----
 
-Using an <<Stack>> (LIFO) for DFS will make use keep visiting the last node children while having a <<Queue>> (FIFO) will allow to visit adjacent nodes first and "queue" their children for later visiting.
+Using an <<part02-linear-data-structures#stack>> (LIFO) for DFS will make use keep visiting the last node children while having a <<part02-linear-data-structures#queue>> (FIFO) will allow to visit adjacent nodes first and "queue" their children for later visiting.
 
-TIP: you can also implement the DFS as a recursive function, similar to what we did in the <<Depth-First Search for Binary Tree, DFS for trees>>.
+TIP: you can also implement the DFS as a recursive function, similar to what we did in the <<part03-graph-data-structures#dfs-tree, DFS for trees>>.
 
 You might wonder what the difference between search algorithms in a tree and a graph is? Check out the next section.
 

book-pro/content/part03/graph.asc

@@ -3,6 +3,7 @@
 // :codedir: ../../src
 // endif::[]
 
+[[graph]]
 === Graph
 (((Graph)))
 (((Data Structures, Non-Linear, Graph)))
@@ -199,7 +200,7 @@ include::{codedir}/data-structures/graphs/graph.js[tag=addVertex, indent=0]
 
 If the node doesn't exist, then we create the new node and add it to a `HashMap`.
 
-TIP: <<Map>> stores key/pair value very efficiently. Lookup is `O(1)`.
+TIP: <<part03-graph-data-structures#map>> stores key/pair value very efficiently. Lookup is `O(1)`.
 
 The `key` is the node's value, while the `value` is the newly created node.
 

book-pro/content/part03/hashmap.asc

@@ -3,6 +3,7 @@
 // :codedir: ../../src
 // endif::[]
 
+[[hashmap]]
 ==== HashMap
 (((HashMap)))
 (((HashTable)))
@@ -239,7 +240,7 @@ include::{codedir}/data-structures/maps/hash-maps/hash-map.js[tag=getEntry, inde
 ----
 <1> Convert key to an array index.
 <2> If the bucket is empty create a new linked list
-<3> Use Linked list's <<Searching by value>> method to find value on the bucket.
+<3> Use Linked list's <<part02-linear-data-structures#array-search-by-value>> method to find value on the bucket.
 <4> Return `bucket` and `entry` if found.
 
 With the help of the `getEntry` method, we can do the `HashMap.get` and `HashMap.has` methods:

book-pro/content/part03/map.asc

@@ -2,7 +2,7 @@
 // :imagesdir: ../images
 // :codedir: ../../src
 // endif::[]
-
+[[map]]
 === Map
 (((Map)))
 (((Data Structures, Non-Linear, Map)))
@@ -23,7 +23,7 @@ In short, you set `key`/`value` pair and then you can get the `value` using the
 The attractive part of Maps is that they are very performant usually *O(1)* or *O(log n)* depending on the implementation. We can implement the maps using two different underlying data structures:
 
 * *HashMap*: it’s a map implementation using an *array* and a *hash function*. The job of the hash function is to convert the `key` into an index that maps to the `value`. Optimized HashMap can have an average runtime of *O(1)*.
-* *TreeMap*: it’s a map implementation that uses a self-balanced Binary Search Tree (like <<AVL Tree>>). The BST nodes store the key, and the value and nodes are sorted by key guaranteeing an *O(log n)* look up.
+* *TreeMap*: it’s a map implementation that uses a self-balanced Binary Search Tree (like <<c-avl-tree#>>). The BST nodes store the key, and the value and nodes are sorted by key guaranteeing an *O(log n)* look up.
 
 <<<
 include::hashmap.asc[]
@@ -41,7 +41,7 @@ include::treemap.asc[]
 
 .When to use a TreeMap vs. HashMap?
 * `HashMap` is more time-efficient. A `TreeMap` is more space-efficient.
-* `TreeMap` search complexity is *O(log n)*, while an optimized `HashMap` is *O(1)* on average. 
+* `TreeMap` search complexity is *O(log n)*, while an optimized `HashMap` is *O(1)* on average.
 * `HashMap`’s keys are in insertion order (or random depending in the implementation). `TreeMap`’s keys are always sorted.
 * `TreeMap` offers some statistical data for free such as: get minimum, get maximum, median, find ranges of keys. `HashMap` doesn’t.
 * `TreeMap` has a guarantee always an *O(log n)*, while `HashMap`s has an amortized time of *O(1)* but in the rare case of a rehash, it would take an *O(n)*.

book-pro/content/part03/set.asc

@@ -3,6 +3,7 @@
 // :codedir: ../../src
 // endif::[]
 
+[[set]]
 === Set
 (((Set)))
 (((Data Structures, Non-Linear, Set)))
@@ -37,7 +38,7 @@ TIP: A hint... it should perform all operations in *O(1)** or at most *O(log n)*
 
 If we use a `map`, we can accomplish this. However, maps use a key/value pair. If we only use the keys, we can avoid duplicates. Since in a `map` you can only have one key at a time.
 
-As you might remember from the <<Map>> chapter, there are two ways of implementing a `map` and both can be used to create a `set`.  Let's explore the difference between the two implementations are.
+As you might remember from the <<part03-graph-data-structures#map>> chapter, there are two ways of implementing a `map` and both can be used to create a `set`.  Let's explore the difference between the two implementations are.
 
 ==== HashSet vs TreeSet
 
@@ -50,6 +51,7 @@ We can implement a `map` using a *balanced BST* and using a *hash function*. If
 
 Let’s implement both!
 
+[[tree-set]]
 ==== TreeSet
 (((TreeSet)))
 (((Data Structures, Non-Linear, TreeSet)))
@@ -151,6 +153,7 @@ Check out our https://github.com/amejiarosario/dsa.js/blob/f69b744a1bddd3d99243c
 
 Let’s now, implement a `HashSet`.
 
+[[hashset]]
 ==== HashSet
 (((HashSet)))
 (((Data Structures, Non-Linear, HashSet)))

book-pro/content/part03/time-complexity-graph-data-structures.asc

@@ -0,0 +1,20 @@
+=== Summary
+
+In this section, we learned about Graphs applications, properties and how we can create them. We mention that you can represent a graph as a matrix or as a list of adjacencies. We went for implementing the later since it's more space efficient. We cover the basic graph operations like adding and removing nodes and edges.  In the algorithms section, we are going to cover searching values in the graph.
+(((Tables, Non-Linear DS, BST/Maps/Sets Complexities)))
+
+// tag::table[]
+.Time and Space Complexity for Graph-based Data Structures
+|===
+.2+.^s| Data Structure 2+^s| Searching By .2+^.^s| Insert .2+^.^s| Delete .2+^.^s| Space Complexity
+^|_Index/Key_ ^|_Value_
+| <<part03-graph-data-structures#bst, BST (unbalanced)>> ^|- ^|O(n) ^|O(n) ^|O(n) ^|O(n)
+| <<b-self-balancing-binary-search-trees#, BST (balanced)>> ^|- ^|O(log n) ^|O(log n) ^|O(log n) ^|O(n)
+| Hash Map (naïve) ^|O(n) ^|O(n) ^|O(n) ^|O(n) ^|O(n)
+| <<part03-graph-data-structures#hashmap>> (optimized) ^|O(1)* ^|O(n) ^|O(1)* ^|O(1)* ^|O(1)*
+| <<part03-graph-data-structures#treemap>> (Red-Black Tree) ^|O(log n) ^|O(n) ^|O(log n) ^|O(log n) ^|O(log n)
+| <<part03-graph-data-structures#hashset>> ^|- ^|O(n) ^|O(1)* ^|O(1)* ^|O(1)*
+| <<part03-graph-data-structures#tree-set>> ^|- ^|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)*.
+// end::table[]

book-pro/content/part03/tree-intro.asc

@@ -3,6 +3,7 @@
 // :codedir: ../../src
 // endif::[]
 
+[[tree]]
 === Tree
 (((Tree)))
 (((Data Structures, Non-Linear, Tree)))
@@ -15,7 +16,7 @@ As you can see in the picture above, this data structure resembles an inverted t
 
 ==== Implementing a Tree
 
-Implementing a tree is not too hard. It’s similar to a <<Linked List>>. The main difference is that instead of having a `next` and `previous` links, we have an infinite number of linked nodes (children/descendants).
+Implementing a tree is not too hard. It’s similar to a <<part02-linear-data-structures#linked-list>>. The main difference is that instead of having a `next` and `previous` links, we have an infinite number of linked nodes (children/descendants).
 
 .Tree's node constructor
 [source, javascript]
@@ -26,9 +27,9 @@ include::{codedir}/data-structures/trees/tree-node.js[tag=snippet]
 Simple! Right? But there are some constraints that you have to keep at all times.
 
 .Tree data structures constraints
-1. *Loops*: You have to be careful *not* to make a circular loop. Otherwise, this wouldn’t be a tree anymore but a <<Graph, graph data structure>>! E.g., Node A has B as a child, then Node B list Node A as its descendant forming a loop. ‍️
-2.  *Parents*: A node with more than two parents. Again, if that happens is no longer a tree but a <<Graph, graph>>.
-3.  *Root*: a tree must have only one root. Two non-connected parts are not a tree. <<Graph>> can have non-connected portions and doesn’t have root.
+1. *Loops*: You have to be careful *not* to make a circular loop. Otherwise, this wouldn’t be a tree anymore but a <<part03-graph-data-structures#graph, graph data structure>>! E.g., Node A has B as a child, then Node B list Node A as its descendant forming a loop. ‍️
+2.  *Parents*: A node with more than two parents. Again, if that happens is no longer a tree but a <<part03-graph-data-structures#graph>>.
+3.  *Root*: a tree must have only one root. Two non-connected parts are not a tree. <<part03-graph-data-structures#graph>> can have non-connected portions and doesn’t have root.
 
 ==== Basic concepts
 
@@ -66,12 +67,12 @@ image:images/image32.png[image,width=321,height=193]
 Binary trees are one of the most used kinds of tree, and they are used to build other data structures.
 
 .Binary Tree Applications
-- <<Map>>
-- <<Set>>
+- <<part03-graph-data-structures#map>>
+- <<part03-graph-data-structures#set>>
 - Priority Queues
-- <<Binary Search Tree (BST)>>
-
+- <<part03-graph-data-structures#bst>>
 
+[[bst]]
 ===== Binary Search Tree (BST)
 (((Binary Search Tree)))
 (((Data Structures, Non-Linear, Binary Search Tree)))

book-pro/content/part03/tree-search-traversal.asc

@@ -29,7 +29,7 @@ Why do we care? Well, there are specific problems that you can solve more optima
 
 Let's cover the Breadth-first search (BFS) and Depth-first search (DFS).
 
-[Breadth First Search]
+[[bfs-tree]]
 ==== Breadth-First Search for Binary Tree
 (((BFS)))
 (((Breadth-First Search)))
@@ -43,7 +43,7 @@ Let's how can we implement it!
 include::{codedir}/data-structures/trees/binary-search-tree.js[tag=bfs,indent=0]
 ----
 
-As you see, the BFS uses a <<Queue>> data structure. We enqueue all the children of the current node and then dequeue them as we visit them.
+As you see, the BFS uses a <<part02-linear-data-structures#queue>> data structure. We enqueue all the children of the current node and then dequeue them as we visit them.
 
 Note the asterisk (`*`) in front of the function means that this function is a generator that yields values.
 (((JavaScript Notes, Generators)))
@@ -83,7 +83,7 @@ console.log(Array.from(dummyIdMaker())); // [0, 1, 2]
 
 ****
 
-
+[[dfs-tree]]
 ==== Depth-First Search for Binary Tree
 (((DFS)))
 (((Depth-First Search)))
@@ -96,8 +96,8 @@ Depth-First search goes deep (depth) before going wide. It means that starting f
 include::{codedir}/data-structures/trees/binary-search-tree.js[tag=dfs,indent=0]
 ----
 
-This is an iterative implementation of a DFS using an <<Stack>>.
-It's almost identical to the BFS, but instead of using a <<Queue>> we use a Stack.
+This is an iterative implementation of a DFS using an <<part02-linear-data-structures#stack>>.
+It's almost identical to the BFS, but instead of using a <<part02-linear-data-structures#queue>> we use a Stack.
 We can also implement it as recursive functions are we are going to see in the <<Binary Tree Traversal>> section.
 
 ==== Depth-First Search vs. Breadth-First Search

book-pro/content/part03/treemap.asc

@@ -3,6 +3,7 @@
 // :codedir: ../../src
 // endif::[]
 
+[[treemap]]
 ==== TreeMap
 (((TreeMap)))
 (((Data Structures, Non-Linear, TreeMap)))

book-pro/content/part04/algorithmic-toolbox.asc

@@ -1,4 +1,4 @@
-[[_algorithms_toolbox]]
+[[algorithms-toolbox]]
 === Algorithmic Toolbox
 
 Have you ever given a programming problem and freeze without knowing where to start?
@@ -18,7 +18,7 @@ TIP: TL;DR: Don't start coding right away. First, solve the problem, then write
 .. If anything else fails, how would you solve it the dumbest way possible (brute force). We can optimize it later.
 . *Test* your algorithm idea with multiple examples
 . *Optimize* the solution –Only optimize when you have something working don't try to do both at the same time!
-.. Can you trade-off space for speed? Use a <<HashMap>> to speed up results!
+.. Can you trade-off space for speed? Use a <<part03-graph-data-structures#hashmap>> to speed up results!
 .. Do you have a bunch of recursive and overlapping problems? Try <<Dynamic Programming>>.
 .. Re-read requirements and see if you can take advantage of anything. E.g. is the array sorted?
 . *Write Code*, yes, now you can code.

book-pro/content/part04/backtracking.asc

@@ -10,7 +10,7 @@ it stops and steps back (backtracks) to try another alternative.
 Some examples that use backtracking is a solving Sudoku/crosswords puzzle, and graph operations.
 
 ifndef::backend-pdf[]
-image:Sudoku_solved_by_bactracking.gif[]
+image:images/Sudoku_solved_by_bactracking.gif[]
 endif::backend-pdf[]
 
 Listing all possible solutions might sound like a brute force.
@@ -58,7 +58,7 @@ For instace, if you are given the word `art` these are the possible permutations
 
 Now, let's implement the program to generate all permutations of a word.
 
-NOTE: We already solved this problem using an <<Getting all permutations of a word, iterative program>>, now let's do it using backtracking.
+NOTE: We already solved this problem using an <<part01-algorithms-analysis#factorial-example, iterative program>>, now let's do it using backtracking.
 
 .Word permutations using backtracking
 [source, javascript]

book-pro/content/part04/bubble-sort.asc

@@ -66,15 +66,15 @@ console.log(b); //️↪️ 1
 Without the destructuring assignment, swapping two values requires a temporary variable.
 ****
 
-Bubble sort has a <<Quadratic>> running time, as you might infer from the nested for-loop.
+Bubble sort has a <<part01-algorithms-analysis#quadratic>> running time, as you might infer from the nested for-loop.
 
 ===== Bubble Sort Properties
 
 - <<Stable>>: [big]#✅# Yes
 - <<In-place>>: [big]#✅# Yes
 - <<Online>>: [big]#✅# Yes
 - <<Adaptive>>: [big]#✅# Yes, _O(n)_ when already sorted
-- Time Complexity: [big]#⛔️# <<Quadratic>> _O(n^2^)_
-- Space Complexity: [big]#✅# <<Constant>> _O(1)_
+- Time Complexity: [big]#⛔️# <<part01-algorithms-analysis#quadratic>> _O(n^2^)_
+- Space Complexity: [big]#✅# <<part01-algorithms-analysis#constant>> _O(1)_
 
 indexterm:[Runtime, Quadratic]

book-pro/content/part04/divide-and-conquer.asc

@@ -8,10 +8,10 @@ It splits the input into manageable parts recursively and finally joins solved p
 We have already implemented some algorithms using the divide and conquer technique.
 
 .Examples of divide and conquer algorithms:
-- <<Merge Sort>>: *divides* the input into pairs, sort them, and them *join* all the pieces in ascending order.
-- <<Quicksort>>: *splits* the data by a random number called "pivot", then move everything smaller than the pivot to the left and anything more significant to the right. Repeat the process on the left and right side. Note: since this works in place doesn't need a "join" part.
-- <<logarithmic-example, Binary Search>>: find a value in a sorted collection by *splitting* the data in half until it sees the value.
-- <<Getting all permutations of a word, Permutations>>: *Take out* the first element from the input and solve permutation for the remainder of the data recursively, then *join* results and append the items that were taken out.
+- <<part04-algorithmic-toolbox#merge-sort>>: *divides* the input into pairs, sort them, and them *join* all the pieces in ascending order.
+- <<part04-algorithmic-toolbox#quicksort>>: *splits* the data by a random number called "pivot", then move everything smaller than the pivot to the left and anything more significant to the right. Repeat the process on the left and right side. Note: since this works in place doesn't need a "join" part.
+- <<part01-algorithms-analysis#logarithmic-example, Binary Search>>: find a value in a sorted collection by *splitting* the data in half until it sees the value.
+- <<part01-algorithms-analysis#factorial-example, Permutations>>: *Take out* the first element from the input and solve permutation for the remainder of the data recursively, then *join* results and append the items that were taken out.
 
 .In general, the divide and conquer algorithms have the following pattern:
 1. *Divide* data into subproblems.

book-pro/content/part04/greedy-algorithms.asc

@@ -34,8 +34,8 @@ This algorithm only gives one shot at finding the solution and never goes back t
 Don't get the wrong idea; some greedy algorithms work very well if they are designed correctly.
 
 .Some examples of greedy algorithms that works well:
-- <<Selection Sort>>: we select the best (minimum value) remove it from the input and then select the next minimum until everything is processed.
-- <<Merge Sort>>: the "merge" uses a greedy algorithm, where it combines two sorted arrays by looking at their current values and choosing the best (minimum) at every time.
+- <<part04-algorithmic-toolbox#selection-sort>>: we select the best (minimum value) remove it from the input and then select the next minimum until everything is processed.
+- <<part04-algorithmic-toolbox#merge-sort>>: the "merge" uses a greedy algorithm, where it combines two sorted arrays by looking at their current values and choosing the best (minimum) at every time.
 indexterm:[Merge Sort]
 
 

book-pro/content/part04/insertion-sort.asc

@@ -1,3 +1,4 @@
+[[insertion-sort]]
 ==== Insertion Sort
 
 (((Sorting, Insertion Sort)))
@@ -29,8 +30,8 @@ include::{codedir}/algorithms/sorting/insertion-sort.js[tag=sort, indent=0]
 - <<In-place>>: [big]#✅# Yes
 - <<Online>>: [big]#✅# Yes
 - <<Adaptive>>: [big]#✅# Yes
-- Time Complexity: [big]#⛔️# <<Quadratic>> _O(n^2^)_
-- Space Complexity: [big]#✅# <<Constant>> _O(1)_
+- Time Complexity: [big]#⛔️# <<part01-algorithms-analysis#quadratic>> _O(n^2^)_
+- Space Complexity: [big]#✅# <<part01-algorithms-analysis#constant>> _O(1)_
 
 (((Quadratic)))
 (((Runtime, Quadratic)))

book-pro/content/part04/merge-sort.asc

@@ -42,7 +42,7 @@ include::{codedir}/algorithms/sorting/merge-sort.js[tag=merge, indent=0]
 <2> If `array1` current element (`i1`) has the lowest value, we insert it into the `mergedArray` if not we then insert `array2` element.
 <3> `mergedArray` is `array1` and `array2` combined in ascending order (sorted).
 
-Merge sort has an _O(n log n)_  running time. For more details about how to extract the runtime go to <<Linearithmic>> section.
+Merge sort has an _O(n log n)_  running time. For more details about how to extract the runtime go to <<part01-algorithms-analysis#linearithmic>> section.
 
 ===== Merge Sort Properties
 
@@ -51,8 +51,8 @@ Merge sort has an _O(n log n)_  running time. For more details about how to extr
 - <<Online>>: [big]#️❌# No, new elements will require to sort the whole array.
 - <<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)_, use auxiliary memory
+- Time Complexity: [big]#✅# <<part01-algorithms-analysis#linearithmic>> _O(n log n)_
+- Space Complexity: [big]#⚠️# <<part01-algorithms-analysis#linear>> _O(n)_, use auxiliary memory
 
 (((Linearithmic)))
 (((Runtime, Linearithmic)))

book-pro/content/part04/quick-sort.asc

@@ -3,13 +3,14 @@
 // :codedir: ../../src
 // endif::[]
 
+[[quicksort]]
 ==== Quicksort
 (((Sorting, QuickSort)))
 (((QuickSort)))
 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 additional memory.
 
 indexterm:[Divide and Conquer]
-In practice, quicksort outperforms other sorting algorithms like <<Merge Sort>>. And, of course, It also outperforms simple sorting algorithms like <<Selection Sort>>, <<Insertion Sort>> and <<Bubble Sort>>.
+In practice, quicksort outperforms other sorting algorithms like <<part04-algorithmic-toolbox#merge-sort>>. And, of course, It also outperforms simple sorting algorithms like <<part04-algorithmic-toolbox#selection-sort>>, <<part04-algorithmic-toolbox#insertion-sort>> and <<part04-algorithmic-toolbox#insertion-sort>>.
 
 Quicksort picks a "pivot" element (preferably random) and move all the parts 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.
 
@@ -72,7 +73,7 @@ And you can see the implementation of `shuffle` below:
 include::{codedir}/algorithms/sorting/sorting-common.js[tag=shuffle, indent=0]
 ----
 
-With the optimization, Quicksort has an _O(n log n)_ running time. Similar to the merge sort we divide the array into halves each time. For more details about how to extract the runtime go to <<Linearithmic>>.
+With the optimization, Quicksort has an _O(n log n)_ running time. Similar to the merge sort we divide the array into halves each time. For more details about how to extract the runtime go to <<part01-algorithms-analysis#linearithmic>>.
 
 ===== Quicksort Properties
 
@@ -81,8 +82,8 @@ With the optimization, Quicksort has an _O(n log n)_ running time. Similar to th
 - <<Adaptive>>: [big]#️❌# No, mostly sorted array takes the same time O(n log n).
 - <<Online>>: [big]#️❌# No, the pivot element can be choose at random.
 - Recursive: Yes
-- Time Complexity: [big]#✅# <<Linearithmic>> _O(n log n)_
-- Space Complexity: [big]#✅# <<Constant>> _O(1)_
+- Time Complexity: [big]#✅# <<part01-algorithms-analysis#linearithmic>> _O(n log n)_
+- Space Complexity: [big]#✅# <<part01-algorithms-analysis#constant>> _O(1)_
 
 (((Linearithmic)))
 (((Runtime, Linearithmic)))

book-pro/content/part04/selection-sort.asc

@@ -37,8 +37,8 @@ One index is for the position in question (selection/left) and another one for f
 - <<Stable>>: [big]#️️❌# No
 - <<Adaptive>>: [big]#️️❌# No
 - <<Online>>: [big]#️️❌# No
-- Time Complexity: [big]#⛔️# <<Quadratic>> _O(n^2^)_
-- Space Complexity: [big]#✅# <<Constant>> _O(1)_
+- Time Complexity: [big]#⛔️# <<part01-algorithms-analysis#quadratic>> _O(n^2^)_
+- Space Complexity: [big]#✅# <<part01-algorithms-analysis#constant>> _O(1)_
 
 *Why selection sort is not stable?*
 
@@ -50,7 +50,7 @@ Initially, we select the first element `2a` and check if there's anything less t
 Now, we have: `1, 5, 2b, 2a`.
 There you have it, `2b` now comes before `2a`.
 
-// CAUTION: In practice, selection sort performance 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.
+// CAUTION: In practice, selection sort performance is the worst compared <<part04-algorithmic-toolbox#insertion-sort>> and <<part04-algorithmic-toolbox#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.
 
 (((Quadratic)))
 (((Runtime, Quadratic)))

book-pro/content/part04/sorting-algorithms.asc

@@ -4,13 +4,13 @@ Sorting is one of the most common solutions when we want to extract some insight
 We can sort to get the maximum or minimum value and many algorithmic problems involves sorting data first.
 
 .We are going to explore three basic sorting algorithms _O(n^2^)_ which have low overhead:
-- <<Bubble Sort>>
-- <<Selection Sort>>
-- <<Insertion Sort>>
+- <<part04-algorithmic-toolbox#insertion-sort>>
+- <<part04-algorithmic-toolbox#selection-sort>>
+- <<part04-algorithmic-toolbox#insertion-sort>>
 
 .and then discuss efficient sorting algorithms _O(n log n)_ such as:
-- <<Merge Sort>>
-- <<Quicksort>>
+- <<part04-algorithmic-toolbox#merge-sort>>
+- <<part04-algorithmic-toolbox#quicksort>>
 
 Before we dive into the most well-known sorting algorithms, let's discuss the sorting properties.
 
@@ -115,22 +115,22 @@ We explored many algorithms some of them simple and other more performant. Also,
 [cols="20,80"]
 |===
 | Algorithms         | Comments
-| <<Bubble Sort>>    | Swap pairs bubbling up largest numbers to the right
-| <<Insertion Sort>> | Look for biggest number to the left and swap it with current
-| <<Selection Sort>> | Iterate array looking for smallest value to the right
-| <<Merge Sort>>     | Split numbers in pairs, sort pairs and join them in ascending order
-| <<Quicksort>>      | Choose a pivot, set smaller values to the left and bigger to the right.
+| <<part04-algorithmic-toolbox#insertion-sort>>    | Swap pairs bubbling up largest numbers to the right
+| <<part04-algorithmic-toolbox#insertion-sort>> | Look for biggest number to the left and swap it with current
+| <<part04-algorithmic-toolbox#selection-sort>> | Iterate array looking for smallest value to the right
+| <<part04-algorithmic-toolbox#merge-sort>>     | Split numbers in pairs, sort pairs and join them in ascending order
+| <<part04-algorithmic-toolbox#quicksort>>      | Choose a pivot, set smaller values to the left and bigger to the right.
 // | Tim sort        | Hybrid of merge sort and insertion sort
 |===
 
 .Sorting algorithms time/space complexity and properties
 |===
 | Algorithms         | Avg        | Best | Worst | Space       | Stable | In-place | Online | Adaptive
-| <<Bubble Sort>>    | O(n^2^)    | O(n) | O(n^2^) | O(1)      | Yes    | Yes      | Yes    | Yes
-| <<Insertion Sort>> | O(n^2^)    | O(n) | O(n^2^) | O(1)      | Yes    | Yes      | Yes    | Yes
-| <<Selection Sort>> | O(n^2^)    | O(n^2^) | O(n^2^) | O(1)        | No     | Yes      | No    | No
-| <<Merge Sort>>     | O(n log n) | O(n log n) | O(n log n) | O(n)        | Yes     | No       | No     | No
-| <<Quicksort>>      | O(n log n) | O(n^2^) | O(n log n) | O(log n)    | Yes     | Yes      | No     | No
+| <<part04-algorithmic-toolbox#insertion-sort>>    | O(n^2^)    | O(n) | O(n^2^) | O(1)      | Yes    | Yes      | Yes    | Yes
+| <<part04-algorithmic-toolbox#insertion-sort>> | O(n^2^)    | O(n) | O(n^2^) | O(1)      | Yes    | Yes      | Yes    | Yes
+| <<part04-algorithmic-toolbox#selection-sort>> | O(n^2^)    | O(n^2^) | O(n^2^) | O(1)        | No     | Yes      | No    | No
+| <<part04-algorithmic-toolbox#merge-sort>>     | O(n log n) | O(n log n) | O(n log n) | O(n)        | Yes     | No       | No     | No
+| <<part04-algorithmic-toolbox#quicksort>>      | O(n log n) | O(n^2^) | O(n log n) | O(log n)    | Yes     | Yes      | No     | No
 // | Tim sort       | O(n log n) | O(log n)    | Yes    | No       | No     | Yes
 |===
 // end::table[]

book-pro/part02-linear-data-structures.asc

@@ -6,12 +6,12 @@ Data Structures comes in many flavors. There’s no one to rule them all. You ha
 Even though in your day-to-day, you might not need to re-implementing them, knowing how they work internally would help you how when to use over the other or even tweak them to create a new one. We are going to explore the most common data structures time and space complexity.
 
 .In this part we are going to learn about the following linear data structures:
-- <<Array>>
-- <<Linked List>>
-- <<Stack>>
-- <<Queue>>
+- <<part02-linear-data-structures#array>>
+- <<part02-linear-data-structures#linked-list>>
+- <<part02-linear-data-structures#stack>>
+- <<part02-linear-data-structures#queue>>
 
-Later, in the next part, we are going to explore non-linear data structures like <<Graph, Graphs>> and <<Tree, Trees>>.
+Later, in the next part, we are going to explore non-linear data structures like <<part03-graph-data-structures#graph, Graphs>> and <<part03-graph-data-structures#tree, Trees>>.
 
 ifdef::backend-html5[]
 If you want to have a general overview of each one, take a look at the following interactive diagram:
@@ -33,39 +33,7 @@ include::content/part02/stack.asc[]
 <<<
 include::content/part02/queue.asc[]
 
+<<<
+include::content/part02/array-vs-list-vs-queue-vs-stack.asc[]
 
-=== Array vs. Linked List & Queue vs. Stack
-
-In this part of the book, we explored the most used linear data structures such as Arrays, Linked Lists, Stacks and Queues. We implemented them and discussed the runtime of their operations.
-
-.Use Arrays when…
-* You need to access data in random order fast (using an index).
-* Your data is multi-dimensional (e.g., matrix, tensor).
-
-.Use Linked Lists when:
-* You will access your data sequentially.
-* You want to save memory and only allocate memory as you need it.
-* You want constant time to remove/add from extremes of the list.
-
-.Use a Queue when:
-* You need to access your data in a first-come, first served basis (FIFO).
-* You need to implement a <<Breadth-First Search for Binary Tree, Breadth-First Search>>
-
-.Use a Stack when:
-* You need to access your data as last-in, first-out (LIFO).
-* You need to implement a <<Depth-First Search for Binary Tree, Depth-First Search>>
-(((Tables, Linear DS, Array/Lists/Stack/Queue complexities)))
 
-// tag::table[]
-.Time/Space Complexity of Linear Data Structures (Array, LinkedList, Stack & Queues)
-|===
-.2+.^s| Data Structure 2+^s| Searching By 3+^s| Inserting at the 3+^s| Deleting from .2+.^s| Space
-^|_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)
-| <<Singly Linked List>> ^|O(n) ^|O(n) ^|O(1) ^|O(n) ^|O(1) ^|O(1) ^|O(n) ^|*O(n)* ^|O(n)
-| <<Doubly Linked List>> ^|O(n) ^|O(n) ^|O(1) ^|O(n) ^|O(1) ^|O(1) ^|O(n) ^|*O(1)* ^|O(n)
-| <<Stack>> ^|- ^|- ^|- ^|- ^|O(1) ^|- ^|- ^|O(1) ^|O(n)
-| Queue (w/array) ^|- ^|- ^|- ^|- ^|*O(n)* ^|- ^|- ^|O(1) ^|O(n)
-| <<Queue>> (w/list) ^|- ^|- ^|- ^|- ^|O(1) ^|- ^|- ^|O(1) ^|O(n)
-|===
-// end::table[]

book-pro/part03-graph-data-structures.asc

@@ -4,10 +4,10 @@
 Graph-based data structures are everywhere whether you realize it or not. You can find them in databases, Web (HTML DOM tree), search algorithms, finding the best route to get home and many more uses. We are going to learn the basic concepts and when to choose one over the other.
 
 .In this chapter we are going to learn:
-- Exciting <<Graph>> data structure applications
-- Searching efficiently with a <<Tree>> data structures.
-- One of the most versatile data structure of all <<HashMap>>.
-- Keeping dups out with a <<Set>>.
+- Exciting <<part03-graph-data-structures#graph>> data structure applications
+- Searching efficiently with a <<part03-graph-data-structures#tree>> data structures.
+- One of the most versatile data structure of all <<part03-graph-data-structures#hashmap>>.
+- Keeping dups out with a <<part03-graph-data-structures#set>>.
 By the end of this section, you will know the data structures trade-offs and when to use one over the other.
 
 include::content/part03/tree-intro.asc[]
@@ -33,24 +33,6 @@ include::content/part03/graph.asc[]
 <<<
 include::content/part03/graph-search.asc[]
 
+<<<
+include::content/part03/time-complexity-graph-data-structures.asc[]
 
-=== Summary
-
-In this section, we learned about Graphs applications, properties and how we can create them. We mention that you can represent a graph as a matrix or as a list of adjacencies. We went for implementing the later since it's more space efficient. We cover the basic graph operations like adding and removing nodes and edges.  In the algorithms section, we are going to cover searching values in the graph.
-(((Tables, Non-Linear DS, BST/Maps/Sets Complexities)))
-
-// tag::table[]
-.Time and Space Complexity for Non-Linear Data Structures
-|===
-.2+.^s| Data Structure 2+^s| Searching By .2+^.^s| Insert .2+^.^s| Delete .2+^.^s| Space Complexity
-^|_Index/Key_ ^|_Value_
-| <<Binary Search Tree, BST (unbalanced)>> ^|- ^|O(n) ^|O(n) ^|O(n) ^|O(n)
-| <<Self-balancing Binary Search Trees, BST (balanced)>> ^|- ^|O(log n) ^|O(log n) ^|O(log n) ^|O(n)
-| Hash Map (naïve) ^|O(n) ^|O(n) ^|O(n) ^|O(n) ^|O(n)
-| <<HashMap>> (optimized) ^|O(1)* ^|O(n) ^|O(1)* ^|O(1)* ^|O(1)*
-| <<TreeMap>> (Red-Black Tree) ^|O(log n) ^|O(n) ^|O(log n) ^|O(log n) ^|O(log n)
-| <<HashSet>> ^|- ^|O(n) ^|O(1)* ^|O(1)* ^|O(1)*
-| <<TreeSet>> ^|- ^|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)*.
-// end::table[]

book-pro/part04-algorithmic-toolbox.asc

@@ -8,7 +8,7 @@ IMPORTANT: There's not a single approach to solve all problems but knowing well-
 
 We are going to start with <<Sorting Algorithms>>
 //  and searching algorithms,
-such as <<Insertion Sort>>, <<Merge Sort>> and some others.
+such as <<part04-algorithmic-toolbox#insertion-sort>>, <<part04-algorithmic-toolbox#merge-sort>> and some others.
 Later, you are going to learn some algorithmic paradigms that will help you to identify common patterns and solve problems from different angles.