Fix the size of the diagrams. Add res folders. (#170)

* Add res folder for building_blocks and move images into it. Fix the size of the diagrams.

* Include images of euler in the same way as in other chapters.

* Add res folder for notation and move image. Center image of Complexity Notation chapter.

* Add res folder for principles_of_code and move images into it. Include images of Version Control in the same way as in other chapters.

* Add something to "website.css", so that all images included via <img> are centered.

* Add res folder for taylor and move images into it. Include images of Taylor Series in the same way as in other chapters.

* Remove height attribute for all images, that have an width attribute as well. Therefore avoid distortion for images.

* Use the width attribute instead of the height attribute in the Bitlogic chapter.

* Include the LabView and Scratch image in Verlet Integration like in the same way as in other chapters.

* Include the Scratch image in Tree Traversal in the same way as in other chapters.

* Add css class and add all images in mds to that class.

Author: june128

chapters/FFT/cooley_tukey.md

@@ -28,8 +28,8 @@ If we take a sum sinusoidal functions (like $$\sin(\omega t)$$ or $$\cos(\omega
 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.
 
-<p align="center">
-    <img src="res/FT_example.png" width="500" height="250" />
+<p>
+    <img  class="center" src="res/FT_example.png" width="500" />
 </p>
 
 This is what the Fourier Transform does!
@@ -149,8 +149,8 @@ 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.
 We can represent this addition with the following (radix-2) butterfly:
 
-<p align="center">
-    <img src="res/radix-2screen_positive.jpg" width="400" height="225" />
+<p>
+    <img  class="center" src="res/radix-2screen_positive.jpg" width="400" />
 </p>
 
 Here, the diagram means the following:
@@ -163,8 +163,8 @@ $$
 
 However, it turns out that the second half of our array of $$\omega$$ values is always the negative of the first half, so $$\omega_2^0 = -\omega_2^1$$, so we can use the following butterfly diagram:
 
-<p align="center">
-    <img src="res/radix-2screen.jpg" width="400" />
+<p>
+    <img  class="center" src="res/radix-2screen.jpg" width="400" />
 </p>
 
 With the following equations:
@@ -180,17 +180,17 @@ Now imagine we need to combine more elements.
 In this case, we start with simple butterflies, as shown above, and then sum butterflies of butterflies.
 For example, if we have 8 elements, this might look like this:
 
-<p align="center">
-    <img src="res/radix-8screen.jpg" width="500" height="500" />
+<p>
+    <img  class="center" src="res/radix-8screen.jpg" width="500" />
 </p>
 
 Note that we can perform a DFT directly before using any butterflies, if we so desire, but we need to be careful with how we shuffle our array if that's the case.
 In the code snippet provided in the previous section, the subdivision was performed in the same function as the concatenation, so the ordering was always correct; however, if we were to re-order with bit-reversal, this might not be the case.
 
 For example, take a look at the ordering of FFT ([found on wikipedia](https://en.wikipedia.org/wiki/Butterfly_diagram)) that performs the DFT shortcut:
 
-<p align="center">
-    <img src="res/butterfly_diagram.png" width="600" height="500" />
+<p>
+    <img  class="center" src="res/butterfly_diagram.png" width="600" />
 </p>
 
 Here, the ordering of the array was simply divided into even and odd elements once, but they did not recursively divide the arrays of even and odd elements again because they knew they would perform a DFT soon thereafter.

chapters/data_compression/huffman/huffman.md

@@ -28,8 +28,8 @@ Well, here we build it from the bottom up like so:
 And that's it.
 Here's an image of what this might look like for the phrase `bibbity_bobbity`:
 
-<p align="center">
-    <img src="res/huffman_tree.png" width="500" height="500" />
+<p>
+    <img  class="center" src="res/huffman_tree.png" width="500" />
 </p>
 
 This will create a codebook that looks like this:

chapters/differential_equations/euler/euler.md

@@ -51,7 +51,9 @@ Now, solving this set of equations in this way is known as the *forward* Euler M
 In fact, there is another method known as the [*backward* Euler Method](backward_euler.md), which we will get to soon enough.
 For now, it is important to note that the error of these methods depend on the timestep chosen.
 
-<div style="text-align:center"><img src ="res/error.png" /></div>
+<p>
+    <img  class="center" src="res/error.png" />
+</p>
 
 For example, here we see dramatically different results for different timesteps for solving the ODE $$y' = \frac{x^3}{6}$$, whose solution is $$y = \frac{x^2}{2}$$.
 The blue line is the analytical solution, the green is with a timestep of 0.5 and the red is with a timestep of 1.
@@ -67,7 +69,9 @@ The solution here is $$y(t) = e^{-3t}$$ and we can find this solution somewhat e
 That said, by choosing a larger timestep, we see the Euler method's solution oscillate above and below 0, which should *never* happen.
 If we were to take the Euler method's solution as valid, we would incorrectly assume that $$e^{-3t}$$ will become negative!
 
-<div style="text-align:center"><img src ="res/instability.png" /></div>
+<p>
+    <img  class="center" src="res/instability.png" />
+</p>
 
 Like above, the blue line is the analytical solution, the green is with a timestep of 0.5 and the red is with a tiemstep of 1.
 Here, it's interesting that we see 2 different instability patterns.

chapters/euclidean_algorithm/euclidean.md

@@ -31,8 +31,8 @@ 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:
 
-<p align="center">
-    <img src="res/subtraction.png" width="500" height="500" />
+<p>
+    <img  class="center" src="res/subtraction.png" width="500" />
 </p>
 
 Modern implementations, though, often use the modulus operator (%) like so
@@ -64,8 +64,8 @@ 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:
 
-<p align="center">
-    <img src="res/modulus.png" width="500" height="500" />
+<p>
+    <img  class="center" src="res/modulus.png" width="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/monte_carlo/monte_carlo.md

@@ -13,8 +13,8 @@ Since it's a square, the $$\text{length}$$ and $$\text{width}$$ are the same, so
 If we embed a circle into the square with a radius $$r = \text{length}$$ (shown below), then it's area is $$\text{Area}_{\text{circle}}=\pi r^2$$.
 For simplicity, we can also say that $$\text{Area}_{\text{square}}=4r^2$$.
 
-<p align="center">
-    <img src="res/square_circle.png" width="300"/>
+<p>
+    <img  class="center" src="res/square_circle.png" width="300"/>
 </p>
 
 Now, let's say we want to find the area of the circle without an equation.
@@ -67,8 +67,8 @@ $$
 
 If we use a small number of points, this will only give us a rough approximation, but as we start adding more and more points, the approximation becomes much, much better (as shown below)!
 
-<p align="center">
-    <img src="res/monte_carlo.gif" width="400"/>
+<p>
+    <img  class="center" src="res/monte_carlo.gif" width="400"/>
 </p>
 
 The true power of monte carlo comes from the fact that it can be used to integrate literally any object that can be embedded into the square.

chapters/physics_solvers/verlet/verlet.md

@@ -190,15 +190,19 @@ Both of these methods work simply by iterating timestep-by-timestep and can be w
 {% sample lang="scratch" %}
 ### Scratch
 Submitted by Jie
-![Scratch 2D implementation](code/scratch/verlet_scratch.png)
+<p>
+    <img  class="center" src="code/scratch/verlet_scratch.png" />
+</p>
 Link: [https://scratch.mit.edu/projects/173039394/](https://scratch.mit.edu/projects/173039394/)
 {% sample lang="matlab" %}
 ### Matlab
 [import, lang:"matlab"](code/matlab/verlet.m)
 {% sample lang="LabVIEW" %}
 ### LabVIEW
 Submitted by P. Mekhail
-![Verlet LabVIEW](code/labview/verlet_labview.png)
+<p>
+    <img  class="center" src="code/labview/verlet_labview.png" />
+</p>
 {% sample lang="javascript" %}
 ### JavaScript
 [import, lang:"javascript"](code/javascript/verlet.js)

chapters/principles_of_code/building_blocks/bitlogic.md

@@ -94,27 +94,40 @@ There are more complicated things that can be done with the bitshift operators;
 In addition to the bitshift operations, there are a number of logical operations that can be performed on one or two bits together.
 These operations are called *gates*, and follow soemwhat straightforward logic.
 The *AND* gate, for example, reads in 2 bits and will only output a 1 value if both inputs are 1. This can be seen in the corresponding truth table:
-![AND Truth Table](and.jpg)
+
+<p>
+    <img  class="center" src="res/and.jpg" width="423" />
+</p>
 
 The *OR* gate will output 1 if either input bits are 1:
 
-![OR Truth Table](or.jpg)
+<p>
+    <img  class="center" src="res/or.jpg" width="423" />
+</p>
 
 The *exclusive OR* or *XOR* gate is the same as the *OR* gate, but will not output 1 if both bits are 1:
 
-![XOR Truth Table](xor.jpg)
+<p>
+    <img  class="center" src="res/xor.jpg" width="423" />
+</p>
 
 The *NOT* gate simply flips the input bit:
 
-![NOT Truth Table](not.jpg)
+<p>
+    <img  class="center" src="res/not.jpg" width="423" />
+</p>
 
 By combining the NOT and AND gates, we get the *NAND* gate:
 
-![NAND Truth Table](nand.jpg)
+<p>
+    <img  class="center" src="res/nand.jpg" width="423" />
+</p>
 
 And NOT and OR create *NOR*:
 
-![NOR Truth Table](nor.jpg)
+<p>
+    <img  class="center" src="res/nor.jpg" width="423" />
+</p>
 
 There are a few other gates, but this is enough for most things. We'll add more as the need arises!