Tutorial 2: Hill Climbing |
Next we'll create a complete project, built up stage by stage, with each step explained along the way. If you have some experience with StarLogoT, or programming in general, you might want to grab some pre-existing model and starting tinkering with it. (Two classic beginner's models are "Virus" and "Fire." Work with one of them to create a new sub-model by changing which variables have sliders, by introducing new factors to the project, etc. Check the Info windows, under "Extending the Model" for more details.)
To creat a new project, select "New" from the "File" menu. Then start your model by creating a once-button called "setup." This button will initialize your project and prepare StarLogoT for what's to come. You create this button by clicking on the blue button icon on the StarLogoT toolbar, and then clicking and dragging where you want the button to be on the Interface window. Release the mouse button to create your button and open a window giving values for the button's attributes. Type "setup" in the 'StarLogoT Instruction box and press OK.
Then go to the Procedures window, and create the setup procedure like this:
To review this command one line at a time:
ca is short for clearall (another acceptable StarLogoT primitive that does the same thing). This command blanks out the screen, initialize your variables to 0, and kills all turtles. Basically ca wipes the slate clean for a new run of the project.
crt 100 then creates 100 turtles. Each turtle begins at the origin (location 0,0), which is why you seem to see one turtle and not the full 100. They're stacked on top of each other; many turtles share the same patch. Each newly created turtle has its own color and heading. These attributes are fairly evenly distributed through the range of StarLogoT colors (for color), and around the circle (for heading).
Finally, fd (random screen-edge-x) is really a combination of two commands. Each turtle first evaluates the line random screen-edge-x which returns a random value between 0 and "screen-edge-x" (whatever the dimension of your screen are, maybe 50 or so). Each then goes fd this number of steps.
Press your "setup" button after the code is done. The turtles quickly spread in a rough circle.
Notice the density distribution of the turtles in the Graphics window. Press "setup" a few more times and watch the turtles' arrangement change. When you're satisfied that the button does what you want (you want the turtles to be somewhere on the screen, right?), it's time to write your next procedure.
Make a forever-button called "go" by creating a button and checking the Forever box in the Creation dialog box.
Then write its procedure:
Pretty neat, huh? But what does move-turtles do? Is it a primitive, like fd is? No, it's a procedure that you're about to write, right after the go procedure listing:
Let's review it line by line:
seth (random 360) is another two-step command. First, each turtle picks a random integer between 0 and 359 (random doesn't include the number you give it). Then it sets its heading to be this number. Heading is measured in degrees starting with 0 degrees at 12:00 and running clockwise around the circle.
After each turtle does that, it moves forward one step in this new direction.
What about the comma? The comma that follows "move-turtles" in the procedure go is another StarLogoT command that tells StarLogoT to pause there until all turtles have finished the move-turtles procedure. You can read about the comma command in greater detail in The StarLogoT Development Reference Manual. For now, know that it is important to place commas anywhere in the code where turtles might get ahead of other turtles, in terms of code execution, but when it is important to keep everything synchronized.
Why couldn't we have just written that in go? Because as you build your project, the model's control structure is likely to change many times. go is this main control structure. (This isn't a requirement for StarLogoT programs, but it's a convention we follow.) We'd like to keep go as simple as possible so it's easy to understand. (And it's just good programming, darn it!)
The "go" button is a forever-button, which means it executes its code continually until you shut it off by clicking it again. After pressing "setup" once to ensure there are turtles to move around, press the "go" button. Watch what happens. Turn it off, and watch the turtles stop in their tracks.
You can take it from here and experiment with other turtle commands. Type commands in the Command window (like setc red), or add them to setup, go, or move-turtles. You might try typing pendown in the Command window or changing seth (random 360) to lt (random 45). Or, instead of saying crt 100 in setup, say crt number, where number is a slider variable. One of StarLogoT's many strenghts is that it's easy to play around with things. Then, continue with the tutorial project. So now we've got 100 turtles aimlessly moving around, completely unaware of their surroundings. Let's make things a little more interesting by giving these turtles a nice background against which to move.
Return to the setup procedure. We can rewrite it to sync better with the go procedure:
setup-turtles is familiar, being exactly what we were doing in our old setup. The line at the top, patches-own [elevation] declares that we have a variable for the patches called elevation. Our setup-patches procedure then uses this variable. First, each patch picks a random number between 0 and 9999, inclusive, and sets its elevation value to that number. We then use a patch primitive, diffuse, that essentially smoothes out the distribution of this variable over all the patches.
We can see the effect of diffuse in the next command, scale-pc, which uses the different values of elevation to assign colors to the patches. In this case, we assign different shades of green to all the patches. (Don't worry about the numbers given to diffuse and scale-pc just yet.) The larger elevation is, the lighter the shade of green. Low values of elevation result in darker shades.
Type this in and press the "setup" button. Voila. We have a lush StarLogoT landscape. Here you can see how diffuse works.
Return to the Procedures window, and comment-out the diffuse command by adding a semi-colon in front of it like this:
Press "setup" again. Doesn't look as good, does it? This is because, as mentioned above, diffuse has each patch share its value of elevation with all its neighbors. Every patch resets its value of elevation to a new value that depends on the value of elevation all around it. Don't worry if you don't quite get what's going on here. You can read about in The StarLogoT Development Reference Manual. It may help to play with the values being passed to it, and see what happens.
We're ready to start creating some kind of dialogue between the turtles and the patches. In fact, we even have an idea for a project. Notice that we called the patch variable "elevation?" Also, our landscape sort of looks topographical. We're going to have our turtles do what is called "hill-climbing," where every turtle seeks to find the highest elevation it can. Go to the Command Center and type show max-of-patches [elevation] and show min-of-patches [elevation]. These two reporters will, respectively, search over all the patches to return to you the highest elevation and the lowest.
One last thing before we delve into the coding. Those two values we just read, the highest and the lowest elevations, might be nice to know. Rather than re-typing that each time, let's use a shortcut. At the top of your code (right after the patches-own declaration), declare two global variables:
and in setup-patches, write:
Now we have saved the highest and lowest points in our terrain and determined where these points are graphically.
Let's look at the two if statements. Each patch looks at both statements and compares its own elevation to our global variables. If the comparison evaluates to true, the patch executes the list of commands that follows. In this case, the command is simply to change colors.
We're having all patches whose elevation values are near (within about 1% of) the highest value change their colors to white. All patches whose elevation values are close to the lowest become black. This makes them easier to see. You can make a few quick changes here if you wish. They won't affect the rest of the model. If you have trouble seeing these peaks and valleys, first type die in the Command window to eliminate the turtles. Then, instead of coding setpc white and setpc black, you can say setpc blue and setpc red, or whichever colors you wish. Also, you can change the range of highest and lowest peaks by changing the number 100.
After this, create two monitors in the Interface window with the toolbar. (Click the Monitor icon on the toolbar, and then click and drag a region in the Interface window where you want a monitor to be.)
Set the decimal places to be 3, and name one "highest" and one "lowest." Then, every time you click "setup" and re-distribute the values of elevation, you'll know exactly what the highest values are, and where they can be found.
1. Creating a New Project: Getting Started
to setup
ca
crt 100
fd (random screen-edge-x)
end
to go
move-turtles,
end
to move-turtles
seth (random 360)
fd 1
end
2. Developing Your Model: Patches and Variables
patches-own [elevation]
to setup
ca
setup-patches
setup-turtles
end
to setup-patches
setelevation (random 10000)
diffuse elevation 1
scale-pc green elevation 1000 9000
end
to setup-turtles
crt 100
fd (random screen-edge-x)
end
;diffuse elevation 1
globals [highest ;; the highest patch elevation
lowest] ;; the lowest patch elevation
to setup-patches
setelevation (random 10000)
diffuse elevation 1
scale-pc green elevation 1000 9000
sethighest max-of-patches [elevation]
setlowest min-of-patches [elevation]
if (elevation > (highest - 100))
[setpc white]
if (elevation < (lowest + 100))
[setpc black]
end