This page presents you with two kinds of assignments: submitted, and discussion-oriented.
You are expected to prepare discussion-oriented assignments for timely discussion. Discussions are graded: your active participation in class discussions is assessed.
Submitted assignments are due by their due dates. Submitted assignments are graded. To receive credit must be submitted on time: they are discussed after submission, so late assignments cannot be accepted.
Econ 450 students should skip parts marked as Advanced (unless pursuing an honors supplement). However, Econ 650 students should complete such sections, which are part of their assignment.
Assignments Page (Outline)
Computationally oriented homework projects implement methods developed in the course. Students must use NetLogo for these projects, even if they are using another language for their term project. Successful project completion will demonstrate an ability to design and construct very simple agent-based models.
You may discuss the assignments online. In the online discussions of assignments, I have two goals that partially conflict. First, I want a full discussion as you attempt the assignments, so that all confusions are quickly addressed. Second, I want everyone to do their own work.
You may find that to ask a question or help another student, you need to post a code snippet. Snippets are OK. But for collected assignments, do not share the bulk of your code before the assignment is collected.
Please do not be too paranoid about posting a little code. I trust you all to have good intent. But avoid posting code when a nice hint or link may serve as well to help your colleague, and never post more than is really needed for the discussion. The day after an assignment is due, you may share as much of your code as you wish. (By implication, assignments will not be accepted after the due date.)
Here are some practices you should follow for every computational project.
Put your name and the date at the very top of your source files.
Fully comment all all your code. The purpose of every global variable, including interface globals, should be carefully defined. Make your comment lines reasonably short, using multiple lines for long comments. Put comments on their own line when that reduces clutter.
Attribute all borrowed code by adding a comment giving the author's name. If the good comes from an existing model, provide a full citation of the model.
Avoid hardcoding numbers when possible. (Instead, set global variables in setupGlobals.)
Distinguish between procedures and reporters (to vs. to-report): only reporters can use the report keyword.
When you work with turtles, work with them directly. (Do not work with their who numbers.)
When you work with patches, work with them directly. (Do not work with their coordinates.)
Your setup procedure should generally look like this:
to setup clear-all setupGlobals setupPatches setupAgents reset-ticks setupGUI end
Most important: bring the error messages that you encounter to the list for discussion, so that you do not have to struggle on your own.
Discussions are a chance for students in this class to exchange ideas with each other. Participation is a very important component of this course. Participation through online discussion is expected even during illness, unless a doctor specifically states that a student is incapable even of online participation.
Discussions are student led. All students are expected to be frequent discussion participants and to clearly demonstrate their preparation of the required readings. Graduate students are expected to demonstrate a deeper understanding of the readings and to prepare more readings (as indicated in the required readings on the syllabus). Participation grades are assigned weekly based in large part on discussion list posts. I will occasionally give credit for other kinds of participation, but the core of your participation grade derives from your discussion of the required readings. I will look for all three the following:
Preparation of the readings for discussion should emphasize the historical development of ABS in the social sciences, the variety of ABS research programs in the social sciences, arguments for the use of agent-based models in the social sciences, unique insights about economics provided by agent-based methods, the applications where agent-based methods provide unique insights, and the problems of empirical validation faced by agent-based models.
Graduate students are expected to demonstrate a deeper understanding of the readings and, as indicated in the required readings, to prepare more readings. Their participation should demonstrate an awareness of the role of object-oriented programming in agent-based modeling and an understanding of the basic principles of object-oriented program design, as addressed in the readings. Graduate readings will also address the usefulness of parallel and distributed processing and the gains from access to a high-performance computing facility for agent-based modelers, and discussions should reflect an awareness of these issues.
Towards the end of the course, active work on the term-project code will also count towards participation.
A course “segment” lasts approximately 1 week.
Important
Discussion is graded!
Important
Review Due Dates!
Important
Discussion is graded!
Related readings:
You should find your own answer for each of these questions, and then pick one for discussion that you still find interesting or puzzling. (Try to pick a question that has not already been discussed by someone else.)
Related readings:
You should find your own answer for each of these questions, and then pick one for discussion that you still find interesting or puzzling. (Try to pick a question that has not already been discussed by someone else.)
Related readings:
Now at: https://subversion.american.edu/aisaac/notes/netlogo-exercises.html#simple-computations
Now at: https://subversion.american.edu/aisaac/notes/netlogo-exercises.html#random-numbers
Now at: https://subversion.american.edu/aisaac/notes/netlogo-exercises.html
Now at: https://subversion.american.edu/aisaac/notes/netlogo-exercises.html#export-agent-attribute
Now at: https://subversion.american.edu/aisaac/notes/netlogo-exercises.html#talking-to-patches
Now at: https://subversion.american.edu/aisaac/notes/netlogo-exercises.html#talking-to-turtles
Now at: https://subversion.american.edu/aisaac/notes/netlogo-exercises.html#netlogo-puzzlers
For this assignment, you will create (and turn in) four separate program files and a two separate charts. Put your name and date near the top of each program file, in a program comment. Your answers to any discussion questions below should be in the form of program comments.
Goals
Learn the use of:
NetLogo-specific Goals
Learn the use of:
Here is what we will do, in basic outline. Simulate draws from a Bernoulli distribution. Simulate draws from a binomial distribution. Characterize this process with run-sequence plots and histograms.
In this part of the exercise, we implement the basic program structure for a coin-flipping program. We will use this program to simulate the outcome of a single trial (one coin flip) and of many trials (many coin flips). We also add buttons to the GUI.
Choose or create a folder to hold your project files. Create a new source code file named coinflip01 (plus an appropriate filename extension).
Your program should introduce three global variables: outcome, nHeads, and nTrials.
Note
Avoiding global variables is good programming practice. Here we use them for two reasons: to illustrate the use of global variables, and to keep our exercise very simple.
Add a coinFlip function, which simulates one flip of a fair coin.
Implement your function as follows. Draw a random floating point value, uniformly between 0 and 1. Then use conditional branching to return a result of either 1 (if the number drawn is less than 0.5) or 0 (otherwise).
Note
This approach to simulating a fair coin flip requires only a tiny change if we later prefer to model an unfair coin flip.
Note
We call coinFlip a function because it returns a value. But unlike a mathematical function, it does not turn an explicit input into a determinisitic output. So it is not a pure function.
We want to use our coinFlip function in a simulation. Simulations very often have two core components: a setup procedure that sets up the initial state of the simulation, and a go (or step) procedure that advances the simulation. We will follow this conventional structure. Start by addign procedures named setup and go, creating an empty stub for each. Then add to these stubs some comments stating what you want them to do when completely implemented. (When implemented, setup will initialize our global variables, and go will flip a coin once and then change the global variables accordingly.)
Implement the setup procedure, which does the preliminary model set up. At this point, setup need only perform the initialization of your global variables. (E.g., reset the values of your global variables to 0.)
Next we implement the go procedure. Your go procedure should
A good way to proceed is to copy these three goals into your procedure body as comments, and then (below each comment) implement each goal.
Q: Implementing setup and go produces a complete a coin-flipping program. Run your setup procedure, then run your go procedure 100 times. (Use a looping construct to do this.) Then print nHeads / nTrials. Did you get half heads and half tails? Should you have?
Q: Rerun your setup procedure, and again run your go procedure 100 times. Do you get an identical outcome? If not, how could you ensure identical outcomes?
Q: Now, again run your go procedure 100 times (this time without first running setup). What is different about the outcome?
Extra exercise (not required): use string concatenation to print an informative summary of the number of trials, the number of heads, and the number of tails.
For user convenience, we often add widgets to a GUI that controls our simulation. For now, add just a single type of GUI widget: three buttons.
It is important to be able to collect data from our simulations for subsequent analysis. In this part of the Coin Flipping exercise, we write data from a coin-flipping simulation to a file. Subsequently, we create a run-sequence plot based on that data. So that we can gather more interesting data, we will generalize our model to allow for unfair coins.
So far we have been assuming a fair coin. Let us generalize this. Add a new global variable named pHead, with a default value of 0.5. This will be the probability of getting a head from a single coin flip. Change your coinFlip function to use pHead.
First, make sure you have saved your program file from Part I. Next, make a copy of that file in the same folder. Call this new program file coinflip02 (plus an appropriate filename extension).
Create a subfolder named out folder to hold your output. (You will write an output file to this folder.)
Modify your setup and go procedures to do data collection.
Add the following to your setup procedure: it should now prepare the file temp.csv (in the out folder) for writing. This setup removes any old version of this file and creates an appropriate header.
Add the following to your go procedure: it should now append one line to temp.csv, which will be the updated value of outcome.
As before, set up your model and again run your go procedure 100 times. Note that because of the changes you have made, this will write your data to out/temp.csv.
Use the data you have written to out/temp.csv to create a run-sequence plot of the cumulative proportion of heads after each of the 100 coin flips. (Effectively, you wish to plot 100 sequential values of nHeads / nTrials, but use the data you wrote to file.) Save your chart as runSequence01.png.
Note
You can use any software you wish to create your chart, including spreadsheet software or a statistical package. Save your plot in a common exchange format, such as Portable Network Graphics (PNG) format. Discuss any interesting features of your plot.
We are going to add slider widget to control how unfair our coin flip is. We will also add a real-time run-sequence plot. You have already created a plot based on the data you wrote to temp.csv. Now, separately, add a real-time plot to your GUI.
Note
Naturally, you will not be able to plot nHeads / nTrials when nTrials is 0. You may therefore want to use conditional branching as your plotting command.
Creation of a slider introduces and initializes a global variable; you should not declare it separately using the globals keyword.
Do not set default values in your setup procedure, because this will interfere with the user’s use of interface globals. Instead, use the special startup procedure for this. http://ccl.northwestern.edu/netlogo/docs/dict/startup.html
To add a plot, you can right click on the Interface window, wherever you wish to place the plot. Change the pen update command to plot nHeads / nTrials. Change the y-range to [0,1].
If you want to use reset-ticks in your setup procedure, you will have to change your plot command just a bit: if (nTrials > 0) [plot nHeads / nTrials]. Be sure you can explain why.
The clear-all command will also clear your plot. The command to run any setup code in your plot is setup-plots, but we do not need that at this time. The command to update your plot is update-plots.
Note
You can use tick instead of update-plots, since the former calls the latter. But since version 5, you would then need to call reset-ticks in setup. However, reset-ticks will call update plots, and if you try to plot nHeads / nTrials you will then get a divide by 0 error.
So for, one “trial” has been a single coin flip. Next, we allow more than one coin flip per trial. (So you are now doing binomial instead of Bernoulli trials.) You will again save your data to a file for subsequent analysis, but this time you will make a histogram from the output. Additionally, we will work on making a more useful GUI by adding two new widgets: a slider and a monitor.
Note
You can use any software you wish to create your chart, including spreadsheet software or a statistical package. Save your plot in a common exchange format, such as Portable Network Graphics (PNG) format. Discuss any interesting features of your plot.
Note
Extra (optional) exercise: As well as collecting the outcomes in a file, collect them by appending each value to a list. (This will require a new global variable.)
We are going to add widgets to our GUI.
In this part of the exercise, we learn to how to use objects to run our previous simulation. Call these object “coin flippers”. We let the coin flippers do the coin flipping, and they also manipulate global variables. In one round of the simulation, each coin flipper run one trial and stores the results of that trial. We also add a dynamic histogram of these stored outcomes to our GUI.
First, make sure you have saved your program file from Part III. Next, copy this to a new program file named coinflip04 (plus an appropriate filename extension). We are going to make some changes in this new file.
Previously, we repeatedly experimented with running 100 trials. Now we will formalize that by adding a new global variable, nTrialsPerRound, with an initial value of 20.
However, we will not simply run nTrialsPerRound trials. Instead, we will use nTrialsPerRound different objects, each doing one trial.
Each coin flipper will need an attribute to store the result of its trial. Name this attribute outcome. (Remove the outcome global variable.)
Discard the old go procedure; it is time to write a brand new one. It should now run an entire round, not just a single trial. A single round should
Optional: Create a global list containing each round’s total for coin-flipper outcomes. We will repurpose nHeads for this: while nHeads will still be a global variable, it will now be a list of numbers instead of a number. (This introduces a little memory.) Your setup procedure should therefore initialize nHeads to an empty list. Each round, use lput to append the round’s total number of heads to the nHeads list (and of course, use set to set nHeads to the new list).
Use patches as your coin-flipper objects. In the Code tab, use the patches-own keyword to add an outcome attribute. (Note that patches-own does not define global variables, but rather patch attributes.)
Be sure to review the code in the Histogram Example in the NetLogo Models Library before attempting to make your dynamic histogram.
We now want outcome to be the name of a patch attribute; it cannot also be the name of a global variable.
Since patches will be our coin flippers, we need the correct number of patches. Each patch runs one trial, and each round we run nTrialsPerRound trials. So add the following to your setup procedure:
resize-world 0 0 0 (nTrialsPerRound - 1) set-patch-size (400 / nTrialsPerRound)
Read about resize-world and set-patch-size in the NetLogo Dictionary, and then explain in detail (in program comments) what this code does. Test this code by running your setup procedure.
Remember that [attr] of patches creates a list of all the values of the patch attribute attr.
To plot two series in the same chart, you need to add a second plot pen. In this case, add a pen that plots the mean of nHeads.
You can use the NetLogo mean primitive http://ccl.northwestern.edu/netlogo/docs/dictionary.html#mean
Note
Using mean on an empty list is an error. So unless you use conditional branching to plot, you will not be able to reset-ticks. This in turn means that (in go) you will need to update-plots instead of tick.
Use the pcolor attribute to represent the number of heads. Make a patch greener as it flips more heads. Think carefully about what range you want to use; it can be bigger than the possible outcomes, if you wish.
First, quickly read over the entire Fishing World chapter in my posted notes. Then slowly work through all the exercises in that chapter.
Before attempting this exercise, be sure you have carefully read the following appendices: NetLogo Introduction and NetLogo Programming. Pay particular attention to the following topics.
Student who do not master these preliminary skills should not expect to be able to complete this assignment. Class should cover all this material before the exercise is due. If you feel a that information you need is missing, please let me know right away.
Details are in the Fishing World notes. Each student should complete all exercises in these notes, unless an exercise is marked as optional.
For this assignment, you will create (and turn in) two separate program files and a two separate charts. Put your name and date near the top of each program file, in a program comment. Your answers to any discussion questions should be in the form of program comments.
What you will turn in.
Attribution
You will be copying some code, particularly tests, from the assignment into your code files. As with any borrowed code, be sure to add an attribution.
In order to succeed at this assignment, you should first quickly read the entire Fishing World chapter. After that, you should approach the assignment step by step.
Read chapter 2 of Railsback and Grim (2011) and implement their Mushroom Hunt model. Carefully follow the details provided in the chapter. Be sure to fully comment your program, explaining all parts in detail.
testPatchColors
and createCluster
Attribution
You will be copying some code, particularly tests, from the assignment into your code files. As with any borrowed code, be sure to add an attribution.
Complete the Mushroom Hunt exercise before attempting the present exercise.
Before attempting this exercise, be sure you have carefully read the following appendices: NetLogo Introduction and NetLogo Programming. Pay particular attention to the following topics.
Class should cover all this material before the exercise is due. If you feel a that information you need is missing, please let me know right away.
First, quickly read over the entire Resource Foraging chapter in my posted notes. This will give you the needed context for the exercise. Then slowly work through all of the exercises in that chapter, rereading the notes as you go.
Find the details of the Resource Foraging exercise here: https://subversion.american.edu/aisaac/notes/abms-ResourceForaging.html Each student should do all exercises in this assignment, except for exercises explicitly marked as optional. (Undergrads need to do part V.)
Goals
NetLogo-specific Goals
Important
This assignment may take 15-20 hours, including preparatory readings and code experimentation.
Reminder: This exercise presumes you have successfully completed the other programming assignments (especially Coin Flipping and Logistic Map).
Submit the Following
Make sure your code is fully commented.
Assignment Goals
From this assignment you should gain familiarity with:
NetLogo Specific Goals
Create a new program file named ruin01 (plus an appropriate filename extension).
Do the 2-Player Gambler’s Ruin exercise, as described in the exercise in the lecture notes. https://subversion.american.edu/aisaac/notes/gamblers_ruin.html
You may find it useful to use a while loop.
Export your wealth history for player 1 to out/temp.csv. (You may use a different filename, but use an out folder immediately below your program file.) Open this CSV file in your favorite spreadsheet (e.g., Calc or Excel). Produce a run-sequence plot from this data. Save your spreadsheet graph as a PNG file, and submit it with this assignment.
DRY is good programming practice,
and we will be able to reuse our playOnce
procedure
later in this assignment.
So move the playOnce
procedure into a new module,
named ruin.nls,
and import it into your ruin01 model file.
After doing this,
make sure your model still runs as before.
Before attempting this part of the exercise, you may find it helpful to read The Process of Programming (Gambler’s Ruin). This guide emphasizes the value of proceeding step by step, with TODO-list outlines, stubs, and placeholders.
This part goes in a separate file from the previous exercises.
setup
and staticPairsRuin
procedures.playOnce
procedure.setup
(or startup
)
use the resize-world
primitive
to make 1000 patches as a 40 x 25 grid.scale-color
to represent the wealth levels of your players
(i.e., the patches).plabel
to visually display the wealth of "agents" (i.e., patches).setup
but try to run staticPairsRuin
?
Why?nAgents
)?This work goes in the same file as your previous work on the N-person model. (That is, just add to your ruin02 file.)
maxitr
rounds?
It is reasonable to interpret the response to these stopping conditions
as reflecting “institutional” considerations?randomPairs01
and randomPairs02
simulation
(after setup
, of course).Advanced
Anticipatory Comment: An array location may seem like a pretty shallow concept of an agent. It is actually a very common one in the literature. This assignment shows you how it can be simple and useful.
This goes in a separate file from the previous exercises. Name the file for this part of the exercise ruin03 (plus an appropriate filename extension).
export-plot
to write data to a file.file-close
when you are done!)
Discuss any problems you have with this exercise.Do things a little bit at a time. Do not try to do too much at once. After each change, make sure your programs still runs without errors. (Use procedure stubs to achieve this.) Use lots of extra print statements so that you can see what is going on in your program.
Let us see how you might approach the problem of writing
an array version of the staticPairsRuin
procedure, step by step.
We assume that you begin with a copy of your 2-player gambler’s ruin file,
and that you will add to this a staticPairsRuin
procedure.
First, start with an empty procedure. This is called a stub. Your stub needs to have the correct signature; in this case it will have one input (a list of players) and no outputs. Your empty stub is sure to execute without a problem.
to staticPairsRuin [#playerlist] end
Next, make a list of the things you want to do, and take them up one at a time. Put your todo list in the body of your procedure. For example:
to staticPairsRuin [#playerlist] ;TODO: pairup the items in #playerlist ;TODO: for each pair, call `ruin2player` end
What we really want to do is the last bit, but we need some pairs in order to do that. So as a temporary placeholder, let us just make up some pairs. This will serve as a “placeholder” until we get around to the first TODO item.
to staticPairsRuin [#playerlist] ;TODO: pairup the items in #playerlist let _pair01 (list patch 0 0 patch 0 1) let _pairs (list _pair01) ;;to be replaced! show _pairs ;;scaffolding ;TODO: call `ruin2player` once for each pair end
Check the syntax of your code. (In NetLogo, press the "Check" button in the Code tab. Do this every time you add code to your Code tab.) It seems to be OK, so switch to the Interface tab and "run" your procedure. I.e., just enter its name in the command center. Voila, it works!
After (seriously, after) you have that working ok, you are ready to try running ruin2player on each pair. But to do that, you need to take care of some preliminaries.
ruin2player
availableruin2player
has some global dependencies,
so you need to provide those:
maxitr
, playOn
, and playOnce
If you began with a copy of your 2-player file,
all of this is already in place.
But now we hit a barrier.
The problem is,
we want to run ruin2player
for each pair,
but we do not yet know how to do that.
Since we have a list of pairs,
you suspect you should use the foreach
command.
But you may not yet fully understand this command.
So first you need to make sure you understand this
command. So you go to
http://ccl.northwestern.edu/netlogo/docs/dictionary.html#foreach
and to
https://subversion.american.edu/aisaac/notes/netlogo-intro.html#agentsets-vs-lists
and read about how to use foreach. You learn that
? is a special name that is sequentially assigned to
each item in the foreach sequence.
So you test that out:
to staticPairsRuin [#playerlist] ;TODO: pairup the items in #playerlist let _pair01 (list patch 0 0 patch 0 1) let _pairs (list _pair01) ;;to be replaced! show _pairs ;;scaffolding ;TODO: call `ruin2player` once for each pair ; first, test understanding of ``foreach`` foreach _pairs [print ?] end
You use the Check button and find this is OK, so you again run your procedure from the command center and look at the output. Does it look like you expect? Make sure you can explain why you are seeing this output!
Now for your last step, you want to replace [print ?] (which just prints the pair) with the code block that does what you want to do (which is to run ruin2player with the pair). To do that, you should move to the command center and try a few things.
For example, at the Command Center you try
ruin2player (list patch 0 0 patch 0 1)
What happens next depends on how you wrote ruin2player
.
If you wrote it to accept a list containing two players,
it works.
However, if you wrote it to take two separate players (rather than a list),
you get
ERROR: RUIN2player expected 2 inputs.
Oh, of course: in this case ruin2player needs two players. So in this case you would instead try
ruin2player patch 0 0 patch 0 1
Hey, that works!
Now you are ready to go back and
use what you have learned to improve your procedure.
Assuming you wrote ruin2player
to accept a list:
to staticPairsRuin [#playerlist] ;TODO: pairup the items in #playerlist let _pair01 (list patch 0 0 patch 0 1) let _pairs (list _pair01) ;;to be replaced! show _pairs ;;scaffolding ;TODO: for each pair, call `ruin2player` foreach %pairs [ruin2player ?] end
Syntax check your code, and try to run it. If it runs, you have completed the hard part. Finally, complete the other TODO item: create the pairs of all the items in playerlist, and replace your place-holder list with your new list of pairs.
This exercise teaches you to model production, harvesting, and growth. It is closely related to the Sugarscape model.
Submit the Following
All students should submit to me one (1) fully commented program file, which should implement all components of Part I. Name your program file template01, with an appropriate filename extension. (Note that all four parts of Part I are due as a single program file. It is broken into step-wise parts for your convenience.)
Graduate students should also submit to me one (1) fully commented program file, which should implement all components of Part II. Name your program file template02, with an appropriate filename extension.
Grading
You will be graded on completeness of the assignment, correctness of the implementation, and adequacy (!!) of the comments in your program file.
Important
This assignment may take 10–15 hours, including code experimentation.
Prerequisites
Plan ahead! Begin your programming by entering explicit comments, which layout your program structure! Keep most comments as you fill in actual code; they will document your code. Be sure to document the type and meaning of every variable or parameter.
See the assignments on Blackboard.
Pick a random turtle and a random one of its links, and replace it within one attached preferentially
- Higher chance of linking to a turtle with the most links
Go to Model Library, open Network > Preferential Attachment, and save under a new name
- Agentset – a set of agents
- Defaults to a random order but can be sorted (into a list)
- Can also pick a random agent from the agentset
- If we want agentset to persist, must set it to a name we have previously declared in globals or locally
- In the context of a turtle, other turtles produces an agentset of all of the other turtles.
Bowen’s suggested modifications of Life * add a slider for global variable init-number
- default = 2
- possible values from 1 to 5
- handle divide-by-zero error when running with init-links = 1
- Divide by clustering-coefficient-of-lattice, divide by dum, protect dum from being zero
- We might eventually want a better fix
Let agents interact by playing a simple two-player game. We will combine this two-player game with learning: agents change what strategy as the gain experience with the game.
Save your model as <FirstLast>-pd.nlogo, where you replace <FirstLast> with your own name (so my program would be called AlanIsaac-pd.nlogo).
Implement this game
Write a NetLogo simulation in which agents play a simple two-player game like the Prisoner’s Dilemma. Each agent plays the game using some strategy. As a first pass, let each agent randomly select which strategy to use (during setup). (But see below.) After setup, the game proceeds in rounds. On each round every agent is paired up with exactly one other agent, and the agents play the game. All agent pairs play the same game, and each agent receives a resulting payoff. Agents total up their scores over time. Agents can observe the payoffs of other agents. After a few rounds, agents decide whether to change strategy.
You can do everything with patches, but it is also fine to use turtles.
Some details:
All you are going to hand in is a NetLogo program so make sure you:
Once your simulation model is coded, it is time to experiment. Try different initial proportions of strategies and different games. Do the agents all converge on the same strategy? If so, how many ticks does it takes? Since there is randomness in the simulation, you will need multiple replicates of each scenario (say 10) to get a sense of how they perform on average.
Describe the results of your experiments,
including the statistics you collect,
in the Info
tab of your project.
Your report should include your UML diagram and the charts and/or tables you produce from your BehaviorSpace output. Follow the formatting checklist for instructions on how to properly format your submission.
Important
This assignment may take 10–15 hours, including code experimentation.
Prerequisite Readings
After learning about the Schelling Segregation Model and the implementation in the NetLogo Models Library, you will design an experiment and write a report.
Carefully describe (in words) the essential features of the Schelling (1978) segregation model (hereafter referred to as the Schelling Model), as set out by Schelling (1978, ch4, pages 147-155). Your goal here is to describe the aspects of the model that must be incorporated in any computational model that might claim to represent a Schelling Segregation Model. For the model details, you may rely entirely on my posted notes rather than reading the Schelling chapter.
Does the implementation of the Schelling Model in the NetLogo Models Library (Sample Models » Social Science » Segregation) capture the general structural features of the Schelling Model? (What is included; what is missing; what if anything is an extension?)
Based on the readings, construct a UML activity diagram (or flow chart) that can guide an implementation of the Schelling model as computer code. (You can use any drawing program you like, but you may want to use umletto, LucidChart, Dia, draw.io, or Gliffy for this.)
Your activity diagram does not need to represent the setting of sliders: treat the user-chosen slider values like any other exogenous global value. Your activity diagram does not need to present any detailed code from the procedure body, but it should carefully present the simulation schedule.
Discuss the how the simulation works, making reference to your UML diagram.
Look at the Interface tab and the Code tab of the Segregation Model. What parameter values must be specified by the user before “experiments” can be run? In your report, document the name, type, and meaning of these variables.
Based on your reading and on preliminary observations of the simulation, propose two different quantitative measures of the segregation outcomes of the Schelling model. These must be computable from information available at the end of each iteration.
At least one measure should be an addition you make to the model. (So you may use one measure that is already in the original model.) You must carefully explain and justify your choices. Aside from that, there is no right answer; be creative! However, your measures need not be your own invention: if you wish, you can use ideas you find in your reading. (As always, use appropriate attribution!) You should write a procedure that computes this measure.
Note that you are justifying looking at these measures prior to actually running your experiments. The results of your experiments may affect your judgments about these measures, but you do not need to revise your measures in light of your results.
Create an experimental design, carefully following our discussion of experimental design. (See the readings above, and follow our experimental design outline.) Use at least 5 values for each continuous treatment factor (i.e., model parameter). Use at least 5 replicates for each scenario.
For example, you might explore how the final values of your two proposed measures of segregation are affected by changes in one or more model parameters.
Graduate student should include a regression analysis. (If you have never studied regression, please contact me.)
Save a copy of the Segregation Model as <LastName>-Segregation.nlogo to a personal folder. (Replace <LastName> with your last name.) Add a comment with your name and date at the very top, followed by a full attribution of the code. In your copy (not to the original), document the name, type, and meaning of all variables. Add your experiments to this copy (not to the original).
Run your experiments and report your results, carefully following our discussion of results reporting. (See the readings above.)
Summarize your results. Do they support your hypotheses? (Give your best and most honest assessment. There are no extra points for confirming or disconfirming an hypothesis.) Comment on the compatibility of your proposed segregation measures: do they produce similar or divergent results? Do either or both of your proposed measures have any advantages or drawbacks? (Does either appear more useful than the other?)
Propose some possible extensions to the Schelling model. You may draw on the readings for this, but if you do, be sure to fully attribute the idea. Be clear about what aspects of the real world your extensions are meant to accomodate. (This is a brainstorming exercise; you do not have to implement these extensions!)
To create your experiment, first make a copy of the Segregation model file (from the Models Library).
In your copy of the Segregation model, put your name at the top of the Code tab, carefully attribute all the code, and then say how you are modifying the file.
Use BehaviorSpace to implement your experimental design. You need to choose at least one output to measure and at least one model parameter to vary. The obvious output to measure is the final value of "percent similar". I have asked you to pick one more. The most obvious way to proceed is to make a small modification to the concept of "nearby" used by the model authors. However you may proceed in any way you wish: just take time (say, one paragraph) to justify your choice.
Use behaviorspace-run-number to set the random seed for each run.
https://subversion.american.edu/aisaac/notes/netlogo-intro.html#behaviorspace-components
Cook, Christopher, “Home Page for the Schelling Segregation Model: Demonstration Software” http://www.econ.iastate.edu/tesfatsi/demos/schelling/schellhp.htm
Based on: http://mcbridme.sba.muohio.edu/ace/labs/lab/assets/ZITraderLab.pdf
develop flow diagrams for the ZIT Gode-Sunder computational model
Consider a ZIT implementation, such as the McBride (2008) online demo ZI Trading NetLogo Model: http://mcbridme.sba.muohio.edu/ace/labs/zitrade/zitradenetlogo.html McBride implements the zero-intelligence constrained (ZI-C) traders from Gode and Sunder: the ZI-C traders are constrained not to make any trade that will yield a negative profit. McBride sets the following defaults:
does the McBride ZI Trading demo for ZI-C trading correctly implement the Gode-Sunder experiments? (With ZI-C traders.)
Complete 5 runs of the ZI-C simulation with McBride’s default parameter values, setting T=2000.
For each run:
Experiment: increase the number of sellers to 100
Record your initial initial simulation results in a table like the following. Make a similar table after changing the number of sellers.
Obs Price Qty Vol Avg-Price Std-Dev Efficiency 1 2 3 4 5
Your write up should consider the following questions: