Re: Modelling time passing

[cgl]

>   In the demo apps, the one example of a dynamic schedule with calculated
> times is the mousetraps model, but that doesn't involve a duration, only a
> calculated start time.

  But this is a duration - it's the duration of the flight of the
ping-pong ball from the trap that fired it to the trap that it
triggers. 

  For those of you who aren't familiar with the mousetrap demo app, it
is an illustration of dynamic scheduling in which the modelSwarm schedule
initially has only one message on it: to trigger the mousetrap in the
middle of the lattice. When the message is sent, the mousetrap that
receives it picks two mousetraps near it (within some radius) at
random, and inserts two new messages into the modelSwarm schedule to
trigger those mousetraps (send them trigger messages) and assigns 
random times in the future (within some "radius") at which they
are to be sent. This delay accounts for the time the "ping-pong"
balls released by the first mousetrap take to fly up and fall
back down again on the two selected mousetraps. Thus, it is an 
example of pre-computing a process duration, and scheduling
an event to happen at the end of that duration. 

  Another way an agent can take an arbitrary amount of time is
to send it "step" messages every time step, in response to which
it does, say, one iteration on a problem that may take an 
arbitrary number of iterations to complete - basicly time-slicing.

  Of course, when we do get to a parallel version of Swarm, you
can regain your "physical" asynchrony because you will be able to 
run swarms asynchronously on different processors. 

Chris Langton