Re: Compare Swarm with Repast

[Gulyas Laszlo]

On Sun, 11 Aug 2002, Paul Johnson wrote:

> I don't want a flame war over this, as I expect the answer will boil
> down to a religious "whatever you like, use it!" I also fear that I'm
> only revealing my ignorance. And if I say anything that offends anybody,
> I sincerely apologize and don't intend to.

I don't want it either, but... Good for a start, yes?! :)

>
> RePast originated as a translation of much Swarm source into Java, so it
> should be similar. There are many parts of RePast that are literal
> translations. I recall recently seeing a user question about why the
> diffusion grid in RePast works the way it does, and the answer was that
> Swarm used a particular formula and they copied it exactly.  I tend to
> think of RePast as an alternative implementation of the Swarm API,
> rather than a competitor, it is a project cooperating along toward a
> common goal.

I agree that the ultimate goal is common. Still, opinions on tactics may
hugely differ. As for the copying part, I am not sure of that. Nick
Collier, the original author would be the most authoritative source to
answer this. As far as I can see, the only 'translation' was done
in the Heatbugs demo. Aat least that was what the question you mentioned
was all about. That  was done in order to show that Repast is capable
of what Swarm is. (Or almost or whatever. :))

>
> I think it would be excellent if you wrote up some agents in Java, and
> then created both Swarm and RePast sims for those agents, and we could
> match them up.  At the last Swarmfest Mike North gave a presentation
> about using RePast to recreate a simulation that replicated an old swarm
> classic.  That presentation was really interesting, showing it could be
> done and that there are some surprising techinical complications
> (numerical precision being important).

I've done this. Several times, actually. The idea has never occured to me
to write my experiences up, but I may do it sometime, time given. In
short, I never had any problems doing that. Rather, everything worked much
smoother for me in Java.

>
> There have been a few comparisons published, they seem to indicate that
> for light duty projects, RePast is easier to get up and running, but for
> heavy duty projects it may be lacking.  In the swarm-support list within
> the last two weeks, a couple users have touted the ease of use.

I've heard about these opinions a number of times, but never actually
seen the real problems Repast is supposed to have with 'heavy duty'
projects. That may be true, though. Michael North is in charge of one of
the largest Repast projects I know of. Maybe, he could comment on this.

>
> For me, Java is a minus rather than a plus, but I understand some people
> like it.

OK, this is really the realigious part. Just for the sake of completeness
(however obvious this may be): for me Objective-C, especially with the
special 'Swarm notation' was a real drag, even though, I've mastered
a dozen of other languages before.

>
> Off the top of my head, I'd say here are some important things to consider:
>
> 1. Archiving:
>
> Now, concerning RePast, I noted this web site today:
>
> http://www.irit.fr/COSI/training/evaluationoftools/Evaluation-Of-RePast.htm
>
> In there it says RePast has no serialization.

True and not true. Repast has no built-in serialization, because that
comes free with Java. And this is probably the main difference between
Swarm and Repast. Repast attempts to be a core package for simulation,
keeping as much of the other functionality separate [#], relying on
industry-standards. Of course, being 100% pure Java makes this rather
easy. On the other hand, Swarm seems to have its own solutions and/or
specific bridges to most of what is needed for you. But that means that
i) you have to learn them just for the sake of Swarm ii) whatever need
comes up, somebody has to write a solution or bridge an existing one
to Swarm.

[#]
Actually, I came across this the hard way. I've been proposing
extensions and got turned down... :-)

>
> I've got the current Swarm (CVS) working to fully save and re-create
> complicated objects, including ones that contain Swarm Arrays and C
> arrays of ints and doubles. Look for a methods
> "lispStoreIntegerArray..." and "lispStoreDoubleArray" in DefObject.*.
>
> Sometimes it is vital to be able to save the state of a simulation in
> its entirety and restart and Swarm can do it for me in the Lisp format.
>    I'm not trying to do this with HDF5. (yet!)
>

See above.

> 2. Swarm implements hierarchical dynamic decentralized scheduling. You
> can have any number of levels of hierarchy and actions from any level
> get merged into time in a meaningful way.  About this, I made a
> presentation at the last swarmfest. (I think I have that online in my
> Swarm directory) In this sense, the Scheduling mechanism in swarm more
> closely approaches the ideal of a 'bottom up' model.


Yes, this is something clearly lacking from Repast. I am not sure, but
this may come in or after Repast 2.0, which is coming soon. Although, I've
always wondered how big a percentage of all ABM's actually use this. I
mean, I love it, but never even talked with someone needeing this. This
may also worth a survey...


>
> 3. For Swarm, one can find some really interesting applications, not
> just the swarmapps stuff, but the village model (of Southwestern Native
> Americans), Arborgames, El Farol, the Artificial Stock Market, and
> numerous others. Many of these are in the Swarm ftp directories, many
> are available directly from authors. Repast has translated Heatbugs to
> run in RePast, but as far as I know, there is not so big a set of examples.

This is not true. There is a fairly large (and growing) collection of
Repast models, including automated trading (auctions), coalition and
voting models, city formation, state formation, small world models, etc.,
to list just the few I had some relations to. It is clear, however, that the
Repast community should be much more organized on this front. (There
is talk about this, too.)


> At the last swarmfest, the RePast team gave a nice presentation
> featuring some of the strengths of their package, including several
> kinds of diagnostic tools for social networks.  As you must know, RePast
> is explicitly designed for social science modeling of that sort. That
> part looked good to me and I considered whether we should lobby for
> development support in Swarm for similar libraries. I concluded that it
> was probably not worth my effort because so many of the people using
> Swarm have no interest in social networks.

This is also true. One of the coolest packages in Repast is the network
library (which is, of course, usable for much more than simple social
networks). For one thing, they can be used to model hierarchies of actors,
partly filling in the gap left by the lack of hierarchical schedules.

Actually, the general use of the network lib. is related to one of my new
'obsessions'. I am trying tro convince the ABM community to be just as
rigorous about interaction topologies as they are caring about sensitivity
to changes in other model parameters. Why would a 2D grid be the canonical
topology for most of what we do?

>
> For me, the most interesting issue is this.  All of these sim packages
> are motivated in part by the desire to help nonprogrammers build models.
>   I think it is important that the modeling framework not impose too
> much structure, it is important to avoid the danger that modelers will
> find a "hammer" and think all problems are "nails".  What can a package
> do to help researchers implement their "ideas" without making them do a
> ton of programming?  I think no package has a perfectly workable answer.

I completely agree with you on this. That's why I greeted Repast's
Simulation Builder (used to be Evolver) that is a rapid development
environment for social network models. Unfortunately, it is in the
very early stages of its development and (to me) too focussed on networks.
Money and time permitting I'd like to spend time on extending it.


OK, this is it for now. I agree with the rest of Paul's mail. And while
I am not in for a flame war either, I think, it was nice to talk
these issues over. Some sort of 'coordination' may also possibly help
in the future.

All the best,

Gulya

[...]

-- 
--
Laszlo Gulyas                           address@hidden
AI Laboratory                           http://www.sztaki.hu/~gulyas/
Computer and Automation Research Inst.  H-1111, Budapest, Kende u. 13-17.
Hungarian Academy of Sciences           * 36 1 209-6194

--> On leave at Government Department, Harvard University      <--
--> 113b VanSerge, Mails: 34 Kirkland st., Cambridge, MA 02138 <--
--> address@hidden, (617) 384-9088                     <--




                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================