Newsgroups: comp.ai.alife
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!news.sprintlink.net!simtel!harbinger.cc.monash.edu.au!aggedor.rmit.EDU.AU!news.unimelb.EDU.AU!wehi.edu.au!woozle.mel.dbe.CSIRO.AU!mel.dit.csiro.au!its.csiro.au!bimbo
From: shaun@prospect.anprod.csiro.au (Shaun Green)
Subject: Re: collision processing
Message-ID: <3vkc9s$ek_002@its.csiro.au>
To: pnelson@lagoon.ultranet.com
Sender: news@its.csiro.au (News Manager)
Nntp-Posting-Host: green.prospect.anprod.csiro.au
Organization: CSIRO
X-Newsreader: News Xpress Version 1.0 Beta #3
References: <pnelson.199.006FC580@lagoon.ultranet.com>
Date: Tue, 1 Aug 1995 04:58:36 GMT
Lines: 92

In article <pnelson.199.006FC580@lagoon.ultranet.com>,
   pnelson@lagoon.ultranet.com (Peter Nelson) wrote:
>
> [ I have no idea what the *correct* newsgroup is for this
>  question so I'm posting it here in the hope that someone
>  will point me in the right direction. ]
>
>For years I've been experimenting with writing tools I can
>use in the simulation of complex systems comprised of 
>many independently interacting entities.  My hope is to
>develop a C++ class library that could be used for such 
>diverse applications as Alife, traffic simulation, securities
>markets simulations, various n-body problems, etc.
>
>One goal is to be able to simulate simultaneity.  There are
>various schemes to do this but the ones I've been using all
>involve computing the state of an entity at time T+1, based
>on the state of it and all other ones in the system at time T.
>That way I avoid order-of-processing artifacts.
>
>The problem I'm having is with "collisions".  A collision
>is when two entities compute states for themselves which
>will be mutually exclusive at time T+1.  In the simulation
>this could be a physical collision such as a pair of billiard
>balls colliding, or a logical one, such as two investors
>trying to buy the same issue of stock. 
>
>In more generic terms imagine a grid with tokens on some
>of the squares.  Imagine that two tokens each attempt 
>to occupy the same square at time T+1, and this isn't
>allowed.  How can this be resolved?   If you try to resolve
>it by preventing it at time T, by having one token "look
>ahead" to see if any other tokens will occupy its intended
>location you introduce order-of-processing artifacts.  If
>you wait until time T+1 and assign a "winner" then what
>happens to the "loser" token?  You can't just leave it in
>its original square because some OTHER token may
>have occupied it - you can easily demonstrate that that
>case *could* recurse endlessly.
>
>I can't be the only person to have hit this problem, but in
>past years when I've asked it I've never gotten a useful
>answer.   Suggestions?
>
>---peter
>  

This is very much like a resource contention problem (as encountered by 
operating systems with resources such as printers, or databases with resources 
like database records).  The standard way of solving these problems is with a 
locking mechanism where the process (or token in your example) "locks" the 
resource to prevent other processes from gaining access to it until the 
process with the lock is finished with it.  I understand that this then 
introduces "order-of-processing" artifacts into the system, but maybe these 
artifacts exist in the phenomenon that you are modelling anyway (two brokers 
*cannot* buy the same item of stock - one buys it first and the other goes 
without).  Maybe you just need to bite the bullet and process your 0..n-1 
tokens in pseudo-random order.  Unfortunately, this will leave you with a 
system that is non-deterministic.  Note that the level of non-determinism in 
such a system will be a function of (the number of collisions / the number of 
non-collisions).

If non-determinism is a problem, you could change the system to one where 
individual processes "compete" for resources when a collision occurs.  For 
example:

    t0: 
        no process has a lock on resource X.

    t0->t1:
        step 1: process1 checks to see if resource X is locked, sees that it
	        is not, and locks it.
        step 2: process2 checks to see if resource X is locked, sees that it
                is locked by process1, and competes for it with process1.

    t1:
        winner of competition gains possession of resource X.

"Competing for a resource" makes more sense in some cases than others (stock 
brokers could compete for shares by screaming louder - or whatever).

Looking back on this, it occurs to me that the first case (processing the 
tokens in each timestep in random order) is just a special case of the second 
(competiton between colliding processes), where the winner of the competition 
between processes is determined by a pseudo-random process.

By the way, have you heard of Swarm (under development by Santa Fe Institute).  
It seems to be the same kind of thing you're working on.  Try having a look 
at:
        http://www.santafe.edu/projects/swarm/


