list of swarms capabilitys?

[glen e. p. ropella]

address@hidden writes:
 > Is there a list of attributes that makes Swarm a) different from other
 > simulation toolkits and b) just as capable ('the same') as other
 > simulation toolkits, right?
 > 
 > Like a list you would show the the un-initiated?  To introduce them to
 > swarm and all the wonderous things it has to offer...
 > 
 > I would be interested to get many users input, plus their feelings on
 > the various tools.

Well, I *am* a user, despite the fact that most of my time has been
occupied with other stuff.  So, I feel justified in giving my opinion.

The first and foremost attribute Swarm has that other sim packages
don't have is an abstract one.

   1. Swarm is an attempt at a modelling specification language.  

   What this means is a bit obscure, so I'll proselytize a little.  The
problem with simulation is twofold (at 1st approximation).  The first
problem in simulation is deciding what one is modelling.  If the model
is ill-defined, then the simulation is guaranteed to be misleading.
And, in that sense, if the model is bad, then simulation is the exact
WRONG thing to use, or, more properly, one is not actually simulating
anything when a bad model is implemented.

   There are, however, many examples of bad models leading to good
intuition.  And there are many examples of bad models leading to bad
intuition.  This means that modelling is *insufficient* to the task of
understanding a system or process.  It is necessary, though.  (I
suppose this point could be argued...some might say that understanding
and knowledge are *not* based on modelling; but, for the purposes of
this discussion, it's safe enough to assume that *some type* of
modelling is necessary for understanding.)  The complement to
modelling needed to make a process that is sufficient to the task
of understanding a system is an implementation of that model.

   Now, the processes that most people seem to call "science" focus on
models induced from the implementation that is our sensory input (or,
for the hardcore realists out there, the real world).  This indicates
that not only is the implementation necessary, but the model is also
necessary (otherwise Skinner's approach would still be in fashion
[grin]).

   So far, I've implicitly outlined a process that is subject to
error injection in only one place, the generation of the model.
Of course there is another one in the generation of the implementation
from a model.  The errors injected at this phase are often a result
of a lack of understanding of the implementation medium (a programming
language or physical/biological/sociological organizations of the 
base "stuff" we call the real world).  And the errors injected in the
other phase (the model building phase) are subject to many more types
of problems.  

   Now, the point of all this jabber is that I pretend that Swarm's
true target domain is the betterment of our models of systems via an
implementation language that rests firmly in the syntactical *and*
semantic framework in which models are described.  What this should
mean is that the implementation language should emphasize complete
descriptions when using it to implement a model, so that implementing
a rudimentary model (albeit a complete one) can lead to a
finer-grained understanding of the model being implemented AND can
also lead to more straightforward implementations of the more
sophisticated models that result.  So that what we get from using
Swarm is an iterative loop between model-design and implementation,
hopefully leading to better overall understanding of a) the models we
study and the computational media in which they can be implemented and
b) the entire knowledge-generation process of model building and
testing.

   In fact, this is really the only aspect of Swarm that I think is
very interesting.  Granted, as a technology, it makes some beautiful
steps toward better simulation technique, etc.  But, it seems very
analogous to the automobile.  The car you drive says alot about your
personality.  Some people drive a car that has a flashy exterior and
flashy specifications, but that everybody intuitively knows is
marketed towards people who are impressed by exteriors and specs.
Some people drive cars that a purely functional.  Then that purely
functional class can be split into two subclasses: drivers who need
horsepower, torque, and speed, and drivers who simply need
transportation that allows them speeds greater than walking or biking.
I like to think I want to use Swarm because I need horsepower and
torque. [grin] (Speed I can do without for the time being.)  People
who only need a simulation tool can use any of the other packages.  I
won't make an analogy with the first class because I don't think that
members of that class would put the time and effort into installing
Swarm just to impress their friends. [grin]

To continue:

   2. The scheduling mechanism allows for various simulation
   techniques, all of which are not available in other simulation
   packages.

   For instance, most simulation packages will target a specific 
type of simulation, say, process-based, discrete-event, continuous-
time, etc.  Swarm is general enough to handle all of these.

   3. Both the scheduling mech. and the Swarm framework allow for
   'composability' of models and the absorption of models written in
   other systems.

   Since, as Paul put it, a Swarm is, simultaneously, "an individual,
a group, a population of actors, a programming language," etc., there
are many ways one can package up a model and many types of models that
can be packaged up.  The result is always a Swarm that interfaces to 
other Swarms.  This has been made possible by the vision of a process
floating around in a "process space" and by the technical magic of 
the implementation.

   4. The object customization mechanism implemented by Roger will
   single-handedly carry the current, impoverished, Object Oriented
   paradigm into a new realm of capturing program (and model) behaviour.

   Right now, the create/use-phase customization implemented in 
DefObj is really being carried on the excuse that the generality
of Swarm is carried by the dynamic binding optimized classes as
opposed to the compiled object code.  It's thought that this style
of customization will allow generality at the coding level and 
optimized efficiency at the run level.

   But, the real impact of object customization will lie in the
reinterpretation of "objects" as sets of program behaviour or
sets of events.  This is the most technologically exciting part
of Swarm and could lead to advances in debugging and profiling
implementations and in the concepts of computing, in general.  Of
course, the problem is that one must be a real geek to get excited
about this. [grin]

   5. Swarm is freely available *and* hopes to achieve new levels of
   cooperation among competitive elements in industry and academia to
   move us into a new way of using and developing enabling technology.

   Now, at first glance, this type of statement could be interpreted
along the vein of "can't we all just get along".  But, I assure you
it's not.  The community we're trying to foster via the Swarm package
is one where we develop a consensus "ontology" that on the one hand,
fosters cooperation at the abstract levels of enabling a modelling
capability and encourages competition within the concrete levels of
the game, itself, and on the other hand, provides mechanisms for the
dynamic redefinition of the "ontology" upon which the games are being
played.  [Hmmm, having reread that, I might think that I've just taken
some kind of psychoactive drug, or something. <grin>]

   In layman's terms, I think Swarm is trying to extract the rules by
which agents behave and return to those agents tools with which to
better understand the rules they're playing by.

So, that's my $0.02.  

Bert writes:
>I hope these tables help to answer your questions.  If those subscribing to
>this list see any thing we could add to the tables to provide a better
>comparison to Swarm, we would be glad to make the changes.

I would really appreciate the inclusion of ModSim, AutoMod, Tailor(sp?),
TarSim, and PowerSim, which are some packages I've heard about.  I 
have no idea if I got the spelling write on any of them.  They're just
spouted quickly during meetings and such, at which time I try to 
jot them down as quickly as possible.

glen
p.s. Opinions expressed herein reflect solely my personal position with
respect to life, the universe, and everything.  Any similarity to opinions
expressed by members of the Swarm Hive at SFI is purely coincidental.
-- 
{glen e. p. ropella <address@hidden>   |  Send lawyers, guns, and money!  }
{Episkopos 11~11                       |            Hail Eris!            }
{http://www.trail.com/~gepr/home.html  |               =><=               }


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