Fix minor typos in introductory pages (#122)

* Minor typo fixes to introductory pages

* Rewording of the examples for the exponent/biased exponent in floating point number storage

* Fix example to use 1-based indexing in Julia example

* Fix typo introduced in 'fix typos' commit

* Some changes to the convolutions and sorting chapter texts.
'convolutional theorem' -> 'convolution theorem' is replaced.
A few words added or rearranged to clarify or simplify sentences.
Minor typos fixed.

Author: chrisb2244

README.md

@@ -11,7 +11,7 @@ If you would like to communicate more directly, please feel free to go to our di
 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 litte, if any practical purpose.
+That said, we'll still cover a few algorithms for fun that have very little, if any practical purpose.
 
 If you would like to contribute, feel free to go to any chapter with code associated with it and implement that algorithm in your favorite language,
 and then submit the code via pull request, following the submission guidelines found in `chapters/how_to_contribute.md` (or [here](chapters/how_to_contribute.md) if you are reading this on gitbook).

chapters/convolutions/convolutions.md

@@ -65,24 +65,24 @@ As described in the chapter on [Fourier Transforms](chapters/computational_mathe
 When we transform a wave into frequency space, we see a single peak in frequency space related to the frequency of that wave.
 No matter what function we send into a Fourier Transform, the frequency-space image can be interpreted as a seires of different waves with a specified frequency.
 
-So here's the idea: if we take two functions $$f(x)$$ and $$g(x)$$ and move them to frequency space to be $$\hat f(\xi)$$ and $$\hat g(\xi)$$, we can then multiply those two functions and transform them back into a third function to blend teh signals together.
+So here's the idea: if we take two functions $$f(x)$$ and $$g(x)$$ and move them to frequency space to be $$\hat f(\xi)$$ and $$\hat g(\xi)$$, we can then multiply those two functions and transform them back into a third function to blend the signals together.
 In this way, we will have a third function that relates the frequency-space images of the two input functions.
 *This is precisely a convolution!*
 
 Don't believe me?
-Well, this is because of something known as the *convolutional theorem* which looks something like this:
+Well, this is because of something known as the *convolution theorem* which looks something like this:
 
 $$\mathcal{F}(f*g) = \mathcal{F}(f) \cdot \mathcal{F}(g)$$
 
 Where $$\mathcal{F}$$ denotes the Fourier Transform.
 Now, by using a Fast Fourier Transform (fft) in code, this can take a standard convolution on two arrays of length $$n$$, which is an $$\mathcal{O}(n^2)$$ process, to $$\mathcal{O}(n\log(n))$$.
-This means that the convolutional theorem is fundamental to creating fast convolutional methods for large inputs, assuming that both input signals are of the similar sizes.
-That said, it is debatable whether the convolutional theorem will be faster when the filter size is small.
+This means that the convolution theorem is fundamental to creating fast convolutional methods for large inputs, assuming that both of the input signals are similar sizes.
+That said, it is debatable whether the convolution theorem will be faster when the filter size is small.
 Also: depending on the language used, we might need to read in a separate library for FFT's.
 
 {% method %}
 {% sample lang="jl" %}
-That said, Julia has an in-built fft routine, so the code for this method not be simpler:
+That said, Julia has an in-built fft routine, so the code for this method could not be simpler:
 [import:19-22, lang:"julia"](code/julia/conv.jl)
 Where the `.*` operator is an element-wise multiplication.
 {% sample lang="hs" %}
@@ -98,10 +98,10 @@ Where the `.*` operator is an element-wise multiplication.
 This method also has the added advantage that it will *always output an array of the size of your signal*; however, if your signals are not of equal size, we need to pad the smaller signal with zeros.
 Also note that the Fourier Transform is a periodic or cyclical operation, so there are no real edges in this method, instead the arrays "wrap around" to the other side.
 For this reason, this convolution is often called a *cyclic convolution* instead of a *linear convolution* like above.
-Note that cyclical convolutions can definitely still be done without Fourier Transforms and we can do linear convolutions with Fourier Transforms, but it makes the code slightly more complicated than described above.
+Note that cyclic convolutions can definitely still be done without Fourier Transforms and we can do linear convolutions with Fourier Transforms, but it makes the code slightly more complicated than described above.
 
 <!---
-If you are still having trouble wrapping your head around what the convolutional theorem actually means, maybe this graphic will help:
+If you are still having trouble wrapping your head around what the convolution theorem actually means, maybe this graphic will help:
 
 ADD IMAGE
 

chapters/getting_started.md

@@ -4,7 +4,7 @@ Here's the thing. I love programming. I know it's fun, interactive, and addictiv
 
 I don't know if you guys had a similar childhood to mine or not, but I found that no matter who I spoke to, there was one central theme in all of our lives -- something so fundamental to the way we communicated with each other that it was nearly impossible to have a discussion without bringing it up: **Video Games**.
 
-Like most of my friends, I spent my entire childhood in front of a television screen or monitor, trying desperately to compete with world-destroying supervillains or at the very lease, anthropomorphic turtles with spikes on their back. During school, we would come together and talk about the latest video game gossip. At the time, the internet was still young and I hardly used it for any real purpose. Sure, I would get online every now and again for a school project or two, but it was definitely not a central component to my life... Well, at least not until high school when I became addicted to one Massively Multiplayer Online game, in particular (which will remain nameless).
+Like most of my friends, I spent my entire childhood in front of a television screen or monitor, trying desperately to compete with world-destroying supervillains or at the very least, anthropomorphic turtles with spikes on their backs. During school, we would come together and talk about the latest video game gossip. At the time, the internet was still young and I hardly used it for any real purpose. Sure, I would get online every now and again for a school project or two, but it was definitely not a central component to my life... Well, at least not until high school when I became addicted to one Massively Multiplayer Online game, in particular (which will remain nameless).
 
 I bought my first laptop after working all summer as a lifeguard my freshman year in high school, but at the time, I was downright awful with computers. I couldn't even figure out antivirus software and my grandfather had to help me get everything set up. It was the era of Windows Vista and that seemed fine to me, but when I returned to school, my friends (who all seemed to know way more than I did on the subject), seemed to believe Vista to be a demon spawned from the pits of... Microsoft? 
 
@@ -16,7 +16,7 @@ Of course I asked about it, but this was early high school. My friends may have
 
 Remember how I said I couldn't get the virus software to work on my computer? Yeah. At this point, I was thinking, *What? A computer that couldn't catch viruses? No way! That's gotta be **leagues** easier to use than Windows!*
 
-*Oh ho* I was... well... I was downright naive. I had no idea what I was doing. That night, I ran home, super excited to learn about linux and operating systems, and spent the entire night browsing the internet, trying to find whatever information was out there. At the time, my google-fu was weak and my internet was slow. The first thing I learned was that there were apparently different types of linuxes called "distributions." At that point, I probably seArched "What is the best linux?" or something to that effect. Somehow, I managed to find [distrowatch](https://distrowatch.com/), which had a list of all the most popular distros on the side. 
+*Oh ho* I was... well... I was downright naive. I had no idea what I was doing. That night, I ran home, super excited to learn about linux and operating systems, and spent the entire night browsing the internet, trying to find whatever information was out there. At the time, my google-fu was weak and my internet was slow. The first thing I learned was that there were apparently different types of linuxes called "distributions." At that point, I probably searched "What is the best linux?" or something to that effect. Somehow, I managed to find [distrowatch](https://distrowatch.com/), which had a list of all the most popular distros on the side. 
 
 I don't remember the exact order, but I knew the key players were there: Ubuntu, Mint, Fedora, Debian, and Arch. Now, here's where my years of gaming experience came in. I personified each distribution as a class in a game world. Ubuntu was the easy to use axe-wielding warrior that would get the job done. Fedora was the Archer in the back with a feather in his cap and a quick quip for everything. Debian was the grandmotherly spellcaster just trying to keep everyone alive. Then there was Arch, the one who rushed into combat without any armor and uses only the environment as a weapon. 
 

chapters/how_to_contribute.md

@@ -19,7 +19,7 @@ Now for some specifics on submissions:
 
 For this project, we allow submissions in every language. 
 To submit code, simply go to the code directory of whatever chapter you want and add a directory for your language of choice. 
-We use two gitbook plugins to allow users to flip between languages on differend algorithms.
+We use two gitbook plugins to allow users to flip between languages on different algorithms.
 One is the theme-api, and the other is the include-codeblock api.
 We need the following statements in the markdown file for these to work together:
 

chapters/principles_of_code/building_blocks/bitlogic.md

@@ -63,9 +63,9 @@ Now, how is this actually implemented on your computer?
 Well, one way is with the IEE 754 Floating-point Arithmetic Standard. 
 For 32 bits, the first bit is the *sign bit*, the next 8 bits tell us about the number's exponent, and the next 23 are called the *mantissa* and hold the binary string, itself. Now, there are a few points to keep in mind:
 
-1. Because the exponent is being represented in 8 bits, we only have 256 values to play with. This means that the largest exponent we can represent (in single precision) is 128 and the smallest is -127. For this reason, we will add 127 to the power of every floating-point number. So, $$1 = 1 \times 10^{127}$$.
+1. Because the exponent is being represented in 8 bits, we only have 256 values to play with. This means that the largest exponent we can represent (in single precision) is 128 and the smallest is -127. For this reason, we will add 127 to the power of every floating-point number. So, $$1 = 1 \times 2^{0}$$. The exponent stored is $$0+127 = 127$$.
 
-2. We normalize every bitstring to the first 1 available. For example: $$9.125 = 1.001001 \times 10^{130}$$, $$8.25 = 1.00001 \times 10^{130}$$, $$0.5 = 1 \times 10^{126}$$ $$\ldots$$ This means that *there will always be a leading 1 in our bitstring*. This means that the first 1 is redundant and can be removed from the mantissa.
+2. We normalize every bitstring to the first 1 available. For example: $$9.125 = 1.001001 \times 2^{3}$$ and the biased exponent is $$3+127=130$$, $$8.25 = 1.00001 \times 2^{130}$$, $$0.5 = 1 \times 2^{126}$$ $$\ldots$$ This means that *there will always be a leading 1 in our bitstring*. This means that the first 1 is redundant and can be removed from the mantissa.
 
 So here are a few floating-point numbers and their corresponding bitstrings:
 

chapters/principles_of_code/building_blocks/functions.md

@@ -1,7 +1,7 @@
 ### Functions
 
 Functions make sense from a mathematical point of view. 
-$$f(x) = 2x+5$$ returns a value for x at any point you want. 
+$$f(x) = 2x+5$$ returns a value for $$f(x)$$ at any point $$x$$ that you want. 
 For example $$f(5) = 15$$, or $$f(10) = 25$$.
 Often times, the function is graphed for *every point* indicating the precise nature of how the function and variable relate to one another, but that is another matter entirely. 
 For the most part, functions in programming work exactly the same way. 

chapters/principles_of_code/building_blocks/stacks.md

@@ -11,4 +11,4 @@ For the most part, though, queues and stacks are treated the same way. There mus
 2. to remove the first element (`pop()`)
 3. to push elements onto the data structure (`push()`)
 
-The notation for this depends on the language you are using. Queues, for example, will often use `dequeue()` instead of `pop()` and `front()` instead of `top()`. You will see the language-specific details in the source code under the algorithms in this book, so for now it's simple important to know what stacks and queues are and how to access elements held within them.
+The notation for this depends on the language you are using. Queues, for example, will often use `dequeue()` instead of `pop()` and `front()` instead of `top()`. You will see the language-specific details in the source code under the algorithms in this book, so for now it's simply important to know what stacks and queues are and how to access elements held within them.

chapters/principles_of_code/choosing_a_language/choosing_a_language.md

@@ -21,7 +21,7 @@ So there I was, struggling to figure out what to do and where to go.
 I decided to do what any teenage boy would do in that situation: go to the bookstore and see what books were actually available for purchase at the time. 
 Now, I think the first book I picked up really describes the desperate pit I had dug for myself. 
 It was a book on how to make websites in HTML. 
-That was about as far away as I could have gotten from my gola of making video games. 
+That was about as far away as I could have gotten from my goal of making video games. 
 I will refrain from commenting further on that book for now because a much more important decision was ahead of me. 
 There before me was an aisle with all the key players I had heard about online: C, C++, C#, Java, Python, Ruby, and so on. 
 They were there just waiting to be chosen. 
@@ -34,7 +34,7 @@ At some point, a store employee walked by and I asked if he knew anything about
 He said he did, so I asked the only question that popped into my head at the time, "What's the difference between C, C++, and C#?" 
 
 The employee said that C# was the newest of the three languages, but that all three were used regularly and if I wanted to learn programming, any would do. 
-Like the experts online, he then suggested python because it was easy for beginners and I was clearly a novice. 
+Like the experts online, he then suggested Python because it was easy for beginners and I was clearly a novice. 
 I thanked him for his time and began thumbing through the book on C#. 
 I remember thinking, *C must be the original language. C+ must be the next generation, followed by C++, then C+++, and then they stylistically changed C++++ to C# by placing the 4 plusses in a pound sign. I guess this means that C will be a little too outdated, but C# might be a little too new. I'll go with C++.*
 

chapters/principles_of_code/notation/notation.md

@@ -73,7 +73,7 @@ Let's consider the following function:
 
 ```julia
 function linear(a::Array{Float64})
-    for i = 0:length(a)
+    for i = 1:length(a)
         println(a[i])
     end
 end

chapters/principles_of_code/principles_of_code.md

@@ -23,7 +23,7 @@ create_something(Human(0,1))
 
 I am sure this has a name, but I like to call it the *perfectionist's loop*. It's obviously endless and the only way out is by forcing the code to terminate early with `ctrl+c`. Any artist knows this problem. At first, the act of creation is fun, but after a few iterations, it becomes frustrating. Soon, you are curled into a ball in the corner of a room with a paintbrush in your hand and a myriad of colors splattered all over you and the immediate area. In front of you lay the remains of your art, toppled to the ground. It happens. It will probably happen when you learn programming. When it happens, there is only one thing to do: *keep iterating through the loop!* 
 
-The moment you press `ctrl_c` is the moment you stop improving. Don't stop improving. Don't lower your standards. If you ever need motivation to continue, look at who you were a few months ago. You should be "better" than that person. If not, figure out what's holding you back and keep iterating through the loop!
+The moment you press `ctrl+c` is the moment you stop improving. Don't stop improving. Don't lower your standards. If you ever need motivation to continue, look at who you were a few months ago. You should be "better" than that person. If not, figure out what's holding you back and keep iterating through the loop!
 
 The problem is that when it comes to programming, there are a bunch of technical problems that crop up and prevent us from improving. This chapter is specifically written to help you make decisions and improve your ability to program. We'll start with choosing a language -- a question that kept me from even starting programming to begin with. Then we'll move on to programming building blocks and important data structures to remember. The idea is that we'll link to the building block sections when necessary throughout the book. This section will probably be the section that changes the most frequently as the archive evolves. after all, the more algorithms we cover, the more building blocks will be necessary to write them.