[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ABM/Toolkit futures [was: Swarm futures (was Re: GNUstep and MacOS X
From: |
Jason Alexander |
Subject: |
Re: ABM/Toolkit futures [was: Swarm futures (was Re: GNUstep and MacOS X Port Effort)] |
Date: |
Sat, 5 Oct 2002 12:50:19 +0100 |
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.
==================================