There are many alternative simulation styles to an ABM simulation architecture:
- Discrete-event queuing models - Continuous systems simulation (ex: CSMP) - Procedural discrete event (ex: SimSCRIPT) - CA The use (or not) of a subroutine in the underlying code has nothing to do with the simulation architecture being used. --Doug On Mon, Jan 5, 2009 at 9:34 AM, John Kennison <[email protected]> wrote: > > > Perhaps the first step in forming a taxonomy is to see if there is a > reasonable way to distinguish ABMs from non-ABMs. I am guessing here, but is > using a subroutine the alternative to using an ABM? (For example, is it the > case that a subroutine which computes square roots can be viewed as an agent > whose purpose in life is to find square roots?) Is the difference merely a > matter of FOR? If my distinction between subroutines and ABMs makes sense, > are some features that would make something more likely to be thought of as > an ABM rather than a subroutine? > ________________________________________ > From: [email protected] [[email protected]] On Behalf Of > Douglas Roberts [[email protected]] > Sent: Sunday, January 04, 2009 2:16 PM > To: The Friday Morning Applied Complexity Coffee Group > Subject: Re: [FRIAM] Classification of ABM's > > Jim, > > I cheerfully concede that one is free to view the universe or any of its > subcomponents through an astoundingly large variety of frames of reference > (FOR). Whichever FOR best gets a person through the day is the one that > should be used. As a not-so-extreme example, an acquaintance of mine has > adopted a particular FOR that allows him to believe with every fiber in his > being that the Mountain Meadows Massacre< > http://en.wikipedia.org/wiki/Mountain_Meadows_massacre> of September, 1857 > (an event that occurred well within the annals of recorded history) was > perpetrated by American Indians. > > Myself, I prefer to us a FOR that requires the minimum of force-fitting to > help me get my job done. However, those of you out there who have this > apparent burning desire to see taxonomy structure as the frame of reference > which will provide the guiding light into the magical mystery wonderland of > successful ABM design, go for it! > > Myself, I don't see much traction there. But, on the other hand, I believe > the Mountain Meadows Massacre was on Mormons by other Mormons. Go figure. > > --Doug > > On Sun, Jan 4, 2009 at 11:54 AM, Nicholas Thompson < > [email protected]<mailto:[email protected]>> wrote: > Jim, > > Don't blame the form of the question on Doug. > > I supplied the straw. > > Nick > > Nicholas S. Thompson > Emeritus Professor of Psychology and Ethology, > Clark University ([email protected]<mailto:[email protected]>) > > > > > > [Original Message] > > From: Jim Gattiker <[email protected]<mailto: > [email protected]>> > > To: <[email protected]<mailto:[email protected]>>; The > Friday Morning Applied Complexity > Coffee Group <[email protected]<mailto:[email protected]>> > > Date: 1/4/2009 8:57:28 AM > > Subject: Re: [FRIAM] Classification of ABM's > > > > > AHA! you DO have a taxonomy. > > > > To pile on here (I suspect Doug can take it): > > > > Doug, after you set up the straw man that there was no taxonomy > > possible, you went on to discuss how you believe there is, in an > > implementation sense, a core set of ABM features. I suggest also that > > software engineers work on ABM environments because the notion of a > > core functionality augmented with structured parts is a compelling > > idea. IF there's a core set of features, AND there are consequent > > optional features, THEN this is a taxonomy. No? At least in > > implementation. > > > > --jim > > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > > > >
============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
