“To play life you must have a fairly large checkerboard and a plentiful supply of flat counters of two colors. It is possible to work with pencil and graph paper but it is much easier, particularly for beginners, to use counters and a board.” —Martin Gardner, Scientific American (October 1970)
-
In Chapter 5, I defined a complex system as a network of elements with short-range relationships, operating in parallel, that exhibit emergent behavior. I illustrated this definition by creating a flocking simulation and demonstrated how a complex system ads up to more than the sum of its parts. In this chapter, I’m going to turn to developing other complex systems known as cellular automata.
-
In some respects, this shift may seem like a step backward. No longer will the individual elements of my systems be members of a physics world, driven by forces and vectors to move around the canvas. Instead, I’ll build systems out of the simplest digital element possible: a single bit. This bit is called a cell, and its value (0 or 1) is called its state. Working with such simple elements will help illustrate the details behind how complex systems work, and it will offer an opportunity to elaborate on some programming techniques that apply to code-based projects. Building cellular automata will also set the stage for the rest of the book, where I’ll increasingly focus on systems an algorithms rather than vectors an motion—albeit systems an algorithms that I can and will apply to moving bodies.
+
In Chapter 5, I defined a complex system as a network of elements with short-range relationships, operating in parallel, that exhibit emergent behavior. I illustrated this definition by creating a flocking simulation and demonstrated how a complex system adds up to more than the sum of its parts. In this chapter, I’m going to turn to developing other complex systems known as cellular automata.
+
In some respects, this shift may seem like a step backward. No longer will the individual elements of my systems be members of a physics world, driven by forces and vectors to move around the canvas. Instead, I’ll build systems out of the simplest digital element possible: a single bit. This bit is called a cell, and its value (0 or 1) is called its state. Working with such simple elements will help illustrate the details behind how complex systems operate, and it will offer an opportunity to elaborate on some programming techniques that apply to code-based projects. Building cellular automata will also set the stage for the rest of the book, where I’ll increasingly focus on systems and algorithms rather than vectors and motion—albeit systems and algorithms that I can and will apply to moving bodies.
What Is a Cellular Automaton?
A cellular automaton (cellular automata plural, or CA for short) is a model of a system of “cell” objects with the following characteristics:
@@ -58,7 +58,7 @@
Elementary Cellular Automata
Figure 7.7: Counting with 3 bits in binary, or the eight possible configurations of a three-cell neighborhood
-
Once all the possible neighborhood configurations are defined, an outcome (new state value: 0 or 1) is specified for each configuration. In Wolfram's original notation and other common references, these configurations are written in descending order, Figure 7.8 follows this convention, starting with 111 and counting down to 000.
+
Once all the possible neighborhood configurations are defined, an outcome (new state value: 0 or 1) is specified for each configuration. In Wolfram's original notation and other common references, these configurations are written in descending order. Figure 7.8 follows this convention, starting with 111 and counting down to 000.
Figure 7.8: A ruleset shows the outcome for each possible configuration of three cells.
@@ -107,9 +107,9 @@
Defining Rulesets
Figure 7.16: How the Wolfram website represents a ruleset
-
Figure 7.16 is identified by Wolfram as “Rule 90.” Where does 90 come from? Each ruleset is essentially an 8-bit number. How many combinations of eight 0s and 1s are there? Exactly 2^8, or 256. You might remember this from when you first learned about RGB color in p5.js. When you write background(r, g, b), each color component (red, green, and blue) is represented by an 8-bit number ranging from 0 to 255 in decimal, or 00000000 to 11111111 in binary.
-
To make ruleset naming even more concise, Wolfram uses decimal (or “base 10”) representations. To name a rule, you convert its 8-bit binary number to its decimal counterpart. The binary number “01011010” translates to the decimal number 90, and therefore it’s named “Rule 90.”
-
Since there are 256 possible combinations of eight 0s and 1s, there are also 256 unique rulesets. Let’s check out another one. How about rule 11011110, or more commonly, rule 222. Figure 7.18 shows how it looks.
+
I’ve said that each ruleset can essentially be boiled down to an 8-bit number, and how many combinations of eight 0s and 1s are there? Exactly 2^8, or 256. You might remember this from when you first learned about RGB color in p5.js. When you write background(r, g, b), each color component (red, green, and blue) is represented by an 8-bit number ranging from 0 to 255 in decimal, or 00000000 to 11111111 in binary.
+
The ruleset in Figure 7.16 could be called “Rule 01011010,” but Wolfram instead refers to it as “Rule 90.” Where does 90 come from? To make ruleset naming even more concise, Wolfram uses decimal (or “base 10”) representations rather than binary. To name a rule, you convert its 8-bit binary number to its decimal counterpart. The binary number 01011010 translates to the decimal number 90, and therefore it’s named “Rule 90.”
+
Since there are 256 possible combinations of eight 0s and 1s, there are also 256 unique rulesets. Let’s check out another one. How about rule 11011110, or more commonly, rule 222. Figure 7.17 shows how it looks.
Figure 7.18: A textile cone snail (Conus textile), Cod Hole, Great Barrier Reef, Australia, 7 August 2005. Photographer: Richard Ling richard@research.canon.com.au
-
The result is a recognizable shape, though it certainly isn’t as exciting as the Sierpiński triangle. As I saidd earlier, most of the 256 elementary rulesets dodn’t produce compelling outcomes. However, it’s still quite incredible that even just a few of these rulesets—simple systems of cells with only two possible states—can produce fascinating patterns seen every day in nature (see Figure 7.18, a snail shell resembling Wolfram’s rule 30). This demonstrates how valuable CAs can be in simulation and pattern generation.
+
The result is a recognizable shape, though it certainly isn’t as exciting as the Sierpiński triangle. As I said earlier, most of the 256 elementary rulesets don’t produce compelling outcomes. However, it’s still quite incredible that even just a few of these rulesets—simple systems of cells with only two possible states—can produce fascinating patterns seen every day in nature. For example, see Figure 7.18, a snail shell resembling Wolfram’s rule 30. This demonstrates how valuable CAs can be in simulation and pattern generation.
Before I go too far down the road of characterizing the results of different rulesets, though, let’s look at how to build a p5.js sketch that generates and visualizes a Wolfram elementary CA.
Programming an Elementary CA
You may be thinking: “OK, I’ve got this cell thing. And the cell thing has some properties, like a state, what generation it’s on, who its neighbors are, and where it lives pixel-wise on the screen. And maybe it has some functions, like to display itself and determine its new state.” This line of thinking is an excellent one and would likely lead you to write some code like this:
@@ -167,7 +167,7 @@
Programming an Elementary CA
cells[i] = newstate;
}
I’m fairly close to getting this right, but there are a few issues to resolve. For one, I’m farming out the calculation of a new state value to some function called rules(). Obviously, I’m going to have to write this function, so my work isn’t done, but what I’m aiming for here is modularity. I want a for loop that provides a basic framework for managing any CA, regardless of the specific ruleset. If I want to try different rulesets, I shouldn’t have to touch that framework at all; I can just rewrite the rules() function to compute the new states differently.
-
So I still have the rules() function to write, but more important, I’ve made one minor blunder and one major blunder in the for loop itself. Let’s examine the code more closely.
+
So I still have the rules() function to write, but more important, I’ve made one minor blunder and one major blunder in the for loop itself. Let’s examine the code more closely.
First, notice how easy it is to look at a cell’s neighbors. Because an array is an ordered list of data, I can use the fact that the indices are numbered to know which cells are next to which cells. I know that cell number 15, for example, has cell 14 to its left and 16 to its right. More generally, I can say that for any cell i, its neighbors are i - 1 and i + 1.
In fact, it’s not quite that easy. What have I done wrong? Think about how the code will execute. The first time through the loop, cell index i equals 0. The code wants to look at cell 0’s neighbors. Left is i - 1 or -1. Oops! An array by definition doesn’t have an element with an index of -1. It starts with 0.
I alluded to this problem of edge cases earlier in the chapter and said I could worry about it later. Well, later is now. How should I handle the cell on the edge that doesn’t have a neighbor to both its left and its right? Here are three possible solutions to this problem:
@@ -221,7 +221,7 @@
Programming an Elementary CA
I can store this ruleset in an array.
let ruleset = [0, 1, 0, 1, 1, 0, 1, 0];
-
And then say, for example:
+
And then I can say, for example:
if (a == 1 && b == 1 && c == 1) return ruleset[0];
If left, middle, and right all have the state 1, that matches the configuration 111, so the new state should be equal to the first value in the ruleset array. Duplicating this strategy for all eight possibilities looks like this:
function rules (a, b, c) {
@@ -234,7 +234,7 @@
Programming an Elementary CA
else if (a === 0 && b === 0 && c === 1) return ruleset[6];
else if (a === 0 && b === 0 && c === 0) return ruleset[7];
}
-
I like writing the rules() function this way because it describes line by line exactly what’s happening for each neighborhood configuration. However, it’s not a great solution. After all, what if a CA has four possible states (0 through 3) instead of two? Suddenly there are 64 possible neighborhood configurations. And with 10 possible states, 1,000 configurations. And just imagine programming von Neumann’s 29 possible states. I’d be stuck typing out thousands of else if statements!
+
I like writing the rules() function this way because it describes line by line exactly what’s happening for each neighborhood configuration. However, it’s not a great solution. After all, what if a CA has four possible states (0 through 3) instead of two? Suddenly there are 64 possible neighborhood configurations. And with 10 possible states, 1,000 configurations. And just imagine programming von Neumann’s 29 possible states. I’d be stuck typing out thousands upon thousands of else if statements!
Another solution, though not quite as transparent, is to convert the neighborhood configuration (a 3-bit number) into a regular integer and use that value as the index into the ruleset array. This can be done as follows, using JavaScript’s built-in parseInt() function:
function rules (a, b, c) {
// A quick way to concatenate three numbers into a string
@@ -369,7 +369,7 @@
Example 7.1: Wolfram El
let index = parseInt(s, 2);
return ruleset[7 - index];
}
-
You may have noticed an optimization I made in this example by simplifying the drawing. I included a white background and rendered only the black squares, which saves the work of drawing many squares. This solution isn’t suitable for all cases (what if I want multi-colored cells!), but it provides a performance boost in this simple case. I’ll also note that if the size of each cell were 1 pixel I would not want to use p5.js’s square() function, but rather access the pixel array directly.
+
You may have noticed an optimization I made in this example by simplifying the drawing: I included a white background and rendered only the black squares, which saves the work of drawing many squares. This solution isn’t suitable for all cases (what if I want multicolored cells!), but it provides a performance boost in this simple case. I’ll also note that if the size of each cell were 1 pixel, I wouldn’t want to use p5.js’s square() function, but rather access the pixel array directly.
Exercise 7.1
Expand Example 7.1 to have the following feature: when the CA reaches the bottom of the canvas, the CA starts over with a new, random ruleset.
@@ -428,7 +428,7 @@
The Rules of the Game
Figure 7.26: A two-dimensional CA showing the neighborhood of 9 cells.
-
With three cells, a 3-bit number had eight possible configurations. With nine cells, there are 9 bits, or 512 possible neighborhoods. In most cases, it would be impractical to define an outcome for every single possibility. The Game of Life gets around this problem by defining a set of rules according to general characteristics of the neighborhood: is the neighborhood overpopulated with life, surrounded by death, or just right? Here are the rules of life.
+
With three cells, a 3-bit number had eight possible configurations. With nine cells, there are 9 bits, or 512 possible neighborhoods. In most cases, it would be impractical to define an outcome for every single possibility. The Game of Life gets around this problem by defining a set of rules according to general characteristics of the neighborhood: is the neighborhood overpopulated with life, surrounded by death, or just right? Here are the rules of life:
Death. If a cell is alive (state = 1), it will die (state becomes 0) under the following circumstances:
@@ -450,7 +450,7 @@
The Rules of the Game
Figure 7.27: Example scenarios for “death” and “birth” in the Game of Life
With the elementary CA, I visualized many generations at once, stacked as rows in a 2D grid. With the Game of Life, however, the CA itself is in two dimensions. I could try to create an elaborate 3D visualization of the results and stack all the generations in a cube structure (and in fact, you might want to try this as an exercise), but a more typical way to visualize the Game of Life is to treat each generation as a single frame in an animation. This way, instead of viewing all the generations at once, you see them one at a time, and the result resembles rapidly developing bacteria in a Petri dish.
-
One of the exciting aspects of the Game of Life is that there are known initial patterns that yield intriguing results. For example, the patterns shown in Figure 7.28 some remain static and never change.
+
One of the exciting aspects of the Game of Life is that there are known initial patterns that yield intriguing results. For example, the patterns shown in Figure 7.28 remain static and never change.
Figure 7.28: Initial configurations of cells that remain stable
@@ -582,7 +582,7 @@
The Implementation
}
board = next;
-
Finally, once the next generation is calculated, I can employ the same method used to draw the Wolfram CA—a square for each spot, white for off, black for on. The only new code here is drawing the board!
+
Now I just need to draw the board. I’ll draw a square for each spot: white for off, black for on.
Example 7.2: Game of Life
@@ -598,7 +598,7 @@
Example 7.2: Game of Life
square(i * w, j * w, w);
}
}
-
In this example, I’m introducing yet another method for drawing the squares based on a cell’s state. Remember, multiplying the cell’s state by 255 gives you white for “on” and black for “off”. To invert this, I start with 255 and subtract cell’s state multiplied by 255: black for “on” and white for “off.”
+
In this example, I’m introducing yet another method for drawing the squares based on a cell’s state. Remember, multiplying the cell’s state by 255 gives a white fill color for “on” and black for “off.” To invert this, I start with 255 and subtract cell’s state multiplied by 255: black for “on” and white for “off.”
Exercise 7.6
Create a Game of Life simulation that allows you to manually configure the grid, either by hardcoding initial cell states or by drawing directly to the canvas. Use the simulation to explore some of the known Game of Life patterns.
@@ -683,7 +683,7 @@
Example 7.3: Object-Oriented Ga
}
}
}
-
By transforming the cell into an object, numerous possibilities emerge for enhancing the cell’s properties and behavior. What if each cell had a lifespan property, incrementing with each cycle which influenced its color or shape over time? Imagine if a cell had a terrain property that could be “land”, “water”, “mountain”, or “forest”. How could a two-dimensional CA integrate into a tile-based strategy game or other context?
+
By transforming the cells into objects, numerous possibilities emerge for enhancing the cells’ properties and behaviors. For example, what if each cell had a lifespan property that increments with each cycle and influences its color or shape over time? Or imagine if a cell had a terrain property that could be land, water, mountain, or forest. How could a two-dimensional CA integrate into a tile-based strategy game or other context?
Variations on Traditional CA
Now that I’ve covered the basic concepts, algorithms, and programming strategies behind the most famous 1D and 2D cellular automata, it’s time to think about how you might take this foundation of code and build on it, developing creative applications of CAs in your own work. In this section, I’ll talk through some ideas for expanding the features of a CA. Example answers to these exercises can be found on the book website.
1) Non-rectangular grids. There’s no particular reason why you should limit yourself to having your cells in a rectangular grid. What happens if you design a CA with another type of shape?
@@ -725,7 +725,7 @@
Exercise 7.13
Exercise 7.14
Use CA rules in a flocking system. What if each boid had a state (that perhaps informs its steering behaviors) and its neighborhood changed from frame to frame as it moved closer to or farther from other boids?
-
7) Nesting. As discussed in chapter 5, a feature of complex systems is that they can be nested. A city is a complex system of people, a person is a complex system of organs, an organ is a complex system of cells, and so on and so forth. How could this be applied to CA?
+
7) Nesting. As discussed in Chapter 5, a feature of complex systems is that they can be nested. A city is a complex system of people, a person is a complex system of organs, an organ is a complex system of cells, and so on and so forth. How could this be applied to CA?
Exercise 7.15
Design a CA in which each cell itself is a smaller CA.
@@ -736,7 +736,7 @@
The Ecosystem Project
Incorporate cellular automata into your ecosystem. Some possibilities:
Give each creature a state. How can that state drive their behavior? Taking inspiration from CA, how can that state change over time according to its neighbors’ states?
-
Consider the ecosystem’s world to be a CA. The creatures move from tile to tile, and each tile has a state. I it land? Water? Food?
+
Consider the ecosystem’s world to be a CA. The creatures move from tile to tile, and each tile has a state. Is it land? Water? Food?
Use a CA to generate a pattern for the design of a creature in your ecosystem.
Once upon a time, I took a course in high school called “Geometry.” Perhaps you took such a course too, where you learned about shapes in one, two, and maybe even three dimensions. What’s the circumference of a circle? The area of a rectangle? The distance between a point and a line? This sort of geometry is generally referred to as Euclidean geometry, after the Greek mathematician Euclid, and come to think of it, it’s a subject I’ve been covering all along in this book. Whenever I used vectors to describe the motion of bodies in Cartesian space, that was Euclidean geometry.
For us nature coders, however, I would suggest the question: can our world really be described with Euclidean geometry? The laptop screen I’m staring at right now sure looks like a rectangle. And the plum I ate this morning was spherical. But what if I were to look further, and consider the trees that line the street, the leaves that hang off those trees, the lightning from last night’s thunderstorm, the cauliflower I ate for dinner, the blood vessels in my body, and the mountains and coastlines that define a landscape? As Figure 8.1 shows, most of the stuff you find in nature looks quite different from the idealized geometrical forms of Euclidean geometry.
-
- Figure 8.1
+
+ Figure 8.1: Comparing idealized euclidean geometry to shapes found in nature.
If you want to start building computational designs with patterns that move beyond basic shapes like circle(), square(), and line(), it’s time to learn about a different kind of geometry, the “geometry of nature”: fractals. This chapter will explore the concepts behind fractals and programming techniques for simulating fractal geometry.
What Is a Fractal?
The term fractal (from the Latin fractus, meaning “broken”) was coined by the mathematician Benoit Mandelbrot in 1975. In his seminal work The Fractal Geometry of Nature, he defines a fractal as “a rough or fragmented geometric shape that can be split into parts, each of which is (at least approximately) a reduced-size copy of the whole.”
-
-
- Figure 8.2: One of the most well-known and recognizable fractal patterns is named for Benoit Mandelbrot himself. Generating the Mandelbrot set involves testing the properties of complex numbers after they are passed through an iterative function. Do they tend to infinity? Do they stay bounded? While a fascinating mathematical discussion, this “escape-time” algorithm is a less practical method for generating fractals than the recursive techniques we’ll examine in this chapter. However, an example for generating the Mandelbrot set is included in the code examples.
-
I’ll illustrate this definition with two simple examples. First, think about the branching structure of a tree, as shown in Figure 8.3. (Later in the chapter, I’ll show you how to write the code to draw this tree.)
-
+ Figure 8.3: A branching fractal tree
Notice how the tree has a single trunk with branches connected at its end. Each one of those branches has branches at its end, and those branches have branches, and so on and so forth. And what if you were to pluck one branch from the tree and examine it more closely on its own, as in Figure 8.4?
-
+ Figure 8.4: Zooming in on one branch of the fractal tree
The zoomed-in branch is an exact replica of the whole, just as Mandelbrot describes. Not all fractals have to be perfectly self-similar like this tree, however. For example, take a look at the two illustrations of the coastline of Greenland in Figure 8.5.
-
+ Figure 8.5: Two coastlines of Greenland
The absence of a scale in these illustrations is no accident. Am I showing the entire coastline, or just a small portion of it? There’s no way for you to know without a scale reference because coastlines, as fractals, look essentially the same at any scale. (Incidentally, coastline A shows [TBD] and B zooms into a tiny part of coastline A, showing [TBD]. I’ve added the scales in Figure 8.6)
-
+ Figure 8.6: Two coastlines of Greenland, with scale
-
A coastline is an example of a stochastic fractal, meaning it’s built out of probabilities and randomness. Unlike the deterministic (or predictable) tree-branching structure, a stochastic fractal is statistically self-similar when you consider the data as a whole, if not literally self-similar when you consider the fractal’s actual appearance. The examples in this chapter will explore both deterministic and stochastic techniques for generating fractal patterns.
+
A coastline is an example of a stochastic fractal, meaning it’s built out of probabilities and randomness. Unlike the deterministic (or predictable) tree-branching structure, a stochastic fractal is statistically self-similar. This means that even if a pattern isn’t precisely the same at every size, the general quality of the shape and its overall feel stay the same no matter how much you zoom in or out. The examples in this chapter will explore both deterministic and stochastic techniques for generating fractal patterns.
While self-similarity is a key trait of fractals, it’s important to realize that self-similarity alone doesn’t make a fractal. After all, a straight line is self-similar: it looks the same at any scale, and can be thought of as comprising lots of little lines. But a straight line isn’t a fractal. Fractals are characterized by having a fine structure at small scales (keep zooming into the coastline and you’ll continue to find fluctuations) and can’t be described with Euclidean geometry. As a rule, if you can say “It’s a line!” then it’s not a fractal.
+
+
The Mandelbrot Set
+
+
+
+
+
One of the most well-known and recognizable fractal patterns is named for Benoit Mandelbrot himself. Generating the Mandelbrot set involves testing the properties of complex numbers after they are passed through an iterative function. Do they tend to infinity? Do they stay bounded? While a fascinating mathematical discussion, this “escape-time” algorithm is a less practical method for generating fractals than the recursive techniques we’ll examine in this chapter. However, an example for generating the Mandelbrot set is included in the code examples.
+
Fractals have a long history predating Mandrelbrot’s 1975 book, appearing in various forms across different cultures. They’re virtually as old as nature itself. Indigenous and ancient societies often incorporated fractal patterns into their art, architecture, and textiles, long before the formal study of fractals in Western mathematics.
@@ -54,12 +58,12 @@
What Is a Fractal?
For example, the traditional Ba-ila village layouts of Zambia and the intricate geometric patterns in Islamic architecture both exhibit fractal properties. These patterns highlight the significance of fractals in diverse cultural contexts and underscore their timeless appeal.
Recursion
-
Beyond self-similarity, another fundamental component of fractal geometry is recursion: the repeated application of a rule to successive results, where the output of one application becomes the input for the next application. Recursion has been in the picture since the first appearance of fractals in modern mathematics, when German mathematician George Cantor developed some simple rules for generating an infinite set in 1883. Cantor’s rules are illustrated in Figure 8.7.
+
Beyond self-similarity, another fundamental component of fractal geometry is recursion: the process of repeatedly applying a rule, where the outcome of one iteration becomes the starting point for the next. Recursion has been in the picture since the first appearance of fractals in modern mathematics, when German mathematician George Cantor developed some simple rules for generating an infinite set of numbers in 1883. Cantor’s rules are illustrated in Figure 8.7.
Figure 8.7: Recursive instructions for generating the Cantor set fractal
-
There’s is a feedback loop at work in Cantor’s rules. Take a single line and break it into two. Then return to those two lines and apply the same rule, breaking each line into two. Now you have four. Return to those four lines and apply the rule. Now you have eight. And so on. That’s how recursion works: the output of a process is fed back into the process itself, over and over again. In this case, the result is known as the Cantor set. Like the fractal tree from Figure 8.3, it’s an example of a deterministic, entirely predictable fractal, where each part is a precise replica of the whole.
+
There is a feedback loop at work in Cantor’s rules. Take a single line and break it into two. Then return to those two lines and apply the same rule, breaking each line into two. Now you have four. Return to those four lines and apply the rule. Now you have eight. And so on. That’s how recursion works: the output of a process is fed back into the process itself, over and over again. In this case, the result is known as the Cantor set. Like the fractal tree from Figure 8.3, it’s an example of a deterministic, entirely predictable fractal, where each part is a precise replica of the whole.
Cantor was interested in what happens when you apply a recursive set of rules an infinite number of times. You and I don’t have infinite time on our hands, however. Also, a p5.js sketch is limited to a finite pixel space, so at some point it becomes impossible to draw increasingly smaller lines. As such, for the purposes of this book, I’ll mostly ignore the questions and paradoxes that arise from infinite recursion. Instead, the code will be constructed in such a way that the rules aren’t applied “forever” (resulting in an infinite loop and a frozen computer) but instead stop when a certain condition is met.
Implementing Recursive Functions
In a moment, I’ll write a sketch that recursively implements the Cantor set. but first, what does it mean to have recursion in code? At root, it boils down to calling a function from inside a function. This, in and of itself, isn’t anything new. After all, you probably call functions from inside other functions all the time. For example:
@@ -78,12 +82,12 @@
Implementing Recursive Functions
0! = 1
Here’s a non-recursive function in p5.js that uses a for loop to calculate the factorial of a number:
function factorial(n) {
- let f = 1;
+ let value = 1;
//{!3} Using a regular loop to compute factorial
for (let i = 0; i < n; i++) {
- f = f * (i + 1);
+ value = value * (i + 1);
}
- return f;
+ return value;
}
Upon close examination, you’ll notice something interesting about how factorials work. Think about how 4! and 3! are defined:
4! = 4 \times 3 \times 2 \times 1
@@ -92,22 +96,23 @@
Implementing Recursive Functions
4! = 4 \times 3!
In more general terms, for any positive integer n:
n! = n \times (n-1)!
-
1! = 1
+
0! = 1
Writing this out, I can say that the factorial of n is defined as n times the factorial of n-1.
The definition of factorial includes factorial?!? It’s kind of like defining pizza as “a delicious meal that includes slices of pizza.” While this definition of pizza is admittedly nonsensical, it highlights the concept of self-reference in a definition, the essence of recursion. When applied to a function definition in code, it can lead to remarkably elegant solutions, such as this recursive definition of a factorial() function:
function factorial(n) {
- if (n == 1) {
+ if (n == 0) {
return 1;
} else {
return n * factorial(n - 1);
}
}
-
The factorial() function calls itself within its own definition. It may look a bit odd at first, but it works, as long as there’s a stopping condition (in this case, n == 1) so the function doesn’t get stuck calling itself forever. Figure 8.8 illustrates the steps that unfold when factorial(4) is called.
+
The factorial() function calls itself within its own definition. It may look a bit odd at first, but it works, as long as there’s a stopping condition (in this case, n == 0) so the function doesn’t get stuck calling itself forever. (This implementation, however, assumes you are passing a non-negative numbers as an argument and should probably include additional error checking.)
+
Figure 8.8 illustrates the steps that unfold when factorial(4) is called.
-
- Figure 8.8: Visualizing the process of recursive factorial.
+
+ Figure 8.8: Visualizing the process of recursive factorial, this diagram uses an exit condition of 1 instead of 0 to save a step!
-
The function keeps calling itself, descending deeper and deeper down a rabbit hole of nested function calls until it reaches the stopping condition within factorial(1). Then it works its way back up out of the hole, returning values until it’s back at the original call of factorial(4).
+
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’s arrives back home at the original call of factorial(4).
You can apply the same recursive principle illustrated by the factorial() 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.
Example 8.1: Recursive Circles Once
@@ -126,8 +131,8 @@
Example 8.1: Recursive Circles Once
The drawCircle() function draws a circle based on a set of parameters that it receives as arguments. It then calls itself with those same parameters, adjusting them slightly. The result is a series of circles, each of which is drawn inside the previous circle.
-
Much like the factorial() function stops recursing when n equals 1, notice how drawCircle() only recursively calls itself if the radius is greater than 4. This is a crucial point. As with iteration, all recursive functions must have an exit condition! You’re likely already aware that all for and while loops must include a boolean expression that eventually evaluates to false, thus exiting the loop. Without one, the sketch would get caught inside an infinite loop. The same can be said about recursion. If a recursive function calls itself forever and ever with no exit, you’ll be be treated to a chilly, frozen screen.
-
This circles example is rather trivial; it could easily be achieved through simple iteration with a for or while loop. Things become more interesting, however, when a function is defined to call itself more than once. In such scenarios, recursion becomes wonderfully elegant. To illustrate, I’ll make drawCircle() a bit more complex: for every circle displayed, draw a circle half its size to the left and right of that circle.
+
Much like the factorial() function stops recursing when n equals 0, notice how drawCircle() only recursively calls itself if the radius is greater than 4. This is a crucial point. As with iteration, all recursive functions must have an exit condition! You’re likely already aware that all for and while loops must include a boolean expression that eventually evaluates to false, thus exiting the loop. Without one, the sketch would get caught inside an infinite loop. The same can be said about recursion. If a recursive function calls itself forever and ever with no exit, you’ll be be treated to a chilly, frozen screen.
+
This circles example is rather trivial; it could easily be achieved through simple iteration with a for or while loop. Things become more interesting, however, when a function is defined to call itself more than once. In such scenarios, recursion becomes wonderfully elegant. To illustrate, I’ll make drawCircle() a bit more complex: for every circle displayed, draw two more circles inside it, half its size: one left of center and one right of center.
Example 8.2: Recursion Circles Twice
@@ -155,7 +160,7 @@
Example 8.2: Recursion Circles Twice
drawCircle(x - radius / 2, y, radius / 2);
}
}
-
Two more lines of code, and there are circles above and below each other circle.
+
Two more lines of code, and now each circle contains four circles—left, right, above and below its center.
Example 8.3: Recursive Circles Four Times
@@ -197,12 +202,13 @@
Drawing the Cantor Set with Recur
function cantor(x, y, length) {
line(x, y, x + length, y);
- y += 20;
//{.bold} From start to 1/3rd
- line(x, y, x + length / 3, y);
+ line(x, y + 20, x + length / 3, y + 20);
//{!1 .bold} From 2/3rd to end
- line(x + (2 * length) / 3, y, x + length, y);
-}
+ line(x + (2 * length) / 3, y + 20, x + length, y + 20);
+}
+
+
Figure 8.11 shows the result.
@@ -210,11 +216,11 @@
Drawing the Cantor Set with Recur
This works over two generations, but continuing to call line() manually will get unwieldy quite quickly. For the succeeding generations, I'd need four, then eight, then sixteen calls to line(). A for loop is the usual way around such a problem, but give that a try and you’ll see that working out the math for each iteration quickly proves inordinately complicated. Don’t despair, however: here’s where recursion comes to the rescue!
Take a look at where I draw the first line of the second generation, from the start to the one-third mark:
-
line(x, y, x + length / 3, y);
-
Instead of calling the line() function directly, why not call the cantor() function itself? After all, what does the cantor() function do? It draws a line at an (x,y) position with a given length. In this case, x and y can stay the same, and the length is length / 3.
-
cantor(x, y, length / 3);
-
This call to cantor() is precisely equivalent to the earlier call to line(). And for the second line in the second generation, I can call cantor() again:
-
cantor(x + (2 * length / 3), y, length / 3);
+
line(x, y + 20, x + length / 3, y + 20);
+
Instead of calling the line() function directly, why not call the cantor() function itself? After all, what does the cantor() function do? It draws a line at an (x,y) position with a given length. The x value stays the same, y increments by 20 , and the length is length / 3.
+
cantor(x, y + 20, length / 3);
+
This call to cantor() is precisely equivalent to the earlier call to line(). And for the next line in the second generation, I can call cantor() again:
+
cantor(x + (2 * length / 3), y + 20, length / 3);
Now the cantor() function looks like this:
function cantor(x, y, length) {
line(x, y, x + len, y);
@@ -222,7 +228,7 @@
Drawing the Cantor Set with Recur
cantor(x, y + 20, length / 3);
cantor(x + (2 * length / 3), y + 20, length / 3);
}
-
Since the cantor() function is now recursive, the same rule will be applied to the next lines and to the next and to the next as cantor() calls itself again and again! But don’t go running this code quite yet. The sketch is missing that crucial element: an exit condition. You’ll want to make sure to stop recursing at some point. For example, I’ll choose to stop if the length of the line ever is less than 1 pixel.
+
Since the cantor() function is now recursive, the same rule will be applied to the next lines and to the next and to the next as cantor() calls itself again and again! But don’t go running this code quite yet. The sketch is missing that crucial element: an exit condition. It’s got to stop recursing at some point. Here, I’ll choose to stop if the length of the line is less than or equal to one pixel. In other words, keep going if length is greater than one.
Example 8.4: The Cantor Set
@@ -231,24 +237,24 @@
Example 8.4: The Cantor Set
function cantor(x, y, length) {
- //{!1} Stop at 1 pixel!
+ //{!1} Keep going as long as the length is greater than 1
if (length > 1) {
line(x, y, x + length, y);
cantor(x, y + 20, length / 3);
cantor(x + (2 * length) / 3, y + 20, length / 3);
}
}
+
Writing a function that recursively calls itself is a simple, elegant technique for generating a fractal pattern, but it doesn’t allow me to do much beyond drawing the pattern itself. For example, what if I wanted the lines in the above Cantor set to exist as individual objects that could be moved independently? For that, I’ll need to use a different programming approach, one that applies recursion in combination with an array that keeps track of all its individual parts. That’s exactly what I’ll do next!
Exercise 8.1
-
Using Examples 8.3 and 8.4 as a model, design your own recursive pattern. Here is an example of one using lines.
+
Using Examples 8.2 and 8.3 as a model, design your own recursive pattern. Here is an example of one using lines.
The Koch Curve
-
Writing a function that recursively calls itself is a simple, elegant technique for generating a fractal pattern, but it doesn’t allow me to do much beyond drawing the pattern itself. For example, what if I wanted the lines in the above Cantor set to exist as individual objects that could be moved independently? For that, I’ll need to use a different programming approach, one that applies recursion in combination with an array that keeps track of all its individual parts.
-
To demonstrate this technique, I’ll now turn another famous fractal pattern, the Koch curve, discovered in 1904 by Swedish mathematician Helge von Koch. Figure 8.12 outlines the rules for drawing this fractal. Notice that the rules start the same way as the Cantor set, with a single line that’s then divided into three equal parts.
+
I’ll now turn another famous fractal pattern, the Koch curve, discovered in 1904 by Swedish mathematician Helge von Koch. Figure 8.12 outlines the rules for drawing this fractal. Notice that the rules start the same way as the Cantor set, with a single line that’s then divided into three equal parts.
Figure 8.12: The rules for drawing the Koch curve
@@ -366,10 +372,10 @@
The “Monster” Curve
return this.end.copy();
}
-
How about points b and d? Pointb is one-third of the way along the line segment, and d is two-thirds of the way along. As Figure 8.16 shows, If I create a vector \vec{v} that points from the original a to b, I can find the new points by scaling its magnitude it to one-third for the new b and two-thirds for the new d.
+
How about points b and d? Pointb is one-third of the way along the line segment, and d is two-thirds of the way along. As Figure 8.16 shows, If I create a vector \vec{v} that points from the original \text{start} to \text{end}, I can find the new points by scaling its magnitude it to one-third for the new b and two-thirds for the new d.
-
- Figure 8.16
+
+ Figure 8.16: The original line expressed as a vector \vec{v} can be divided by 3 to find the positions of the points for the next generation.
Here’s how that looks in code:
kochB() {
@@ -391,11 +397,11 @@
The “Monster” Curve
return d;
}
-
- Figure 8.17
+
+ Figure 8.17: The vector \vec{v} is rotated by 60° to find the third point.
The last point, c, is the most difficult one to compute. However, if you consider that the angles of an equilateral triangle are all 60 degrees, this makes things suddenly easier. If you know how to find the new b with a vector one-third the length of the line, what if you rotate that same vector 60 degrees (or \pi/3 radians) and add it to b? You’d then have arrived at c!
-
kochC() {
+
kochC() {
//{!1} Start at the beginning.
let c = this.start.copy();
@@ -432,6 +438,8 @@
Example 8.5: The Koch Curve
generate();
}
}
+
In this example, I chose to call generate() five times. Each time the Koch rules are applied, the number of line segments grows exponentially. It’s an arbitrary decision, but after five iterations there are 1,024 segments, a considerable amount of detail to see the pattern!
+
You could, however, choose to use the approach taken in previous examples, where a threshold is set for the minimum segment length and generate() is called until the segments become too small. Alternatively, you might consider an interactive option with a button that advances the shape to the next generation with each press.
Exercise 8.2
Draw the Koch snowflake, which consists of three Koch curves arranged in a triangle. Or draw some other variation of the Koch curve.
@@ -524,7 +532,7 @@
The Deterministic Version
branch();
pop();
}
-
Notice how I use push() and pop() around each pair of calls to rotate() and branch(). This is one of those elegant code solutions that feels like magic. Each call to branch() takes a moment to remember the position of that particular branch. If you turn yourself into p5.js for a moment and try to follow the recursive function with pencil and paper, you’ll notice that you end up drawing all of the branches to the right first. At the very end of the right side, pop() will send you back along all of the branches drawn to populate the branches to the left.
+
Notice how I use push() and pop() around each pair of calls to rotate() and branch(). This is one of those elegant code solutions that feels like magic. Before each subsequent call to branch(), the code takes a moment to remember that branch’s starting position, so it can come back to it later. If you turn yourself into p5.js for a moment and try to follow the recursive function with pencil and paper, you’ll notice that you end up drawing all of the branches to the right first. At the very end of the right side, pop() will send you back along all of the branches that were drawn, so that you can populate the branches to the left.
Exercise 8.6
@@ -539,7 +547,7 @@
Exercise 8.6
line(0, 0, 0, -len);
translate(0, -len);
- //{!1} Each branch’s length shrinks by two-thirds.
+ //{!1} Each branch’s length shrinks by one-third.
len *= 0.67;
if (len > 2) {
@@ -580,6 +588,7 @@
Example 8.6: A Recursive Tree
strokeWeight(2);
branch(80);
}
+
The recursive branch() function provides a clean and elegant way of drawing the tree with very few lines of code. However, this approach constrains the potential for animation. By adopting the methodology used in the Koch curve, where each segment is stored as an object in an array, you can explore creative ways to animate the tree’s growth of or even apply physics to the branches!
Exercise 8.7
Vary the strokeWeight() for each branch. Make the trunk thick and each subsequent branch thinner.
@@ -590,14 +599,14 @@
Exercise 8.7
Exercise 8.8
-
The tree structure could also be generated using an array of objects, the technique demonstrated with the Koch curve. Re-create the tree using a Branch class and an array to keep track of the branches. (Hint: you’ll want to keep track of the branch directions and lengths using vector math instead of p5.js transformations.) Once you have the tree built with an array of Branch objects, can you animate the tree’s growth? What about drawing leaves at the end of the branches?
+
Re-create the tree using a Branch class and an array to keep track of the branches. (Hint: you’ll want to keep track of the branch directions and lengths using vector math instead of p5.js transformations.) Can you animate the tree’s growth? What about drawing leaves at the end of the branches?
The Stochastic Version
-
At first glance (and with the right angle), it may look like I’ve drawn a convincing tree in the previous example, but on closer inspection, the result is a little too perfect. Take a look outside at a real tree and you’ll notice that the branch lengths and angles vary from branch to branch, not to mention the fact that not all branches split off into exactly two smaller branches. Fractal trees are a nice example of a scenario where adding a little bit of randomness can make the result look more natural. That bit of randomness also transforms the fractal from deterministic to stochastic—the exact outcome will be different from drawing to drawing, while still retaining the overall characteristics of a branching, tree-like structure.
+
At first glance (and with the right angle), it may look like I’ve drawn a convincing tree in the previous example, but on closer inspection, the result is a little too perfect. Take a look outside at a real tree and you’ll notice that the branch lengths and angles vary from branch to branch, not to mention the fact that not all branches split off into exactly two smaller branches. Fractal trees are a great example of how adding a touch of randomness can make the end result look more natural. That bit of randomness also transforms the fractal from deterministic to stochastic—the exact outcome will be different from drawing to drawing, while still retaining the overall characteristics of a branching, tree-like structure.
First, how about randomizing the angle for each branch? This is a pretty easy one to do just by adding random().
//{!1} Pick a random angle between 0 and PI/3 for each branch.
let angle = random(0, PI / 3);
@@ -638,7 +647,7 @@
Exercise 8.10
Use toxiclibs.js to simulate tree physics. Each branch of the tree could be two particles connected with a spring. How can you get the tree to stand up and not fall down?
L-systems
-
In 1968, Hungarian botanist Aristid Lindenmayer developed a grammar-based system to model the growth patterns of plants. L-systems (short for Lindenmayer systems) can be used to generate the recursive fractal patterns demonstrated so far in this chapter. They’re additionally useful because they provide a mechanism for using simple symbols to keep track of fractal structures that require complex and multifaceted production rules.
+
In 1968, Hungarian botanist Aristid Lindenmayer developed a grammar-based system to model the growth patterns of plants. This system makes use of textual symbols and a specific set of rules to generate patterns, much like how grammar in language uses words and rules to construct sentences. Known as L-systems (short for Lindenmayer systems) can be used to generate the recursive fractal patterns demonstrated so far in this chapter. They’re additionally useful because they provide a mechanism for using simple symbols to keep track of fractal structures that require complex and multifaceted production rules.
Implementing an L-system in p5.js requires working with (a) recursion, (b) transformations, and (c) strings of text. This chapter already covers recursion and transformations, but strings are new. Here’s a quick snippet of code demonstrating the three aspects of working with text important to L-systems: creating, concatenating, and iterating over strings. You can refer to the book website for additional string resources and tutorials.
// A string is created as text between quotes (single or double).
let message1 = "Hello!";
@@ -687,10 +696,10 @@
L-systems
for (let i = 0; i < current.length; i++) {
let c = current.charAt(i);
//{!1} Production rule A --> AB
- if (c === 'A') {
+ if (c === "A") {
next += "AB";
//{!1} Production rule B --> A
- } else if (c === 'B') {
+ } else if (c === "B") {
next += "A";
}
}
@@ -908,17 +917,17 @@
Example 8.8: Simple L-sy
-
The sketch available for download on the book’s website takes all of the L-system code provided in this section and organizes it into three classes:
+
The sketch available for download on the book’s website takes all of the L-system code provided in this section and organizes it into three elements:
-
Rule: A class that stores the predecessor and successor strings for an L-system rule.
-
LSystem: A class to iterate a new L-system generation (as demonstrated with the StringBuffer technique).
+
rules: A JavaScript object that stores pairs of predecessor and successor strings for an L-system rule.
+
LSystem: A class to iterate a new L-system generation.
Turtle: A class to manage reading the L-system sentence and following its instructions to draw on the screen.
I won’t write out these classes here, since they simply duplicate the code I’ve already worked out in this chapter. Instead, I’ll show how all the elements come together in the main sketch.js file.
Example 8.9: An L-System
-
+
@@ -941,7 +950,7 @@
Example 8.9: An L-System
lsystem.generate();
}
- //{!2 .offset} The Turtle object is a length and angle.
+ //{!2 .offset} The Turtle object has a length and angle.
turtle = new Turtle(4, radians(25));
}
@@ -952,9 +961,11 @@
Example 8.9: An L-System
// Ask the turtle engine to render the sentence.
turtle.render(lsystem.sentence);
}
+
Throughout this book, I have extensively covered object-oriented programming in the context of classes such as Particle and p5.Vector. However, in Example 8.9, you may have noticed a shortcut I took when initializing the rules variable. Instead of defining a Rule class and invoking a constructor with the new keyword, the variable is initialized with what is called an "object literal."
+
A JavaScript object literal stores a collection of key-value pairs, a convenient way to define transformation rules for an L-System. The key, in this case "F", serves as a unique identifier, and the value, "FF+[+F-F-F]-[-F+F+F]", is the data associated with that key. The key represents the character in the current generation that needs to be replaced, and the value defines what it should be replaced with. Another way to think of it is as a simple dictionary or lookup table. Although this example only has one rule, an object literal can contain multiple key-value pairs separated by commas, as well as nested objects and functions as values.
Exercise 8.11
-
Use an L-system as a set of instructions for creating objects stored in an array. Use trigonometry and vector math to perform the rotations instead of matrix transformations (much like I did with the Koch curve example).
+
Use an L-system as a set of instructions for creating objects stored in an array. Use trigonometry and vector math to perform the rotations instead of transformations (much like I did with the Koch curve example).
Exercise 8.12
diff --git a/content/examples/08_fractals/example_8_9_l_system/index.html b/content/examples/08_fractals/example_8_9_l_system/index.html
new file mode 100644
index 00000000..2b47ae34
--- /dev/null
+++ b/content/examples/08_fractals/example_8_9_l_system/index.html
@@ -0,0 +1,13 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/content/examples/08_fractals/example_8_9_l_system/lsystem.js b/content/examples/08_fractals/example_8_9_l_system/lsystem.js
new file mode 100644
index 00000000..7edbe9ae
--- /dev/null
+++ b/content/examples/08_fractals/example_8_9_l_system/lsystem.js
@@ -0,0 +1,34 @@
+// The Nature of Code
+// Daniel Shiffman
+// http://natureofcode.com
+
+// An LSystem has a starting sentence
+// An a ruleset
+// Each generation recursively replaces characters in the sentence
+// Based on the ruleset
+
+// Construct an LSystem with a starting sentence and a ruleset
+class LSystem {
+ constructor(axiom, rules) {
+ this.sentence = axiom; // The sentence (a String)
+ this.ruleset = rules; // The ruleset (an array of Rule objects)
+ }
+
+ // Generate the next generation
+ generate() {
+ // An empty string that we will fill
+ let nextgen = "";
+ // For every character in the sentence
+ for (let i = 0; i < this.sentence.length; i++) {
+ // What is the character
+ // We will replace it with itself unless it matches one of our rules
+ let c = this.sentence.charAt(i);
+ let next = this.ruleset[c] || c;
+ // Append replacement String
+ nextgen += next;
+ }
+ // Replace sentence
+ this.sentence = nextgen;
+ }
+
+}
\ No newline at end of file
diff --git a/content/examples/08_fractals/example_8_9_l_system/screenshot.png b/content/examples/08_fractals/example_8_9_l_system/screenshot.png
new file mode 100644
index 00000000..4903579d
Binary files /dev/null and b/content/examples/08_fractals/example_8_9_l_system/screenshot.png differ
diff --git a/content/examples/08_fractals/example_8_9_l_system/sketch.js b/content/examples/08_fractals/example_8_9_l_system/sketch.js
new file mode 100644
index 00000000..4963b16a
--- /dev/null
+++ b/content/examples/08_fractals/example_8_9_l_system/sketch.js
@@ -0,0 +1,41 @@
+// The Nature of Code
+// Daniel Shiffman
+// http://natureofcode.com
+
+let lsystem;
+let turtle;
+
+function setup() {
+ createCanvas(640, 240);
+
+ let rules = {
+ F: "FF+[+F-F-F]-[-F+F+F]",
+ };
+ lsystem = new LSystem("F", rules);
+ turtle = new Turtle(4, radians(25));
+
+ for (let i = 0; i < 4; i++) {
+ lsystem.generate();
+ }
+
+ // Some other rules
+ // let ruleset = {
+ // F: "F[F]-F+F[--F]+F-F",
+ // };
+ // lsystem = new LSystem("F-F-F-F", ruleset);
+ // turtle = new Turtle(4, PI / 2);
+
+ // let ruleset = {
+ // F: "F--F--F--G",
+ // G: "GG",
+ // };
+ // lsystem = new LSystem("F--F--F", ruleset);
+ // turtle = new Turtle(8, PI / 3);
+}
+
+function draw() {
+ background(255);
+ translate(width / 2, height);
+ turtle.render(lsystem.sentence);
+ noLoop();
+}
\ No newline at end of file
diff --git a/content/examples/08_fractals/example_8_9_l_system/style.css b/content/examples/08_fractals/example_8_9_l_system/style.css
new file mode 100644
index 00000000..130b7d69
--- /dev/null
+++ b/content/examples/08_fractals/example_8_9_l_system/style.css
@@ -0,0 +1,7 @@
+html, body {
+ margin: 0;
+ padding: 0;
+}
+canvas {
+ display: block;
+}
diff --git a/content/examples/08_fractals/example_8_9_l_system/turtle.js b/content/examples/08_fractals/example_8_9_l_system/turtle.js
new file mode 100644
index 00000000..ea1ee08c
--- /dev/null
+++ b/content/examples/08_fractals/example_8_9_l_system/turtle.js
@@ -0,0 +1,29 @@
+// The Nature of Code
+// Daniel Shiffman
+// http://natureofcode.com
+
+class Turtle {
+ constructor(length, angle) {
+ this.length = length;
+ this.angle = angle;
+ }
+
+ render(sentence) {
+ stroke(0);
+ for (let i = 0; i < sentence.length; i++) {
+ let c = sentence.charAt(i);
+ if (c === "F" || c === "G") {
+ line(0, 0, 0, -this.length);
+ translate(0, -this.length);
+ } else if (c === "+") {
+ rotate(this.angle);
+ } else if (c === "-") {
+ rotate(-this.angle);
+ } else if (c === "[") {
+ push();
+ } else if (c === "]") {
+ pop();
+ }
+ }
+ }
+}
\ No newline at end of file
diff --git a/content/images/08_fractals/08_fractals_2.png b/content/images/08_fractals/08_fractals_2.png
index fa61f18f..716e59ed 100644
Binary files a/content/images/08_fractals/08_fractals_2.png and b/content/images/08_fractals/08_fractals_2.png differ
diff --git a/content/images/08_fractals/08_fractals_3.png b/content/images/08_fractals/08_fractals_3.png
index 716e59ed..ed4b15d0 100644
Binary files a/content/images/08_fractals/08_fractals_3.png and b/content/images/08_fractals/08_fractals_3.png differ
diff --git a/content/images/08_fractals/08_fractals_4.png b/content/images/08_fractals/08_fractals_4.png
index ed4b15d0..0e417062 100644
Binary files a/content/images/08_fractals/08_fractals_4.png and b/content/images/08_fractals/08_fractals_4.png differ
diff --git a/content/images/08_fractals/08_fractals_5.png b/content/images/08_fractals/08_fractals_5.png
index 0e417062..65e9e59f 100644
Binary files a/content/images/08_fractals/08_fractals_5.png and b/content/images/08_fractals/08_fractals_5.png differ
diff --git a/content/images/08_fractals/08_fractals_6.png b/content/images/08_fractals/08_fractals_6.png
index 65e9e59f..fa61f18f 100644
Binary files a/content/images/08_fractals/08_fractals_6.png and b/content/images/08_fractals/08_fractals_6.png differ
- 
- 
+ 
+ 
+ 
+ 
@@ -54,12 +58,12 @@ 
- 
@@ -210,11 +216,11 @@ 
- 
- 
