February 2014


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
Roman Seidl <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Thu, 27 Feb 2014 11:47:25 +0100
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

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.


* 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