Models and Programs

[From Bruce Abbott (941229.1710 EST)]

I've been trying to unravel how I got into such semantic difficulty with my
simple "evolution" model. My intention had been to provide a simple example
of random variation and environmental "selection" of control system
parameters, but there was a technical problem with doing so. I wanted to
create and test what might be a large number of variants but had room on the
screen to keep track of the parameters of only four bugs at a time. My
solution was to have the program initially create only four bugs and then
replace each bug that expired with a brand new one. Eventually the program
would "discover" four sets of parameters that maintained viable control over
stored nutrients. By recording these values and running the program many
times, it would be possible to empirically map the three-dimensional response
surface of viable parameters for the given environment and starting

If I had generated a fixed set of bugs at the outset (say, 1000) and just let
the program run, the same variation (random parameter setting) and winnowing
process would have occurred, without closing the loop with the IF DEAD
statement. So we would have the same process as before, yielding the same
"consequences" (surviving bugs have viable control system parameters). And
Rick would not object to calling this process "selection BY consequences," if
"selection" simply refers the process of selective retention he illustrated as
"siftin' sand." I was not expecting controversy.

When I posted the model, I was thinking only of this aspect; the control
system part was just a necessary addition to accommodate the limited screen
space. This is why I thought it "a model of selection BY consequences that
even Rick Marken would like." When Rick asked whether I intended it as an
illustration of the reorganization process, I realized that, viewed
differently (including the IF DEAD part in the model), it would serve as such.
So I described it in those terms. But this places the model in a different
context; now the IF DEAD part of the program becomes an integral part of the
model rather than a simple bit of supporting code, and the model's description
changes as well. It is no longer correct to describe the model as
illustrating selection BY consequences. This, I believe, is where all the
confusion came in.

What this means to me is that even computer code cannot always be understood
unambiguously--the various parts may require an interpretation as to whether
they are a PART OF THE MODEL or just supporting code intended to help cope
with limitations of the system, such as available screen space. So I was
wrong to think that Rick could have understood the model correctly merely by
examining the program code. Context is crucial.

[A technical note: there is a minor problem in the SetViewPort statements
that contain a first parameter of 2 1--the value should be 1. This has no
effect on the operation of the model except to move the nutrient source a bit
right and cause the bugs to disappear off the left of the screen before they
reach the boundary. You can quickly fix this problem by doing a global find
and replace.]