fix index to avoid blank lines

amejiarosario · amejiarosario · commit 711f84d31649 · 2019-03-22T17:53:54.000-04:00
diff --git a/book/chapters/algorithms-analysis.adoc b/book/chapters/algorithms-analysis.adoc
@@ -60,7 +60,6 @@ To give you a clearer picture of how different algorithms perform as the input s
 |=============================================================================================
 
 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,5 +184,4 @@ 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
@@ -44,7 +44,6 @@ 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
@@ -46,7 +46,6 @@ As you can see, in both examples (array and linked list) if the input is a colle
 == 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]
@@ -128,7 +127,6 @@ 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.
@@ -223,7 +221,6 @@ A factorial is the multiplication of all the numbers less than itself down to 1.
 === Getting all permutations of a word
 
 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
diff --git a/book/chapters/divide-and-conquer--fibonacci.adoc b/book/chapters/divide-and-conquer--fibonacci.adoc
@@ -1,7 +1,6 @@
 = Recursive Fibonacci Numers
 
 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
diff --git a/book/chapters/divide-and-conquer--intro.adoc b/book/chapters/divide-and-conquer--intro.adoc
@@ -1,6 +1,5 @@
 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.
diff --git a/book/chapters/dynamic-programming--fibonacci.adoc b/book/chapters/dynamic-programming--fibonacci.adoc
@@ -3,7 +3,6 @@
 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
@@ -25,7 +24,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,5 +36,4 @@ 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
@@ -250,7 +250,6 @@ So far, we have seen two liner data structures with different use cases. Here’
 |===
 
 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.adoc b/book/chapters/map-hashmap.adoc
@@ -296,5 +296,4 @@ 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
@@ -10,7 +10,6 @@ Implementing a Map with a tree, TreeMap, has a couple of advantages over a HashM
 * 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
@@ -3,7 +3,6 @@
 ((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.
 
 image:image11.png[Mergesort visualization,width=500,height=600]
diff --git a/book/chapters/queue.adoc b/book/chapters/queue.adoc
@@ -69,7 +69,6 @@ As an experiment, we can see in the following table that if we had implemented t
 | Queue (w/array) ^|- ^|- ^|- ^|- ^|*O(n)* ^|- ^|- ^|O(1) ^|O(n)
 | 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
@@ -3,7 +3,6 @@
 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>>.
 
 Quicksort 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.
@@ -52,7 +51,6 @@ Merge sort has a _O(n log n)_ running time. For more details about the how to ex
 - Recursive: Yes
 - Time Complexity: [big]#✅# <<Linearithmic>> _O(n log n)_
 - Space Complexity: [big]#⚠️# <<Linear>> _O(n)_
-
 indexterm:[Space Complexity, Linear]
 
 // Resources:
diff --git a/book/chapters/sample.adoc b/book/chapters/sample.adoc
@@ -286,7 +286,6 @@ digraph G {
 ....
 
 === Graphviz with svg
-
 indexterm:[Fibonacci]
 
 [graphviz, Recursive Fibonacci call tree with dp (sample), svg]
diff --git a/book/chapters/selection-sort.adoc b/book/chapters/selection-sort.adoc
@@ -38,5 +38,4 @@ 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
@@ -212,7 +212,6 @@ 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,6 @@
 = 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>>.
diff --git a/book/chapters/tree--binary-search-tree.adoc b/book/chapters/tree--binary-search-tree.adoc
@@ -170,6 +170,5 @@ 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,5 +96,4 @@ 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]
