Re: models in the wild (was Re: [Swarm-Modelling] Re: [Swarm-Support] Repast vs. Swarm)

[gepr]

Rick Riolo writes:
 > But I think *another* reasonable direction to go is to treat ABM's
 > as *models*, just as diffyQs or other formalisms (or informalisms)
 > are models, i.e., a simplified version of some "real" system,
 > which (more or less) generates some of the same dynamics,patterns,etc,
 > of interest in the real system, which needs "verifcation" and 
 > "validation" as appropriate given the modeling goals, and given
 > the possibilities (given the complexity of the system being modeled...
 > see Steve Bankes on "Deep Uncertainty").
 > 
 > A thought provoking article in the ALife literature that
 > covers many of these issues is:
 > 
 >   Di Paolo, Nobe and Bullock.  Simulation Models as Opaque Thought 
 >   Experiments (Postscript)  Artificial Life VII: The Seventh International 
 >   Conference on the Simulation and Synthesis of Living Systems, Reed 
 >   College, Portland, Oregon, USA, 1-6 August, 2000.
 > 
 > But as i say, maybe i'm missing glen's point.

Yep.  You're getting the point.  (And the Di Paolo reference is right
on the money.)  You may just disagree or think I'm being
extremist... [grin] which, to some extent, I am.

The difference between continuing down the simulation path and just
doing a "proper job of it" versus abandoning the concept of simulation
entirely amounts only to one thing: methods.

Because the teleology of simulation is "to mimic", there are no holds
barred on getting a model to behave like the referent.  You can use
diffeqs, expert systems, the moorlocks behind the refrigerator, etc.
And this is all considered OK because your goal is to mimic.  Then,
once you've mimicked it successfully, you go about doing things like
sensitivity and robustness analysis, run it live to see if you can
make useful predictions off it (that save you money/time), etc.

It's the no holds barred aspect of simulation that prevents it from
leading to pedigreed methods that work.  (The same is true of software
development -- witness that even _today_ we have pompous people
running around inventing new "paradigms" like aspects, stories, etc.)
You end up, at the end of the day, saying "Oh sure, Bob added a few
fudge-factors here and there; but, it verifies in all the right
places!"  And then, unless you get the source code and, possibly, the
machine upon which the code ran, the right compiler, the right
parameter settings, the right input, etc., 10 years from now, nobody
will have any clue what you did to make it work.

What we need is to back off and treat the things we've created as if
we didn't create them.  (The crux of Di Paolo's paper doesn't do this.
It relies fundamentally on "a plausible mechanism" for the patterns of
interest.)

If you think about something like a "chair", "hammer", or a "beaker",
the creator is completely separated from the user.  I can use a
speaker for a chair, a monkey wrench for a hammer, and a french-press
for a beaker.  When we think "simulation", we force the inscription of
the purpose.  When we think of a computational device, we can think in
terms of simply "what it does" and not "what it was meant to do".
This might lead to more reusable systems in the end.  I believe it's
the reason the unixen are still around.  "Do one thing well" is
another way to say what I'm getting at... you could elaborate on that
mantra and say "Do one thing well and don't spend any time thinking
about how those idiot end-users will abuse your program."

Now, for your basic point, which I read as "Sure, you could do that
and maybe make progress; but, you could also go down the current
simulation path and make progress, too."  Well, i'd be insane to argue
with that. [grin] But, my point is not to denigrate simulation as a
practice.  My point is to hilight another approach that might help.

-- 
glen e. p. ropella              =><=                           Hail Eris!
H: 503.630.4505                              http://www.ropella.net/~gepr
M: 971.219.3846                               http://www.tempusdictum.com