Calculation¶

Calculation is the easiest of the basic parts of an algorithm to understand. The ability of a computer to do arithmetic is the same as any human’s ability except that the computer is faster and does not make mistakes. Computers are great at working with numbers. Programming languages include a full array of arithmetic operations: +, -, *, and /, along with parentheses to group expressions together.

All calculation involves three elements: the generation of a mathematical result, the property whose value is set to that result, and some language symbol that identifies this as a calculation statement. In NetLogo, calculation statements have the general form:

set property result

In NetLogo, “set” is a keyword that identifies that this statement is a calculation. The “property” is the name of an agent’s property or a global property. Finally, “result” is the outcome of calculating a mathematical expression. The effect of the statement is that the value of the property is set to result.

Perhaps the simplest form of calculation is an initialization. In this case, a property is set to some predetermined value. Often the value is simply a constant. An example of an initialization in our simple ecological model is:

set age 0

which is a calculation to set the age property of a turtle to zero. This statement is performed as part of the model’s setup operations. The goal is to make sure that all turtles start out as “young” turtles. Similarly, the initialization

set energy 2

sets the energy property of a turtle to a simple constant.

Another recurring kind of calculation is an update. The idea of an update is seen in real world situations. When you pay for a purchase using your debit card, the card’s balance is updated by subtracting the amount of the purchase from the debit card’s current (before the purchase) balance with the result becoming the new (after the purchase) balance. When a turtle in our simple ecological model moves, it expends a unit of energy. Thus, the energy property of the turtle has to be updated. We can see this update in the NetLogo code as:

set energy energy - 1

This statement sets the energy property of a turtle to be an amount equal to one unit less than its previous value. More mechanically, the current value of the energy property is obtained, one is subtracted from this value and the result becomes the new value for the energy property. In the same way, the turtle ages and so its age property must be updated by increasing the value of the property by 1 time unit. The NetLogo code for this is:

set age age + 1

This statement sets the age property of a turtle to be an amount equal to one unit more than its previous value. More mechanically, the current value of the age property is obtained, one is added to this value, and the result becomes the new value for the age property.

Calculations can be more complicated mathematically. The model named GasLab Free Gas (in the NetLogo Models Library in the Chemistry & Physics section) has these calculations:

set energy (0.5 * mass * (speed ^ 2))
set heading (theta - (atan v2l v2t))

While they are more involved, they still follow the same form.

In some cases, a calculation is complicated enough that it is broken down into pieces. The same GasLab Free Gas model has this code:

let vcm (((mass * v1t) + (mass2 * v2t)) / (mass + mass2) )
...
set v1t (2 * vcm - v1t)
set v2t (2 * vcm - v2t)

The first statement, beginning with the keyword “let”, computes a temporary result as the value of “vcm” which is then used in the each of the next two calculation statements.

Sequence¶

Arranging things in the right order is important. Sayings like “putting the cart before the horse” and the phrase “ready, fire, aim” are emblematic of the importance of proper order. The same is true in text that we read - shuffling the sentences in a paragraph is not likely to result in something that makes sense.

The Importance of Order

Ordering the steps in a program is equally important. A simple example of this is the code shown immediately above. In this code, a value for vcm is calculated and then this value is used in the calculation of the values for v1t and v2t. Reordering the steps in this code so that the calculation of vcm comes after the the steps that calculate v1t and v2t is clearly wrong.

Computers are designed to follow the order of steps given in the code they are executing. Unless the code says otherwise, a computer will simply fetch the next line, execute that line of code, fetch the next line of code, and so on.

Decisions¶

For programs to be able to cope with even simple problems, they usually have to be able to take alternative courses of action. That is, the program must adapt its behavior to changing circumstances. People adapt their behavior to changing circumstances all the time. Consider the image below of a traffic sign. This sign tells drives how to adapt their behavior to conform with legal driving conditions. One way to state what the sign says is that “if the light is flashing, then the speed limit is 15 miles per hour.” This form of “if...then...” expression is exactly what the designers of programming languages use to give the code we write the ability to adapt to changing circumstances.

A Traffic Control Sign

Similarly, the agents in the simple ecological model have rules that cause the agents to change behavior depending on circumstances. These rules are also cast in a “if... then...” framework. One of the rules for a turtle in the simple ecological model is that it can only reproduce if its energy is above a given threshold. This is code in NetLogo as follows:

if energy > birth-energy [
   set number-turtles number-turtles + 1
   set energy energy - birth-energy
   ; other steps here but not shown
]

This code directs the turtle to check a certain condition, namely whether its energy is above the threshold specified for reproduction (e.g, birth-energy). If this condition is true, then the turtle and the program take the actions specified; the turtle reduces its own energy level by the birth-energy, and one turtle is added to the previous number of turtles. Notice that in the NetLogo programming language, the “then” word does not appear but its sense is implied in NetLogo.

In general, a decision in NetLogo is of the form:

if condition [
   list of actions
]

which means that if the agent finds the “condition” to be true, then the agent will perform the list of actions given in the square brackets. When the condition is not true, then the list of actions will not be performed. The “if” and the square brackets are part of the “syntax” of the NetLogo programming language. Be careful; omitting the square brackets or forgetting to match the brackets will cause NetLogo to complain - or worse, simply execute a rule other than what you intended.

Life can be complicated and so can the conditions that we need to test for. The traffic control sign that follows is an example of this. This sign has multiple conditions that all go together to determine whether the speed limit is reduced to 40 miles per hour. These conditions are:

• the time of day is between 8 and 9:30AM
• the time of day is between 2:30 and 4PM
• the day is a school day

We would certainly understand from this sign that at 9AM on Tuesday the speed limit would be 40 MPH but that this would not be the limit if it were 9AM on a Saturday. Similarly, the speed limit would be 40 MPH at 3PM on Friday but that this would not be the limit if it were 3AM on a Friday.

A More Complex Traffic Control Sign

There are different ways of expressing the decision logic for this sign in the “if ... then ...” style. Warning: the code shown for this example is not meant to be completely valid NetLogo code. The details of how to write this correctly in NetLogo is not the point. This example is about the logical structure and its meaning.

One way is to begin coding the school sign logic is like this:

if day = school-day [
   ; other parts of decision here
]

This first step separates the decision into whether the current day is or is not a school day. If the condition is not true (i.e., the day is not a school day) then the sign does not apply and we can skip the rule. If, however, the current day is a school day we still need to apply the logic about the time of day. Let’s first deal with the morning hours. We can account for this in our logic like this:

if day = school-day [
   if time in 8-9:30AM [
      set speed-limit 40
   ]
   ; more needed here
]

This step has refined the decision logic by adding the condition that the speed limit is 40 MPH during the restricted morning hours (8-9:30AM). It is very important to notice the dependency created by this structure. Namely, the condition for whether the time is in the restricted morning hours is only tested if the current day is a school day. However, our rule is still incomplete because it does not handle the case for the restricted afternoon hours. We can add this condition like this:

if day = school-day [

   if time in 8-9:30AM [
      set speed-limit 40
   ]

   if time in 2:30-4PM [
      set speed-limit 40
   ]

]

This step has completed the logic of the sign by accounting for the lower speed limit during the restricted afternoon hours.

While the completed sign logic is correct, one aspect of it deserves a closer look. Notice that the two if statements that test the time of day are separate statements that will be executed in sequence (see discussion of “Sequence” above). We can follow the execution of the code by using a visualization of the execution shown in the following figure.

Flow Chart of an If-Then Statement

In this figure, the steps in the two separate decision statements are surrounded by dashed boxes to emphasize that they are two separate statements. The execution of the statements is shown by the arrowed lines. The execution starts at the top of the figure. The first condition is tested, and if found to be true, the execution proceeds to the right (indicated by the word “true” over the arrowed line going to the right); otherwise, the execution proceeds immediately to the next statement (following the arrowed lines labelled “false”). If the execution proceeds to the right, it executes the set statement (setting the speed-limit to 40 MPH) and then also proceeds to the next statement. The second if statement is similarly executed. What is to be seen here is that the second test is always made regardless of whether the first test was true or not.

In our complete sign logic, the test for the time of day being in the afternoon is executed even if the test for the time being in the morning is true. This “unnecessary” testing is harmless, though possibly annoying. It is harmless because if the time is in the morning, the second test will simply not be true and the execution will proceed. This situation might be annoying because we are making a test even though we know it will be false. To avoid this, we can structure the decision logic somewhat differently.

One way to restructure the decision logic is to use an alternative expression of the form “if ... then ... else ...” which provides that the “then” part is executed only when the condition tested is true; the “else” part is executed only when the condition tested is not true. In NetLogo, a statement like this appears as:

ifelse condition
  [ list of "then" actions ]
  [ list of "else" actions ]

The keyword “ifelse” and the square brackets are part of the NetLogo syntax. Remember that the square brackets have to be matched. The execution of this statement is illustrated by the following visualization similar to the one above.

Flowchart of an If-Then-Else Statement

This visualization shows that there is a strict choice being made between two alternative sets of actions. One and only one of the two alternative sets of actions will be executed depending on whether the condition being tested is true or false. Regardless of which “branch” is taken, the execution then proceeds to the next statement.

We can make use of this form of expression in structuring our sign logic. We want to be sure that the test for the afternoon restricted times is only made when the test for the morning restricted time is found not to be true. That is, the afternoon time test should be the “else” part of the morning time test. The NetLogo-style code for this is as follows:

if day = school-day [

   ifelse time in 8-9:30AM

     [ set speed-limit 40 ]      ; "then" actions

     [ if time in 2:30-4PM       ; "else" actions
         [ set speed-limit 40 ]
     ]
]

It may help to look at the visualization for this code.

Flowchart of If-Then-Else Code

In this visualization, a dotted box is used to outline the “else” actions. Following the execution indicated in the visualization shows that the test for the afternoon times is not made when the test for the morning times is true.

There is a second way to restructure our traffic sign logic. It relies on the way which we might explain the sign’s meaning to someone else. It would be natural to say something like “the speed limit is reduced on school days between 8-9:30AM or between 2:30-4PM”. In this case a form of ”... or ...” expression is being used. The meaning of this expression is that the condition is true if one or the other of the conditions is true. This corresponds well with the formal logical notion of “or” as well. A NetLogo-style version of our sign logic can be written this way:

if day = school-day [

   if time in 8-9:30AM  or  time in 2:30-4PM

     [ set speed-limit 40 ]

]

In this version of our sign logic, there is only one test for time of day which uses the “or” form of expression.

We have now seen three different but correct coding for the sign logic. This means that different programmers may come up with different ways to write a program that all solve the same problem. This is part of the creativity of programming.