Re: ABM/Toolkit futures [was: Swarm futures (was Re: GNUstep and MacOS X Port Effort)]

[Jason Alexander]

This is a long email.  My apologies.

On Friday, October 4, 2002, at 05:11 PM, Darren Schreiber wrote:
> It has been a while since I have chimed in on the Swarm list.  But, I 
> have been doing a lot of thinking in the past year or so about what I 
> would want from an agent-based modeling toolkit.  My two main concerns 
> now are teaching and research.

I'm in a similar situation and have thought about similar issues (as, I 
suspect, many people on this list have).  What I would like to do is 
summarize what I see as some of the main virtues (and vices) of Swarm in 
its present state, and offer some thoughts on what a possible future 
trajectory of Swarm might look like.  I suspect some of the following 
comments will be perceived as making radical, if not heretical, 
suggested changes -- especially to those who are fond of the current 
Swarm way of doing things -- but I take that to be a good thing.  If the 
goal is to think about what to change/improve/rework in a future version 
of Swarm, then I think we should adopt the approach that Larry Wall has 
taken for Perl 6: if we intend to change Swarm in ways that make it 
incompatible with previous versions, we should break everything that 
needs breaking in one fell swoop.

A partial summary of what are, IMHO, the biggest problems with Swarm are:

(1-) Swarm is hard to install.

That is, Swarm is hard to install if one isn't using the standard 
platform (i.e., linux).  Windows support (as I understand) is sketchy 
for the current CVS version of Swarm and one's best bet involves use of 
an old release version.  The woes of getting Swarm on Mac OS X are 
well-documented on this list.

(2-) Once installed, Swarm is hard to use.

This, of course, various with one's experience in programming and ABM.  
However, I don't think we should underestimate the importance of the 
perceived difficulty of Swarm, especially if we want to continue to 
attract new users, get students interested in Swarm (and up to speed in 
using it), and really make Swarm the de facto standard for ABM in 
science (which was, I thought, one of the original purposes of Swarm).

I mean, look at the requirements for a new user to do something simple 
like re-create Nowak & May's classic model of the Prisoner's Dilemma on 
a lattice (assuming Swarm is installed):

a. Learn enough of C and Objective-C syntax to be able to read code.
a'. Figure out how to use a compiler.
b. Create a basic "Agent" class holding PD strategies.
c. Figure out how to represent a payoff matrix in C or Objective C.  
This will probably be done
by hard-coding in the payoffs as constants because it's the easiest 
thing to do for a new user.
d. Figure out how to use the various *2D data structures to hold agents 
on a lattice.
e. Figure out how to draw the lattice on the screen.
f. Figure out how the scheduler works to be able to schedule 
interaction, strategy update,
etc. each generation.
.
.
.

I don't know about other people's experiences, but I've found that 
unless someone is already committed to learning about Swarm and ABM, 
most casual users burn out around a' or b.  This is unfortunate because 
if the learning curve had been a bit easier, these casual users could 
have gone on to become Swarm users and Swarm advocates.

I think what we should strive to do is to make (as in Perl) the "easy 
things easy and the hard things possible."

What's easy?  That depends on what you use Swarm for, and will vary for 
different uses in different fields.  For example, I work in evolutionary 
game theory and work with decision theorists, game theorists, 
philosophers, and economists.  The concepts these people use to conceive 
of problems involve payoff matrixes, learning rules, risk-aversion, etc.

A desideratum, then, is that

(3-) It should be easy for people using Swarm to describe modeling 
problems in the language they find most suitable.

The most suitable language will, in most cases, not Objective-C or 
Java.  This reiterates Darren's point: for new users, the toolkit should 
be a modeler friendly and at a high level.

Another problem with Swarm is:

(4-) It is hard to share models.

Of course, one can bundle up the code into a gzipped tarball and sling 
it off as an attachment, but then the person at the other end has to 
know what to do with it.  This brings us back to the problem that you 
have to be a bit of a code monkey to work with Swarm.  Many people don't 
want to do that.

Another problem:

(5-) It's hard to graft a GUI interface on top of Swarm.

For the Objective-C version of Swarm, writing a GUI interface stinks.  
If you want your controls to modify variables in your model you need to 
either use undocumented tcl/tk functions or use some kind kind of glue 
code.  I've not used the java version of Swarm, but I suspect many of 
these problems are eliminated if one can write models that use the AWT 
or Swing widgets.  If one can't write models that use these widgets, 
then the problem remains.


I take those to be the most serious vices with Swarm.  On the face of 
it, it's a damning list.  Swarm's hard to install, it's hard to use, 
it's hard to describe problems in the "natural way" (without being a 
programmer), and it's hard to share models.  Why use Swarm at all?  
Because:

(1+) Swarm is powerful, flexible, and incredibly open-ended (if you know 
what you're doing).


As I see it, this power creates some of the above problems because (a) 
the internal workings of Swarm aren't well-enough hidden from the first 
time user.  Moreover, it's hard to keep some of these internal workings 
hidden given the current design of Swarm.

I wonder, though, how much of the power and flexibility of Swarm creates 
unnecessary problems.  I've never used the phase-based object creation 
system.  Is it really necessary?  Would not having it make stuff 
impossible to do?  If the phase-based object system makes difficult (but 
rarely used) stuff easy at the cost of making often-used (or important) 
easy stuff harder, then maybe it should be dumped.  From what I 
understand, the phase-based object system underlies many of the porting 
problems to Mac OS X.

Also, what about the scheduler?  I've never used the full power of the 
scheduler.  From what I understand, though, it's a work of art.  But how 
many models can be expressed simply in terms of:

(a) do_this_stuff() each time step.
(b) At time t, do_this_stuff_once().

If 99% of the models can be expressed in these terms, do we really want 
to require people to have to create ActionGroups and hook them into 
Schedules, and activate schedules and... to get a simple model working?  
I realize that much of the creation of schedules is "easy" in the sense 
that it can be done by cutting-and-pasting from existent code and 
deriving your objects from the proper point in the Swarm hierarchy, but 
yet again we run into the problem of imposing significant overhead on 
casual users.


Enough.  What I'd like to do now is suggest a possible solution.


If you believe what I've said above, the biggest problems are:

(1) Make Swarm easy to install.
(2) Make Swarm easy to use (without, presumably, sacrificing power 
and/or features)
(3) Make it possible to describe modeling problems in a high-level 
language.
(4) Make it easy to share models.
(5) Make it easy to graft custom GUI interfaces on top of Swarm.
(6) Make it easy to create (and share) extension libraries for Swarm.

Other desiderata:

(7) Get Swarm running (easily) on all major platforms.
(8) Make it possible (perhaps) to embed Swarm models in a web page.


Compare the above list of features with the design of Mathematica. NOT 
BECAUSE I think one can do effective ABM with Mathematica (one can't -- 
it's dog slow and easy things aren't easy), but because I think that 
some of the above problems could be solved by integrating a 
Mathematica-like interface onto Swarm.

Think about it.  A Mathematica-like interface would mean:

(a) Models can be expressed in a "notebook" like form.  Evaluating cells 
causes changes to occur in the state of the model.

(b) If well-designed, the "language" of Swarm could involve high-level 
functions for setting up easy stuff, while at the same time allowing 
people to dig down into the lower-level guts for doing more complicated 
stuff.

(c) Models could be exchanged by sending the "notebook" as an 
attachment.  The notebook could be saved as text, or an XML file.  The 
use of high-level commands means that much could be achieved with 
relatively little text, so file size could be small.

In one stroke, then, we have a way of tackling (3) and (4), and make 
significant headway on (2).  Using Swarm for simple stuff, then, only 
involves reading a manual documenting the high-level functions.  If we 
really take the notebook idea seriously, one can incorporate (like in 
Mathematica) "description" or "comment" text that would allow the 
notebooks to be self-documenting.


Here's the really radical and/or heretical suggestion: it seems to me 
that many of the other problems could be solved if we dumped the 
Objective-C engine and went with a pure Java Swarm.

(1) Swarm would become easy to install because all one would need to do 
is install the Java runtime environment and download swarm.jar (say).  
Double-clicking on swarm.jar would start a Mathematica-like session and 
the user could be off and running.  One would not even need to install a 
Java compiler, at the start.

(5) Using pure Java means that one could use AWT or Swing for GUI 
interfaces.

(6) Java byte code is useable across all platforms.  A jar file 
containing a Swarm extension could be dragged-and-dropped into a 
standard location and automatically loaded by the class loader at start 
time (or any other time).

(7) Solved because of the widespread availability of Java.  (Might have 
to stick with Java 1.3.1 because Mac OS X doesn't have Java 1.4, yet).

(8) Pure java Swarm means that a Swarm "model" could be rolled into an 
applet, if the underlying base classes were written appropriately.


What about graphs?  The BLT stuff?  Let's use a freely available java 
solution like the Scientific Graphics Toolkit from NOAA.  It provides 
more than BLT, and already exists.

        http://www.epic.noaa.gov/java/sgt/

What about numerical functions?  Distributions?  Random number 
generators?  Let's use a freely available solution like Colt.  It's 
developed at CERN for high performance numerical computing in Java.

        http://tilde-hoschek.home.cern.ch/~hoschek/colt/

What about the interpreter?  A Mathematica-like interface would require 
an interpreted language. Writing an interpreter would be a major pain.  
Let's use BeanShell, a freely available interpreter that basically 
understands all of Java, save creating extension classes.  (That's one 
thing we would need to provide.  I've written to Pat, the author of 
BeanShell, and he doesn't think this would be too hard to provide.  
BeanShell already lets you create new instances of interfaces.)

        http://www.beanshell.org/home.html

What about the notebook interface?  Something like this already exists 
for BeanShell.  Commands can be inserted in "input cells" and evaluated 
by typing Shift+Enter.  Documentation cells can be created and they are 
capable of displaying any HTML code that a Java JEditorPane can handle 
(which is, I think, HTML 3.2).  More than enough for our purposes.

GUI interfaces can be easily embedded in the notebook because, when an 
input cell is evaluated, if the final output is an extension of the 
Component class, that object is automatically inserted in the output 
cell.  Entire JPanels, Boxes, etc. can be built up and inserted into the 
notebook.  Cells can be set to be automatically evaluated upon be 
loaded, so these simple GUI interfaces can be created without any 
interaction from the user.

The "notebooks" can also be saved as an XML-like file.

I've written a simple program illustrating how some of these things can 
be combined into an ABM modeling toolkit.  This program is tailored to 
my own research interests and isn't based on any of the Swarm code, but 
I hope it serves as a proof-of-concept of the above.   I *think* the 
current program suffices for both pedagogical and research purposes.  
One can basically model any two-person symmetric game expressible in 
normal form on an arbitrary social network, using high-level commands.  
Asymmetric games would be pretty easy to implement, but I haven't done 
it yet.

You can download the program from 
http://evolve.lse.ac.uk/jalex/misc/eml/docs.  Some preliminary docs 
exist, too.

One thing that isn't documented is how to insert/create GUI components.  
Try entering and evaluating the following commands in a cell:

        ShowLegend();

(this displays a legend for the current game)

        ShowPayoffMatrix();

(this displays the payoff matrix for the current game)

        bb = CreateButtonBox();
        b1 = Button("Reset model", "ResetModel()");
        b2 = Button("Evolve model", "Evolve()");
        bb.add(b1);
        bb.add(b2);
        bb

(this creates a mini toolbar with two buttons bound to the commands 
ResetModel() and Evolve(), respectively)

To grab an image of the current model, evaluate:

        ScaledModelImage( WIDTH, HEIGHT);

(where WIDTH and HEIGHT are integers).


Enough of my rambling.  Fire away.

Cheers,

Jason
--
J. McKenzie Alexander
Department of Philosophy, Logic and Scientific Method
London School of Economics and Political Science
Houghton Street, London WC2A 2AE



                 ==================================
  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.
                 ==================================