MASON-INTEREST-L Archives

February 2014

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Roman Seidl <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Thu, 27 Feb 2014 11:47:25 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (49 lines)
Actually this is something that is not in any way specific to MASON. The 
ABM Frameworks I know usually assume you are working on mutable data in 
sequence.

I like the problem because it relates to the question of mutable vs. 
immutable data.

It is easily thinkable to e.g. have an agent that produces a new agent 
as a result, thus making the agent immutable. Or to have an environment 
that is immutable and some process produces a new environment for the 
next round. This is actually kind of what Sean's double buffer approach 
would do.

What would be an advantage is that this would allow for parallel 
processing, besides meeting the religious beliefs of the functional crowd.*

At least as long as there is no interdependencies between agents and the 
changed state of other agents e.g. their new positions.

This where it gets kind of funny:
On 2014-02-27 02:36, Sean Luke wrote:
>   they'll need to make sure that they don't overwrite each other in field B.

How could one ensure that movement works if agents only know a picture 
of where the other agents have been and then call them to move blindly? 
They will inevitably run into each other. How would you try to avoid 
that? You could check in the new field that then would have to be 
mutable reflecting the current agent positions. This would have to be 
changed in sequence. Thus there is a dependence on mutable data, calling 
for synchronization.

Possible solutions would maybe either be actually span a copy of the 
field just for the neighbourhood calculations, use Sean's double buffer 
approach or to use Chris' "two rounds" approach, where first all agents 
get called for some calculations and then they get called for a second 
time to move.

The "two-rounds" approach would allow for putting the first round in a 
ParallelSequence, if you mind the other synchronization issues e.g. with 
the Random Number Generator.


cheers
roman

* Does anybody know if somebody ever tried to produce a functional ABM 
framework? I wouldn't want to use it but I would like to see it. As a 
tourist.

ATOM RSS1 RSS2