Clean up whitespace related issues in entire project

.editorconfig

@@ -1,14 +1,10 @@
 root = true
 
-# This file
-[.editorconfig]
-trim_trailing_whitespace = true
-insert_final_newline = true
-
-# Pretty much everything should trim whitespace and have a final EOL
-[*.{c,clj,cpp,cs,css,elm,go,hs,html,jl,js,md,py,rs}]
+# Base for all text files
+[*]
 trim_trailing_whitespace = true
 insert_final_newline = true
+end_of_line = lf
 
 # C
 [*.c]
@@ -69,6 +65,11 @@ indent_size = 2
 indent_style = space
 indent_size = 2
 
+# OCAML
+[*.ml]
+indent_style = space
+indent_size = 2
+
 # Python
 [*.py]
 indent_style = space

.gitattributes

@@ -0,0 +1,2 @@
+# Force all text files to have LF line endings
+* text=auto eol=lf

README.md

@@ -1,5 +1,5 @@
 # The Arcane Algorithm Archive
-The Arcane Algorithm Archive is a collaborative effort to create a guide for all important algorithms in all languages. 
+The Arcane Algorithm Archive is a collaborative effort to create a guide for all important algorithms in all languages.
 This goal is obviously too ambitious for a book of any size, but it is a great project to learn from and work on and will hopefully become an incredible resource for programmers in the future.
 The book can be found here: https://www.algorithm-archive.org/.
 The github repository can be found here: https://github.com/algorithm-archivists/algorithm-archive.
@@ -8,7 +8,7 @@ and livecoded on Twitch: https://www.twitch.tv/simuleios.
 If you would like to communicate more directly, please feel free to go to our discord: https://discord.gg/Pr2E9S6.
 
 
-Note that the this project is is essentially a book about algorithms collaboratively written by an online community. 
+Note that the this project is is essentially a book about algorithms collaboratively written by an online community.
 Fortunately, there are a lot of algorithms out there, which means that there is a lot of content material available.
 Unfortunately, this means that we will probably never cover every algorithm ever created and instead need to focus on what the community sees as useful and necessary.
 That said, we'll still cover a few algorithms for fun that have very little, if any practical purpose.

TODO.md

@@ -23,7 +23,7 @@ I'll try to keep this list updated as I write more sections
 Here are points of discussion that need to be had about the Algorithm Archive before it gets too big and becomes too difficult to revise everything
 
 * **Should community-submitted code be clean or efficeint?** When it comes to writing code, I often feel readability is the most important factor to keep in mind; however, with the code submitted to this archive, there will be psudocode available to guide new folks through the process of writing the algorithm for the first time. For this reason, it might be best for the community to submit the most efficient code they can write in their own languages, commenting in any tricks to improve performance.
-* **Is the current method of writing optimal?** When I originally envisioned this project, I thought that I would do all the writing and the community would do (most of) the coding. That said, I am becoming more open to the idea of letting community members write for the Archive. The advantage to this is obvious: The book gets written faster. The disadvantage is also obvious: We lose focus and consistency throughout the book. 
-* **We need a Logo.**  I have no idea how to go about this. Maybe a logo contest at 16384 subscribers on youtube? The project will be large enough at that point to warrant a good logo. I really want something simple, though, like a [Trefoil Knot](https://en.wikipedia.org/wiki/Trefoil_knot#/media/File:Trefoil_knot_left.svg) or something. It kinda looks like 3 A's if you look at it the right way, and we'll definitely cover knot algorithms at some point because they are fascinating! 
+* **Is the current method of writing optimal?** When I originally envisioned this project, I thought that I would do all the writing and the community would do (most of) the coding. That said, I am becoming more open to the idea of letting community members write for the Archive. The advantage to this is obvious: The book gets written faster. The disadvantage is also obvious: We lose focus and consistency throughout the book.
+* **We need a Logo.**  I have no idea how to go about this. Maybe a logo contest at 16384 subscribers on youtube? The project will be large enough at that point to warrant a good logo. I really want something simple, though, like a [Trefoil Knot](https://en.wikipedia.org/wiki/Trefoil_knot#/media/File:Trefoil_knot_left.svg) or something. It kinda looks like 3 A's if you look at it the right way, and we'll definitely cover knot algorithms at some point because they are fascinating!
 
 Anyway, let me know what you think. I love the community we have here and appreciate all the conversations we've had so far!

book.json

@@ -25,7 +25,7 @@
 				},
 				{
 					"lang": "cs",
-					"name": "C#"	
+					"name": "C#"
 				},
 				{
 					"lang": "cpp",
@@ -79,7 +79,7 @@
 					"lang": "LabVIEW",
 					"name": "LabVIEW"
 				}
-                                
+
 			],
 			"split": false
         }

book_ace.json

@@ -18,14 +18,14 @@
 				},
 				{
 					"lang": "cs",
-					"name": "C#"	
+					"name": "C#"
 				},
 				{
 					"lang": "c",
-					"name": "C"	
+					"name": "C"
 				}
 			],
-			"split": true 
+			"split": true
 		},
 		"include-codeblock": {
 			"template": "ace",

chapters/FFT/code/julia/fft.jl

@@ -25,7 +25,7 @@ function cooley_tukey(x)
     half = div(N,2)
     factor = exp.(-2im*pi*n/N)
     return vcat(x_odd + x_even .* factor[1:half],
-                x_odd - x_even .* factor[1:half]) 
+                x_odd - x_even .* factor[1:half])
 
 end
 
@@ -84,7 +84,7 @@ function iterative_cooley_tukey(x)
            for k = 1:length(y)
                z[start_index+k-1] = y[k]
            end
-       end 
+       end
        bnum = div(bnum,2)
     end
 

chapters/FFT/cooley_tukey.md

@@ -1,15 +1,15 @@
 ## What Makes a Fourier Transform Fast?
 
-If there were ever an algorithm to radically change the landscape of computer science and engineering by making seemingly impossible problems possible, it would be the Fast Fourier Transform (FFT). 
+If there were ever an algorithm to radically change the landscape of computer science and engineering by making seemingly impossible problems possible, it would be the Fast Fourier Transform (FFT).
 On the surface, the algorithm seems like a simple application of recursion, and in principle, that is exactly what it is; however, the Fourier Transform is no ordinary transform -- it allows researchers and engineers to easily bounce back and forth between real space and frequency space and is the heart of many physics and engineering applications.
-From calculating superfluid vortex positions to super-resolution imaging, Fourier Transforms lay at the heart of many scientific disciplines and are essential to many algorithms we will cover later in this book. 
+From calculating superfluid vortex positions to super-resolution imaging, Fourier Transforms lay at the heart of many scientific disciplines and are essential to many algorithms we will cover later in this book.
 
-Simply put, the Fourier Transform is a beautiful application of complex number systems; however, it would rarely be used today if not for the ability to quickly perform the operation with Fast Fourier Transform, first introduced by the great Frederick Gauss in 1805 and later independently discovered by James Cooley and John Tukey in 1965 {{ "ct1965" | cite }}. 
+Simply put, the Fourier Transform is a beautiful application of complex number systems; however, it would rarely be used today if not for the ability to quickly perform the operation with Fast Fourier Transform, first introduced by the great Frederick Gauss in 1805 and later independently discovered by James Cooley and John Tukey in 1965 {{ "ct1965" | cite }}.
 Gauss (of course) already had too many things named after him and Cooley and Tukey both had cooler names, so the most common algorithm for FFT's today is known as the Cooley-Tukey algorithm.
 
 ### What is a Fourier Transform?
 
-To an outsider, the Fourier Transform looks like a mathematical mess -- certainly a far cry from the heroic portal between two domains I have depicted it to be; however, like most things, it's not as bad as it initially appears to be. 
+To an outsider, the Fourier Transform looks like a mathematical mess -- certainly a far cry from the heroic portal between two domains I have depicted it to be; however, like most things, it's not as bad as it initially appears to be.
 So, here it is in all it's glory!
 
 $$F(\xi) = \int_{-\infty} ^\infty f(x) e^{-2 \pi i x \xi} dx$$
@@ -18,24 +18,24 @@ and
 
 $$f(x) = \int_{-\infty} ^\infty F(\xi) e^{2 \pi i \xi x} d\xi$$
 
-Where $$F(\xi)$$ represents a function in frequency space, $$\xi$$ represents a value in frequency space, $$f(x)$$ represents a function in real space, and $$x$$ represents a value in the real space. 
-Note here that the only difference between the two exponential terms is a minus sign in the transformation to frequency space. 
+Where $$F(\xi)$$ represents a function in frequency space, $$\xi$$ represents a value in frequency space, $$f(x)$$ represents a function in real space, and $$x$$ represents a value in the real space.
+Note here that the only difference between the two exponential terms is a minus sign in the transformation to frequency space.
 As I mentioned, this is not intuitive syntax, so please allow me to explain a bit.
 
 Firstly, **what does the Fourier Transform do?**
 
 If we take a sum sinusoidal functions (like $$\sin(\omega t)$$ or $$\cos(\omega t)$$), we might find a complicated mess of waves between $$\pm 1$$.
 Each constituent wave can be described by only one value: $$\omega$$.
-So, instead of representing these curves as seen above, we could instead describe them as peaks in frequency space, as shown below. 
+So, instead of representing these curves as seen above, we could instead describe them as peaks in frequency space, as shown below.
 
 <p align="center">
     <img src="res/FT_example.png" width="500" height="250" />
 </p>
 
-This is what the Fourier Transform does! 
+This is what the Fourier Transform does!
 After performing the transform, it is now much, much easier to understand precisely which frequencies are in our waveform, which is essential to most areas of signal processing.
 
-Now, how does this relate to the transformations above? 
+Now, how does this relate to the transformations above?
 Well, the easiest way is to substitute in the Euler's formula:
 
 $$e^{2 \pi i \theta} = \cos(2 \pi \theta) + i \sin(2 \pi \theta)$$
@@ -48,10 +48,10 @@ and our function in real space into:
 
 $$f(x) = \int_{-\infty} ^\infty F(\xi) (\cos(2 \pi \xi x) + i \sin(2 \pi \xi x))e^{2 \pi i \xi x} d\xi$$
 
-Here, the $$\sin$$ and $$\cos$$ functions are clearly written in the formulas, so it looks much friendlier, right? 
-This means that a point in real space is defined by the integral over all space of it's corresponding frequency function multiplied by sinusoidal oscillations. 
+Here, the $$\sin$$ and $$\cos$$ functions are clearly written in the formulas, so it looks much friendlier, right?
+This means that a point in real space is defined by the integral over all space of it's corresponding frequency function multiplied by sinusoidal oscillations.
 
-Truth be told, even after seeing this math, I still didn't understand Fourier Transforms. 
+Truth be told, even after seeing this math, I still didn't understand Fourier Transforms.
 Truth be told, I didn't understand it fully until I discretized real and frequency space to create the Discrete Fourier Transform (DFT), which is the only way to implement Fourier Transforms in code.
 
 ### What is a Discrete Fourier Transform?
@@ -60,12 +60,12 @@ In principle, the Discrete Fourier Transform (DFT) is simply the Fourier transfo
 
 $$X_k = \sum_{n=0}^{N-1} x_n \cdot e^{-2 \pi k n / N}$$
 
-and 
+and
 
 $$x_n = \frac{1}{N} \sum_{k=0}^{N-1} X_k \cdot e^{2 \pi k n / N}$$
 
-Where $$X_n$$ and $$x_n$$ are sequences of $$N$$ numbers in frequency and real space, respectively. 
-In principle, this is no easier to understand than the previous case! 
+Where $$X_n$$ and $$x_n$$ are sequences of $$N$$ numbers in frequency and real space, respectively.
+In principle, this is no easier to understand than the previous case!
 For some reason, though, putting code to this transformation really helped me figure out what was actually going on.
 
 {% method %}
@@ -83,21 +83,21 @@ For some reason, though, putting code to this transformation really helped me fi
 [import:2-11, lang:"julia"](code/julia/fft.jl)
 {% endmethod %}
 
-In this function, we define `n` to be a set of integers from $$0 \rightarrow N-1$$ and arrange them to be a column. 
-We then set `k` to be the same thing, but in a row. 
-This means that when we multiply them together, we get a matrix, but not just any matrix! 
+In this function, we define `n` to be a set of integers from $$0 \rightarrow N-1$$ and arrange them to be a column.
+We then set `k` to be the same thing, but in a row.
+This means that when we multiply them together, we get a matrix, but not just any matrix!
 This matrix is the heart to the transformation itself!
 
 ```
-M = [1.0+0.0im  1.0+0.0im           1.0+0.0im          1.0+0.0im; 
-     1.0+0.0im  6.12323e-17-1.0im  -1.0-1.22465e-16im -1.83697e-16+1.0im; 
-     1.0+0.0im -1.0-1.22465e-16im   1.0+2.44929e-16im -1.0-3.67394e-16im; 
+M = [1.0+0.0im  1.0+0.0im           1.0+0.0im          1.0+0.0im;
+     1.0+0.0im  6.12323e-17-1.0im  -1.0-1.22465e-16im -1.83697e-16+1.0im;
+     1.0+0.0im -1.0-1.22465e-16im   1.0+2.44929e-16im -1.0-3.67394e-16im;
      1.0+0.0im -1.83697e-16+1.0im  -1.0-3.67394e-16im  5.51091e-16-1.0im]
 ```
 
-It was amazing to me when I saw the transform for what it truly was: an actual transformation matrix! 
-That said, the Discrete Fourier Transform is slow -- primarily because matrix multiplication is slow, and as mentioned before, slow code is not particularly useful. 
-So what was the trick that everyone used to go from a Discrete fourier Transform to a *Fast* Fourier Transform? 
+It was amazing to me when I saw the transform for what it truly was: an actual transformation matrix!
+That said, the Discrete Fourier Transform is slow -- primarily because matrix multiplication is slow, and as mentioned before, slow code is not particularly useful.
+So what was the trick that everyone used to go from a Discrete fourier Transform to a *Fast* Fourier Transform?
 
 Recursion!
 
@@ -106,11 +106,11 @@ Recursion!
 The problem with using a standard DFT is that it requires a large matrix multiplications and sums over all elements, which are prohibitively complex operations.
 The Cooley-Tukey algorithm calculates the DFT directly with fewer summations and without matrix multiplications.
 If necessary, DFT's can still be calculated directly at the early stages of the FFT calculation.
-The trick to the Cooley-Tukey algorithm is recursion. 
-In particular, we split the matrix we wish to perform the FFT on into two parts: one for all elements with even indices and another for all odd indices. 
-We then proceed to split the array again and again until we have a manageable array size to perform a DFT (or similar FFT) on. 
+The trick to the Cooley-Tukey algorithm is recursion.
+In particular, we split the matrix we wish to perform the FFT on into two parts: one for all elements with even indices and another for all odd indices.
+We then proceed to split the array again and again until we have a manageable array size to perform a DFT (or similar FFT) on.
 We can also perform a similar re-ordering by using a bit reversal scheme, where we output each array index's integer value in binary and flip it to find the new location of that element.
-With recursion, we can reduce the complexity to $$\sim \mathcal{O}(n \log n)$$, which is a feasible operation. 
+With recursion, we can reduce the complexity to $$\sim \mathcal{O}(n \log n)$$, which is a feasible operation.
 
 In the end, the code looks like:
 {% method %}
@@ -128,14 +128,14 @@ In the end, the code looks like:
 [import:14-31, lang:"julia"](code/julia/fft.jl)
 {% endmethod %}
 
-As a side note, we are enforcing that the array must be a power of 2 for the operation to work. 
+As a side note, we are enforcing that the array must be a power of 2 for the operation to work.
 This is a limitation of the fact that we are using recursion and dividing the array in 2 every time; however, if your array is not a power of 2, you can simply pad the leftover space with 0's until your array is a power of 2.
 
 The above method is a perfectly valid FFT; however, it is missing the pictorial heart and soul of the Cooley-Tukey algorithm: Butterfly Diagrams.
 
 ### Butterfly Diagrams
-Butterfly Diagrams show where each element in the array goes before, during, and after the FFT. 
-As mentioned, the FFT must perform a DFT. 
+Butterfly Diagrams show where each element in the array goes before, during, and after the FFT.
+As mentioned, the FFT must perform a DFT.
 This means that even though we need to be careful about how we add elements together, we are still ultimately performing the following operation:
 
 $$X_k = \sum_{n=0}^{N-1} x_n \cdot e^{-2 \pi k n / N}$$
@@ -146,7 +146,7 @@ Basically, we split the array into a series of omega values:
 $$\omega_N^k = e^{-2 \pi k / N}$$
 
 And at each step, we use the appropriate term.
-For example, imagine we need to perform an FFT of an array of only 2 elements. 
+For example, imagine we need to perform an FFT of an array of only 2 elements.
 We can represent this addition with the following (radix-2) butterfly:
 
 <p align="center">
@@ -197,7 +197,7 @@ Here, the ordering of the array was simply divided into even and odd elements on
 
 Ultimately, that's all I want to say about Fourier Transforms for now, but this chapter still needs a good amount of work!
 I'll definitely come back to this at some point, so let me know what you liked and didn't like and we can go from there!
- 
+
 ### Bibliography
 
 {% references %} {% endreferences %}
@@ -238,11 +238,11 @@ Note: I implemented this in Julia because the code seems more straightforward in
 Some rather impressive scratch code was submitted by Jie and can be found here: https://scratch.mit.edu/projects/37759604/#editor
 {% endmethod %}
 
- 
+
 <script>
 MathJax.Hub.Queue(["Typeset",MathJax.Hub]);
 </script>
-$$ 
+$$
 \newcommand{\d}{\mathrm{d}}
 \newcommand{\bff}{\boldsymbol{f}}
 \newcommand{\bfg}{\boldsymbol{g}}

chapters/QI/QI.md

@@ -1,6 +1,6 @@
 # Quantum Information
 
-Quantum information theory is... intense. 
+Quantum information theory is... intense.
 It requires a strong and fundamental understanding of classical information theory and quantum mechanics.
 It is not obvious in any way and deserves many textbooks on it's own.
 In fact, there are numerous textbooks on the subject already.

chapters/computational_geometry/computational_geometry.md

@@ -1,13 +1,13 @@
 # Computational Geometry
 When it comes to the different sectors of computational mathematics, there are none that bring me more joy than computational geometry.
 In some sense, it is the foundation for almost every area of automatically generated two and three dimensional graphics.
-If you have time to spend poring through some interesting research, I would definitely recommend going to the [arXiv.org section for computational geometry](https://arxiv.org/list/cs.CG/recent). 
+If you have time to spend poring through some interesting research, I would definitely recommend going to the [arXiv.org section for computational geometry](https://arxiv.org/list/cs.CG/recent).
 We will add more to this section as the Archive evolves, so let me know of any algorithms that you would like to cover in the future!
 
 <script>
 MathJax.Hub.Queue(["Typeset",MathJax.Hub]);
 </script>
-$$ 
+$$
 \newcommand{\d}{\mathrm{d}}
 \newcommand{\bff}{\boldsymbol{f}}
 \newcommand{\bfg}{\boldsymbol{g}}

chapters/computational_geometry/gift_wrapping/chan/chans.md

@@ -1,7 +1,7 @@
 <script>
 MathJax.Hub.Queue(["Typeset",MathJax.Hub]);
 </script>
-$$ 
+$$
 \newcommand{\d}{\mathrm{d}}
 \newcommand{\bff}{\boldsymbol{f}}
 \newcommand{\bfg}{\boldsymbol{g}}

chapters/computational_geometry/gift_wrapping/gift_wrapping.md

@@ -9,7 +9,7 @@ Strictly speaking, though, the term is not entirely accurate for all convex hull
 <script>
 MathJax.Hub.Queue(["Typeset",MathJax.Hub]);
 </script>
-$$ 
+$$
 \newcommand{\d}{\mathrm{d}}
 \newcommand{\bff}{\boldsymbol{f}}
 \newcommand{\bfg}{\boldsymbol{g}}