Notion - Update docs

content/06_libraries.html

@@ -1051,7 +1051,7 @@ function mousePressed() {
 <p>I’ve managed to get most of the way through this material related to physics simulation without really needing to dive into calculus. As I wrap up the first half of this book, however, it’s worth taking a moment to examine the calculus behind what I’ve been demonstrating and how it relates to the methodology in certain physics libraries (like Box2D, Matter.js, and the upcoming Toxiclibs.js). This way, you’ll know what to say at the next cocktail party when someone asks you about integration.</p>
 <p>I’ll begin with a question: “What does integration have to do with position, velocity, and acceleration?” To answer, I should first define <strong>differentiation</strong>, the process of finding a derivative. The <strong>derivative</strong> of a function is a measure of how a function changes over time. Consider position and its derivative. Position is a point in space, while velocity is the change in position over time. Therefore, velocity can be described as the derivative of position. And what’s acceleration? The change in velocity over time. Acceleration is the derivative of velocity.</p>
 <p><strong>Integration</strong>, the process of finding an integral, is the inverse of differentiation. For example, the <strong>integral</strong> of an object’s velocity over time tells us the object’s new position when that time period ends. Position is the integral of velocity, and velocity is the integral of acceleration.</p>
-<p>Since the physics simulations in this book are founded on the notion of calculating acceleration based on forces, integration is needed to figure out the object’s location after a certain period of time (like one cycle of the <code>draw()</code> loop). In other words, you’ve been doing integration all along! It looks like this:</p>
+<p>Since the physics simulations in this book are founded on the notion of calculating acceleration based on forces, integration is needed to figure out the object’s location after a certain period of time (like one cycle of the <code>draw()</code> loop). In other words, you’ve been doing integration all along! It looks like the following.</p>
 <pre class="codesplit" data-code-language="javascript">velocity.add(acceleration);
 position.add(velocity);</pre>
 <p>This methodology is known as <strong>Euler integration</strong>, or the Euler method (named for the mathematician Leonhard Euler, pronounced <em>Oiler</em>). It’s essentially the simplest form of integration and is very easy to implement in code—just two lines! However, while it’s computationally simple, it’s by no means the most accurate or stable choice for certain types of simulations.</p>
@@ -1215,7 +1215,7 @@ a.normalize();</code></pre>
 <h3 id="the-physics-world">The Physics World</h3>
 <p>The classes to describe the world and its particles and springs in Toxiclibs.js are found in <code>toxi.physics2d.</code> I’m also going to use a <code>Rect</code> object (to describe a generic rectangle boundary) and <code>GravityBehavior</code> to apply a global gravity force to the world. Including <code>Vec2D</code>, I now have all the following class aliases:</p>
 <pre class="codesplit" data-code-language="javascript">
-// The necessary geometry classes for vectors and rectangles
+// The necessary geometry classes: vectors, rectangles
 let { Vec2D, Rect } = toxi.geom;
 // Alias the important classes from <code>toxi.physics2d</code>.
 let { VerletPhysics2D, VerletParticle2D, VerletSpring2D } = toxi.physics2d;
@@ -1226,7 +1226,7 @@ let { GravityBehavior } = toxi.physics2d.behaviors;</pre>
   <pre class="codesplit" data-code-language="javascript">let physics;
 
 function setup() {
-  // Create a Toxiclibs.js Verlet physics world.
+  // Create a Toxiclibs world.
   physics = new VerletPhysics2D();</pre>
 </div>
 <p>Once I have the <code>VerletPhysics</code> world, I can set global properties. For example, if I want hard boundaries beyond which particles can’t travel, I can provide rectangular bounds:</p>

content/07_ca.html

@@ -27,11 +27,11 @@
   <li>Each cell has a <strong>neighborhood</strong>. This can be defined in any number of ways, but it’s typically all the cells adjacent to that cell.</li>
 </ul>
 <p>It’s important to stress that the cells in a CA don’t refer to biological cells (although you’ll see how CA can mimic lifelike behavior and have applications in biology). Instead, they simply represent discrete units in a grid, similar to the cells in a spreadsheet (as in Microsoft Ex<em>cel</em>). Figure 7.1 illustrates a CA and its various characteristics.</p>
+<p>The second CA feature I listed—the idea that a cell’s state can vary over time—is an important new development. So far in this book, the objects (movers, particles, vehicles, boids, bodies) have generally existed in only one state. They might have moved with sophisticated behaviors and physics, but ultimately they remained the same type of object over the course of their digital lifetime. I’ve alluded to the possibility that these entities can change over time (for example, the weights of steering “desires” can vary), but I haven’t fully put this into practice. Now, with CA, you’ll see how an object’s state can change based on a system of rules.</p>
 <figure>
   <img src="images/07_ca/07_ca_2.png" alt="Figure 7.1: A 2D grid of cells, each with a state of on or off. A neighborhood is a subsection of the large grid, usually consisting of all the cells adjacent to a given cell (circled).">
   <figcaption>Figure 7.1: A 2D grid of cells, each with a state of <em>on</em> or <em>off</em>. A neighborhood is a subsection of the large grid, usually consisting of all the cells adjacent to a given cell (circled).</figcaption>
 </figure>
-<p>The second CA feature I listed—the idea that a cell’s state can vary over time—is an important new development. So far in this book, the objects (movers, particles, vehicles, boids, bodies) have generally existed in only one state. They might have moved with sophisticated behaviors and physics, but ultimately they remained the same type of object over the course of their digital lifetime. I’ve alluded to the possibility that these entities can change over time (for example, the weights of steering “desires” can vary), but I haven’t fully put this into practice. Now, with CA, you’ll see how an object’s state can change based on a system of rules.</p>
 <p>The development of CA systems is typically attributed to Stanisław Ulam and John von Neumann, who were both researchers at the Los Alamos National Laboratory in New Mexico in the 1940s. Ulam was studying the growth of crystals, and von Neumann was imagining a world of self-replicating robots. You read that right: robots that can build copies of themselves.</p>
 <p>Von Neumann’s original cells had 29 possible states, so perhaps the idea of self-replicating robots is a bit too complex of a starting point. Instead, imagine a row of dominoes; each domino can be in one of two states: standing upright (1) or knocked down (0). Just as dominoes react to their neighboring dominoes, the behavior of each cell in a CA is influenced by the states of its neighboring cells.</p>
 <p>This chapter explores how even the most basic rules of something like dominoes can lead to a wide array of intricate patterns and behaviors, similar to natural processes like biological reproduction and evolution. Von Neumann’s work in self-replication and CA is conceptually similar to what’s probably the most famous CA, the Game of Life, which I’ll discuss in detail later in the chapter.</p>

content/08_fractals.html

@@ -118,11 +118,11 @@
   }
 }</pre>
 <p>The <code>factorial()</code> function calls itself within its own definition. It may look a bit odd at first, but it works, as long as a stopping condition exists (in this case, <code>n &#x3C;= 1</code>) so the function doesn’t get stuck calling itself forever. (I’m using <code>&#x3C;=</code> instead of <code>===</code> as a safeguard against infinite recursion, but I should probably include additional error checking to manage noninteger or negative inputs to be more mathematically accurate.) Figure 8.7 illustrates the steps that unfold when <code>factorial(4)</code> is called.</p>
-<p>The function keeps calling itself, descending deeper and deeper down a rabbit hole of nested function calls until it reaches the stopping condition. Then it works its way up out of the hole, returning values until it arrives back home at the original call of <code>factorial(4)</code>.</p>
 <figure>
   <img src="images/08_fractals/08_fractals_9.png" alt="Figure 8.7: Visualizing the process of calling the recursive factorial() function">
   <figcaption>Figure 8.7: Visualizing the process of calling the recursive <code>factorial()</code> function</figcaption>
 </figure>
+<p>The function keeps calling itself, descending deeper and deeper down a rabbit hole of nested function calls until it reaches the stopping condition. Then it works its way up out of the hole, returning values until it arrives back home at the original call of <code>factorial(4)</code>.</p>
 <p>You can apply the same recursive principle illustrated by the <code>factorial()</code> function to graphics in a canvas, only instead of returning values, you draw shapes. This is precisely what you’ll see in the examples throughout this chapter. To begin, here’s a simple recursive function that draws increasingly smaller circles.</p>
 <div data-type="example">
   <h3 id="example-81-recursive-circles-once">Example 8.1: Recursive Circles Once</h3>