This quarter the focus of this course will be on complex systems and the tools used to build and analyze them.
See Grading for grading policy.
Equivalently, see Complex Systems Resources in Courses/CS 461
Question, comment, and discussion page
If you have a question or comment, please enter it on the discussion page. Click the discussion tab above.
User pages and Homework pages
I'd like you each to create a user account. (That will be required before the system allows you to submit your homework.) When you create a user account, also create a user page and make sure to include an email address on it.
I'd also like you each to create a homework page for yourself as a subpage of this page. (Please put your email address on your homework page as well.) To do that enter [[/your name/]] below in the list of homework pages. That will create a page "your name" as a subpage of this page. Then, for each week's homework assignment, put your homework answer as a subpage of that page. Put each week's homework on a separate subpage. Point to those answer pages from the Homework submission sections below. See the example.
Homework pages: Jeff Bailey, Bill Kunyiha, Robert Lai, Chris Lemcke, Justin Padilla, Nghia Phan, Rick Strom, Brian Smith, Justin Wu, Jesse Zwerling, Joey Leung, Firouz Bharthania, Darren Iwaki, Christian Kaskara, Martin Olsen, Kwan Shing Yuen, Mark Luntzel, Nick Tolentino
To refer to the homework for week 1, enter [[/My name/Week 1 | My name]] under Homework submission for Week 1. This will show up as My name, and it will be a pointer to your Week 1 submission.
Don't forget the [[/ at the beginning and the /]] at the end of all these page pointers.
Enrollment as of 2/4
From the GET web page.
Bailey, Jeff Allen Bharthania, Firouz Chen, Ke Iwaki, Darren Takio Kaskara, Christian Kunyiha, Bill Gitonga Lai, Robert Siu Fung Lemcke, Christopher R Leung, Yuk Luntzel, Mark Barnabas Olsen, Martin Jarnes Padilla, Justin Daniel Phan, Nghia Ngoc Smith, Brian David Strom, Richard Ward Wimmer, Robert Andrew Wu, Justin Chun Wah Yuen, Kwan Shing Zwerling, Jesse H
Week 1. Introduction
- Abbott Complex Systems Engineering
- Bar-Yam, Dynamics of Complex Systems
- Chrichton, Michael Complex Systems text and video
- Maslov, Sandpile Model
- Rauch, Seeing Around Corners
- Reynolds, Boids
- Shalizi, on emergence
- Tesfatsion, Agent-Based Computational Economics: Growing Economies from the Bottom Up
This site contains a large collection of useful material.
- Wilensky, NetLogo Schelling Segregation model
- Zick and Bramson, Complexity Blog
- Zick and Bramson, Computer Modeling Tutorial (slides)
- Download NetLogo.
- Work through the NetLogo tutorials (1, 2, and 3) in the User Manual.
- Open and run some additional examples from the models library.
- Look at the code.
- Create at least one simple model of your own and be prepared to demonstrate it. It need not be at all sophisticated. It can be derivative of a model in the models library. Just get some sense of working with the system.
- Feel free to experiment. I'm more interested in your playing around with the system (and putting comments about your experience on your homework page for this week) than in your building any particular simple model. You might write down comments about what you liked/disliked about the system. What you found confusing. Etc.
MediaWiki leaves lines that begin with a blank space unformatted—although it does recognize formatting commands within the line. This provides a useful way to enter code.
This is some text.
If you leave a space at the beginning of a line the text will be displayed more (but not completely) literally. So this is good for code. Note that code in the preceding sentence is displayed in boldface (and in italics in this sentence). Formatting within a line is possible. It is also possible to include external and internal links within a line.
This is the end of the code.
===Submissions=== A check mark ( ) indicates presentation in class.
Kwan Shing Yuen
Week 2. Emergence
Look at some NetLogo models. For at least three of them do the following.
- Characterize the emergent phenomena or properties, i.e., phenomena or properties that may be described at the level of the overall model.
For the segregation model, an emergent property is the formation of segregated neighborhoods.
- Describe (in English) the rules that the agents follow.
For the segregation model, the rules are the rule that an agent moves if an insufficient percentage of it's neighbors are of its own kind.
- Describe why the rules give rise to the emergent phenomena or properties. In other words, imagine that the emergent phenomena are specifications that the model is supposed to satisfy and that you as the model designer picked those rules to achieve that effect. Describe why the rules that the model implements cause the model to satisfy those specifications, i.e., why the rules work.
In some cases, the rules will not cause the model to satisfy the specifications except within a limited range of parameter values. Describe why those parameter values make a difference.
For the segregation model, the emergent effect occurs because mixed communities are likely to include patches in which no one of the opposite kind will be comfortable. Therefore all members of that kind will leave that small area. But then the area becomes totally segregated. This makes it more difficult for areas at the border of that neighborhood to remain mixed since it can only remain mixed if a large proportion of the elements adjacent to that neighborhood are of the opposite kind. This means that borders form in which one side of the border is of one kind and the other side is of the other kind.
The comfort zone parameter is important because if an agent doesn't care what percentage of the community is his own kind, he will never move. If an agent only wants to be with other agents of his own kind, all communities will be strictly segregated with moats of uninhabitable areas between them. As currently defined, this will not happen. All agents will almost certainly be unhappy all the time. As the model is written, an unhappy agent moves even if moving means going to a spot that makes him more unhappy! That should be changed. More realistically, perhaps agents should move only if they can move to a place where they will be happier. Small changes in the rules often make a big difference! To get a nice moat effect, try setting the comfort zone level to 80% and the number of turtles to 1000. 70% and 2200 also works—at least if the turtles are allowed to decide one at a time if they are happy or not.
Another problem with the NetLogo model is that all agents decide simultaneously whether they are happy or not. It would be better if each agent made an independent decision, acted on it, and then let the remaining agents act based on the new situation.) Intermediate values will produce intermediate results.
Download either MASON or Repast and implement one NetLogo model in whichever you select. My choice would be for you to implement the Biology > Wolf-Sheep Predation model since it is fairly typical of agent-based models and should be fairly straightforward in both Repast and MASON.
Kwan Shing Yuen
Week 3. NetLogo as a programming language
It's now possible to upload files with a .nlogo extension.
===Submissions=== A check mark ( ) indicates presentation in class.
Kwan Shing Yuen
Week 4. The Game of Life and other Models
Week 5. Intro to Game Theory and the Prisoner's Dilemma
- Create an
- evolutionary (more successful strategies displace less successful ones)
- spatialized (players play their neighbors and don't move around)
- iterated (strategies may consider previous interactions) PD model.
- Use the standard PD payoff table: T = 5; R = 3; P = 1; S = 0.
- Include as many strategies as possible.
- Include noisy and non-noisy versions of each strategy—except the random strategy.
- If possible allow the noisiness to be user-adjustable.
If you start with PD Basic Evolutionary, fix it so that, (a) it uses valid PD playoffs, (b) each player considers its own score as well as its neighbors when deciding what to do next, (c) it plays iterated PD instead of just single-shot PD.
Use NetLogo, Repast, Mason, or write code from scratch.
If you are already working on a model
for which you are writing a significant amount of your own code,
Week 6. Feb 11
Please sign up to see me individually.
To sign up, please link to your homework page. If the sign-up schedule is full, add a new slot at either the beginning or the end.
Note: I have copied check marks from this page to your homework pages—but only in those cases in which your homework pages pointed to the checked work. If your homework pages are not up to date on that score, please bring them up to date—and add checkmarks when you presented the work in class.
9:15 Joey Leung 9:30 Martin Olsen 9:45 Rick Strom 10:00 Nghia Phan 10:15 Firouz Bharthania 10:30 Darren Iwaki 10:45 Justin Padilla 11:00 Robert Lai 11:15 Bill Kunyiha 11:30 Chris Lemcke 11:45 Mark Luntzel 12:00 Justin Wu 12:15 Jeff Bailey 12:30 Kwan Shing Yuen 12:45 Jesse Zwerling 1:00 Brian Smith
Week 7. Feb 18. ProgFest
No class this week. The department requests that instead of class you sign up to help out with ProgFest. Please send an email to Raj Pamula.
Week 8. Feb 25. Genetic algorithms and the traveling salesman problem (TSP).
Homework 8Implement a GA for some problem. You may select your own GA problem, but discuss it with me (either directly or by email) before committing to it. Otherwise select one of the following projects.
We will probably continue this project through the end of the term. This week will be the first step. Over the next two weeks we will make the GA smarter or make the problem more sophisticated. So approach this week's work with the thought in mind that you are building a base for further development/enhancement—even though we are almost at the end of the term.
- Port TSP (as discussed in Week 8 notes) from MASON to NetLogo, Repast, or to be a stand-alone application. In making the port, merge the classes Tour and MyTour.
The only real use the TSP code makes of MASON is its display system. Writing a new Repast or stand-alone Java2D display should not be that difficult. Doing so would also allow one to add buttons and fields to parameterize the GA. The revised system could also be written to run as either an application or an Applet, which would be nice.
If you want to extend the TSP code you might try the following. Before running the GA on the entire problem, partition the cities by quadrant on the map. Solve the TSP for each quadrant separately. Then patch together pairs of quadrants (that is, generate a new population consisting of concatenated elements of the populations of the quadrants) and solve the TSP for map halves. Then patch together the map halves and solve again for the entire map. Each time you patch partial solutions together, you will probably have most of the good links in the new population. So it will be easier to find the best tour for the larger problem.
You may also want to add some additional genetic operators or refine some of the exiting operators. For example, the moveCity mutation operator currently moves a random city to a new location. An alternative might be to use a tournament (or other biased) selection process to select the city to move based on the lengths of the links to it. (The longer the link, the more likely the city is to be moved.) You might also want to place the city at a location in the tour that also depends preferentially on the length of the links created—the shorter the better. But don't always move the city with the longest link(s), and don't always place the moved city at the spot that will make the shortest link(s). You want the system to be able to make many choices. Think of it as non-deterministic: it will (eventually) find the one that works best. But it doesn't hurt to help it a bit in finding choices that might be better. Also, if one city is an outlier and is very far away from the other cities, it will necessarily have the longest links. You don't want to be moving it all the time. So don't try to outsmart nature.
The best reference for TSP is probably this Georgia Tech page.
- Write a GA for Prisoner's Dilemma. (Look at the description in the previous version of this course. (Scroll down a bit more than half way. Look at Homework (2) under Genetic algorithms.) In each generation, each PD player plays a sequence of (say) 10 games with every other player (including itself). A player's fitness is the total of all its points. (When a player plays against itself, don't give it double points, though.) Then the population evolves the players' PD strategies using traditional GA operations.
- Solve Sudoku using a GA. I discuss it briefly here. Last fall we solved Sudoku using constraint programming. (See simplified Sudoku solver and Sudoku using Finite Sets.) That approach was quite successful and is more efficient than using a GA. But a GA Sudoku solver would be an interesting exercise.
(If you are are working on a continuing project ask me if you want to continue working on that instead of writing a GA.)
Week 9. Mar 4. Genetic Programming
Prepare the work you are most proud of for presentation. I would like everyone to select the work (a) that you find most interesting, (b) that you are most proud of, and (c) that represents your most significant effort. (You decide how to prioritize these three criteria.) The one qualification is that whatever you decide to present should be work for which you wrote a significant amount of code. It should not be just a NetLogo (or other) model that you modified minimally.
Week 10. Mar 11. Presentations
This week is devoted to presentations of your work. I would like everyone to present one example of your work.
Final. Mar 18
Please sign up to see me individually.
To sign up, please link to your homework page. If the sign-up schedule is full, add a new slot at the end.
We'll meet in the classroom (E&T 220).
10:00 Justin Padilla 10:20 Chris Lemcke 10:40 Martin Olsen 11:00 Jesse Zwerling 11:20 Bill Kunyiha