Coding Collective Intelligence (Chemoton § Vitorino Ramos' research notebook)
Archive for November, 2009
[Link] Coding Collective Intelligence
November 23rd, 2009[Link] Working With Computer Nerds
November 18th, 2009Stochastic Traffic Cellular Automaton
November 17th, 2009Lately, I have started to study Traffic Flow Models. This post will hopefully be a start of a long series of posts regarding the field. Typically, there are two types of approaches when modeling traffic flow. The first approach is to treat traffic as a fluid. In this model, the behavior of individual cars are not directly modeled. Instead of modeling cars, this approach models the behavior of traffic density using Constitutive Laws. The second approach attempts to model traffic flow using a Cellular Automaton. The basic idea is that the driver’s behavior only depends on the car(s) immediately in-front and behind him. In this post, I am going to construct a simple model to describe this later approach.
First, let us divide the road into equal segments of length
and divide time likewise into equal time-steps
. The road would look something like this:

At any given timestep, a car can only occupy one grid space. This space is represented by the integer
. After each time-step, we will move the car according to it’s current velocity. We will define the integer
as the number of steps that the car will take at each time-step. Hence, the new car position will follow the iterative formula
. In order to understand Stochastic Traffic Cellular Automaton, we will also have to define two more variables. The first is
which the number of steps between the car and the car in-front of it. The second variable is
which corresponds to the max distance that any car can move on a time-step.
The Stochastic Traffic Cellular Automaton model will then follow the following steps for each car on the road for each time-step:
, then 
, then 
, then with probability
take
.
.Without any traffic, a driver would speed up to a velocity of
with an acceleration of
. If there is a car in front, it makes sure that it doesn’t crash into the car (which is usually a good idea). Lastly, there is a random factor placed into the equation. This is to make the model non-deterministic. For example, a driver could over-brake or do other non-deterministic behaviors. The randomization is created to encapsulate all these possible behaviors. As you can see, the model is very basic. However, we can add further rules if we want a more accurate description of a driver.
If you want to try coding this up, I would try simulating traffic behind a red light. What happens when the light turns green?
Holmes, Mark, Introduction to the Foundations of Applied Mathematics, Chapter 5
K. Nagel and M. Schreckenberg, J. Physique I, 2, 2221 (1992), A cellular automaton model for freeway traffic
[Link] Where do you benefit from dynamic typing?
November 17th, 2009[Link] Transaction costs
November 15th, 2009Transaction costs (The Endeavour)
I totally agree with John’s observations. Transaction costs are a good reason not to outsource certain tasks. However, it isn’t the only reason not to outsource. Even if outsourcing is cheaper (including transaction costs), it is not always a good idea. For example, a lot of software companies after the dot-com bust started to outsource software projects to India (and other countries). The software design and specs were handled in-house and the “implementation” was then outsourced to India. In the short-run, it paid to outsource. However, as time elapsed, Developers left the software company. Normally, this wouldn’t be an issue because a younger programmer would transition into the position and only a limited amount of knowledge would be lost. But if you outsourced all your junior positions, your company will develope a huge knowledge leak. Your software company will start to know less and less about the actual software it sells. I don’t think that I need to convince you that this is a bad thing.

