smallscale changes to multiple chapters.

Author: leios

chapters/euclidean_algorithm/euclidean.md

@@ -52,7 +52,9 @@ The algorithm is a simple way to find the *greatest common divisor* (GCD) of two
 
 Here, we simply line the two numbers up every step and subtract the lower value from the higher one every timestep. Once the two values are equal, we call that value the greatest common divisor. A graph of `a` and `b` as they change every step would look something like this:
 
-![Subtraction-based Euclidean algorithm](res/subtraction.png)
+<p align="center">
+    <img src="res/subtraction.png" width="500" height="500" />
+</p>
 
 Modern implementations, though, often use the modulus operator (%) like so
 
@@ -81,7 +83,9 @@ Modern implementations, though, often use the modulus operator (%) like so
 
 Here, we set `b` to be the remainder of `a%b` and `a` to be whatever `b` was last timestep. Because of how the modulus operator works, this will provide the same information as the subtraction-based implementation, but when we show `a` and `b` as they change with time, we can see that it might take many fewer steps:
 
-![Modulus-based Euclidean algorithm](res/modulus.png)
+<p align="center">
+    <img src="res/modulus.png" width="500" height="500" />
+</p>
 
 The Euclidean Algorithm is truly fundamental to many other algorithms throughout the history of computer science and will definitely be used again later. At least to me, it's amazing how such an ancient algorithm can still have modern use and appeal. That said, there are still other algorithms out there that can find the greatest common divisor of two numbers that are arguably better in certain cases than the Euclidean algorithm, but the fact that we are discussing Euclid two millenia after his death shows how timeless and universal mathematics truly is. I think that's pretty cool.
 

chapters/sorting_searching/bogo/bogo_sort.md

@@ -36,14 +36,8 @@ In the best case, this algorithm runs with a complexity of $$\Omega(1)$$, and in
 In code, it looks something like this:
 
 {% method %}
-{% sample lang="pseudo" %}
-```julia
-function bogo_sort(Vector{Type} a)
-    while(!is_sorted(a))
-        shuffle(a)
-    end
-end
-```
+{% sample lang="jl" %}
+[import:1-14, lang:"julia"](code/julia/bogo.jl)
 {% sample lang="cs" %}
 [import:29-35, lang:"csharp"](code/cs/bogo.cs)
 {% sample lang="clj" %}

chapters/sorting_searching/bogo/code/julia/bogo.jl

@@ -0,0 +1,22 @@
+function is_sorted(a::Vector{Float64})
+    for i = 1:length(a)-1
+        if (a[i+1] > a[i])
+            return false
+        end
+    end
+    return true
+end
+
+function bogo_sort(a::Vector{Float64})
+    while(!is_sorted(a))
+        shuffle!(a)
+    end
+end
+
+function main()
+    a = [1., 3, 2,4]
+    bogo_sort(a)
+    println(a)
+end
+
+main()

chapters/sorting_searching/bubble/bubble_sort.md

@@ -31,19 +31,8 @@ In this way, we sweep through the array $$n$$ times for each element and continu
 This means that we need to go through the vector $$\mathcal{O}(n^2)$$ times with code similar to the following:
 
 {% method %}
-{% sample lang="pseudo" %}
-```julia
-function bubble_sort(Vector{Type} a)
-    n = length(a)
-    for i = 0:n
-        for j = 1:n
-            if(a[j-1] > a[j])
-                swap(a[j-1], a[j])
-            end
-        end
-    end
-end
-```
+{% sample lang="jl" %}
+[import:1-10, lang:"julia"](code/julia/bubble.jl)
 {% sample lang="cs" %}
 [import:9-27, lang:"csharp"](code/cs/Sorting.cs)
 {% endmethod %}

chapters/sorting_searching/bubble/code/julia/bubble.jl

@@ -0,0 +1,19 @@
+function bubble_sort(a::Vector{Float64})
+    n = length(a)
+    for i = 1:n
+        for j = 1:n-1
+            if(a[j] < a[j+1])
+                a[j], a[j+1] = a[j+1], a[j]
+            end
+        end
+    end
+end
+
+
+function main()
+    a = [1., 3, 2, 4, 5, 10, 50, 7, 1.5, 0.3]
+    bubble_sort(a)
+    println(a)
+end
+
+main()

chapters/tree_traversal/tree_traversal.md

@@ -71,7 +71,9 @@ Because of this, the most straightforward way to traverse the tree might be recu
 
 At least to me, this makes a lot of sense. We fight recursion with recursion! First, we first output the node we are on and then we call `DFS_recursive(...)` on each of its children nodes. This method of tree traversal does what its name implies: it goes to the depths of the tree first before going through the rest of the branches. In this case, the ordering looks like:
 
-![DFS ordering pre](res/DFS_pre.png)
+<p align="center">
+    <img src="res/DFS_pre.png" width="500" height="500" />
+</p>
 
 Note that the in the code above, we are missing a crucial step: *checking to see if the node we are using actually exists!* Because we are using a vector to store all the nodes, we will be careful not to run into a case where we call `DFS_recursive(...)` on a node that has yet to be initialized; however, depending on the language we are using, we might need to be careful of this to avoid recursion errors! 
 
@@ -99,7 +101,9 @@ Now, in this case the first element searched through is still the root of the tr
 [import:20-29, lang:"julia"](code/julia/Tree.jl)
 {% endmethod %}
 
-![DFS ordering post](res/DFS_post.png)
+<p align="center">
+    <img src="res/DFS_post.png" width="500" height="500" />
+</p>
 
 In this case, the first node visited is at the bottom of the tree and moves up the tree branch by branch. In addition to these two types, binary trees have an *in-order* traversal scheme that looks something like this:
 
@@ -124,7 +128,10 @@ In this case, the first node visited is at the bottom of the tree and moves up t
 [import:31-47, lang:"julia"](code/julia/Tree.jl)
 {% endmethod %}
 
-![DFS ordering in](res/DFS_in.png)
+<p align="center">
+    <img src="res/DFS_in.png" width="500" height="500" />
+</p>
+
 
 The order here seems to be some mix of the other 2 methods and works through the binary tree from left to right.
 
@@ -162,7 +169,9 @@ In code, it looks like this:
 
 All this said, there are a few details about DFS that might not be idea, depending on the situation. For example, if we use DFS on an incredibly long tree, we will spend a lot of time going further and further down a single branch without searching the rest of the data structure. In addition, it is not the natural way humans would order a tree if asked to number all the nodes from top to bottom. I would argue a more natural traversal order would look something like this:
 
-![BFS ordering](res/BFS_simple.png)
+<p align="center">
+    <img src="res/BFS_simple.png" width="500" height="500" />
+</p>
 
 And this is exactly what Breadth-First Search (BFS) does! On top of that, it can be implemented in the same way as the `DFS_stack(...)` function above, simply by swapping the `stack` for a `queue`, which is similar to a stack, exept that it only allows you to interact with the very first element instead of the last. In code, this looks something like: