[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Swarm Futures re-cap
From: |
gepr |
Subject: |
Swarm Futures re-cap |
Date: |
Thu, 10 Oct 2002 11:23:37 -0700 |
OK. This is going *very* well. Our reports from Roger and Gulya
will help, too. Right now, I'm just collecting this stuff. I'd
like to have enough fodder for some solid discussion by the time
SwarmFest comes around.
Also, we should have more discussion of the other implementations like
AScape, RePast, MAS, Ecolab, StarLogo and any other tool that falls
under "Swarm-like" modeling. And I, personally, welcome discussion
of things like Mathematica, Matlab, XMath, R, HDF, VenSim, ProModel,
DADiSP, etcetcetc, as well as Linux (as a preferred platform),
Windows, Mac OSX, etc. Heck, I'd even like to see some discussion of
real-time systems. Swarm has never even approached things like
real-time scheduling or embedded systems or mobile agents, etc.
It would be cool to have a little discussions on low-leve protocols
for agents (SAX is NOT a low-level protocol [grin] but I suppose that's
ok, too).
glen
-----------Re-cap------------
>From Darren Schreiber:
1. Teaching:
1.1 Install
1.2 High-level modeling
1.2.1 Agent interaction network topology tools
1.2.2 Creation and mgmt of agents
1.2.3 Input and output tools
1.2.4 Retain capability of puncturing the high-level when necessary
2. Research:
2.1 High-level modeling
2.1.1 All of the points listed above go here, too
2.1.2 Rapid prototyping
2.1.3 Model replication through a gui or high-level language
2.1.4 Drag and drop GUI
2.2 Model Validation/Verification Toolkit
2.2.1 Docking tools to perform experiments on multiple models
2.3 Best Practice Modeling
2.3.1 Modeling Patterns for Input, Output, and Topology
>From Jason Alexander:
3. If we're going to break it, break everything that needs breaking.
4. Problem List
4.1 The reference (SDG's) implementation is hard to install.
4.2 The reference implementation is complicated to use and
inefficient for simple tasks.
4.3 (7.1) and (7.2) limit the propogation of Swarm.
4.4 It is hard to share models and extensions.
4.5 It is hard to graft a GUI on top of an application written for
the reference implementation (though this may be mitigated with
the Java layer or with other implementations).
5. Benefits
5.1 Powerful, flexible, and open-ended
8.1.1 Powerful tools are HARD TO USE, which brings up the
question of whether or not we need this much power.
6. Imperatives
6.1 It should be easy for people using Swarm implementations to
describe modeling problems in the language they find most
suitable.
6.2 Make it easy for others to install an implementation on any
major platform.
6.3 Make it possible to embed Swarm models in a web page.
7. Potential Directions
7.1 Develop a Mathematica-like model specification mechanism
7.1.1 "Notebook" model for modules/apps, which embody a complete
model specification that can be shared.
7.1.2 A multi-grained "language" that allowed both high-level
abstractions and low-level specification.
7.2 Dump Objective-C and re-implement the reference implementation in
Java.
7.2.1 Leverages Java deployment (model sharing and installation)
and portability.
7.2.2 Leverages the many APIs available like Swing.
7.2.3 Embeddable in a client-side applet.
7.2.4 Leverages the community-generated tools like SGT.
7.3 Already have a proof-of-concept for (10.1 & 10.2) with
<http://evolve.lse.ac.uk/jalex/misc/eml/docs>
>From Russell Standish:
8. Another toolkit with a slightly different focus: Ecolab.
9. Problems with the reference implementation of Swarm
9.1 Objective-C and Java are too simple to support some constructs.
9.1.1 Operator Overloading, generic programming
9.1.2 No parallelizing compiler
9.2 No complete scripting system
10. Swarm helped in designing Ecolab.
>From Phil <address@hidden>:
11. F-Script as a suggested scripting integration (at least for Ecolab)
>From Gary Polhill:
12. Build more on top of the existing libraries in the reference impl
12.1 Standar applications
12.2 Classes of agents
12.3 Model/ObserverSwarm extensions
12.3.1 Perhaps make Swarms into complete run-times and/or
interpreters
that can read a specification and instatiate, then execute
that
specification.
12.3.2 [Un]Marshalling of model specifications for transport or
storage
13. Imperative
13.1 Find out how much of most people's wishes could be achieved
through adding a bit of flesh on the Swarm libraries' bones,
rather than rebuilding the bones themselves.
--
glen e. p. ropella =><= Hail Eris!
H: 831.335.4950 http://www.ropella.net/~gepr
M: 831.247.7901 http://www.tempusdictum.com
==================================
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.
==================================