Friam

Classification of ABM's

Classic

List

Threaded

8 messages Options

Nick Thompson

Classification of ABM's

Thanks, Doug.

I am continuing to mull over the idea that the structure comes from the problems, not from the simulations that solve them.

Nick

----- Original Message -----

From: [hidden email]

To: [hidden email];[hidden email]

Sent: 1/4/2009 11:16:21 AM

Subject: Re: [FRIAM] Classification of ABM's

I'm afraid taxonomy, mentally encapsulated or otherwise, has little to do with the way I develop an ABM, Nick. Rather, good software engineering practices provide the tools for success. CMMI provides a reasonable software engineering methodology that emphasizes feedback between the following project phases. CMMI is a good replacement of the old, rigid "Waterfall" SW engineering approach. Not that i am a huge fan of rigid, formal SW engineering approaches, but CMMI at least encourages feedback between the following standard SW project engineering stages:

Develop a requirements doc that states what the problem is, and what the simulation will be required to produce for results.
Develop a design. An ABM design, if the the requirements describe real-world entities that interact with each other in meaningful ways. The ABM modeling approach naturally covers many real world application areas (duh, the universe is populated with enteracting enties, duh), but not all systems are best suted to ABM appproaches for one reason or another.

Select an implementation environment, unless it was specified in the requirements.

Code
Test
V&V
The "magic" involved with being able to develop a successful ABM, or any other kind of simulation derives from the ability to develop a realistic requirements document, followed by appropriately defining the correct levels of abstraction between the real-world entities to be modeled, and their corresponding simulation agents.

Extracting a realistic requirements definition from the client, or as it frequently turns out, helping the client develop one is the most important phase of any SW project. If you allow a fuzzy, ill-defined, vague, contridictory requirements definition to stand, the project will fail.

--Doug

Nicholas S. Thompson

Emeritus Professor of Psychology and Ethology,

Clark University ([hidden email])

Nick Thompson

Re: Classification of ABM's

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 ([hidden email])

> [Original Message]
> From: Jim Gattiker <[hidden email]>
> To: <[hidden email]>; The Friday Morning Applied Complexity
Coffee Group <[hidden email]>

> 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

Douglas Roberts-2

Re: 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 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 <[hidden email]> 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 ([hidden email])

> [Original Message]
> From: Jim Gattiker <[hidden email]>

> To: <[hidden email]>; The Friday Morning Applied Complexity

Coffee Group <[hidden email]>
> 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

John Kennison

Re: Classification of ABM's

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: [hidden email] [[hidden email]] On Behalf Of Douglas Roberts [[hidden email]]
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 <[hidden email]<mailto:[hidden email]>> 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 ([hidden email]<mailto:[hidden email]>)

> [Original Message]
> From: Jim Gattiker <[hidden email]<mailto:[hidden email]>>
> To: <[hidden email]<mailto:[hidden email]>>; The Friday Morning Applied Complexity
Coffee Group <[hidden email]<mailto:[hidden email]>>

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

Douglas Roberts-2

Re: Classification of ABM's

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 <[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Douglas Roberts [[hidden email]]
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 <[hidden email]<mailto:[hidden email]>> 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 ([hidden email]<mailto:[hidden email]>)

> [Original Message]
> From: Jim Gattiker <[hidden email]<mailto:[hidden email]>>
> To: <[hidden email]<mailto:[hidden email]>>; The Friday Morning Applied Complexity
Coffee Group <[hidden email]<mailto:[hidden email]>>

> 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

Steve Smith

Re: Classification of ABM's

Though John's statement *does* beg the question of what is meant by "Agent Based Model". There is a whole galaxy of discussion to be had about "Agency". What is conventionally termed "Agent Based Modeling" only barely references and certainly does not require any significant "agency" on the model's parts.

I can't remember if this can of worms has already been opened and thoroughly sorted through on-list before. I don't need to do that myself, but I suppose I'm asking for it by even offering up the can-opener here!

- Steve

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 <[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Douglas Roberts [[hidden email]]
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 <[hidden email]<mailto:[hidden email]>> 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 ([hidden email]<mailto:[hidden email]>)

> [Original Message]
> From: Jim Gattiker <[hidden email]<mailto:[hidden email]>>
> To: <[hidden email]<mailto:[hidden email]>>; The Friday Morning Applied Complexity
Coffee Group <[hidden email]<mailto:[hidden email]>>

> 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

Marcus G. Daniels

Re: Classification of ABM's

In reply to this post by Douglas Roberts-2

Douglas Roberts wrote:

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

Each of these is a recipe of sorts, and it ought be be possible with
static analysis techniques or runtime profiling (tracking the life and
death of objects, intra-agent mutations, and inter-agent communication)
to detect that recipe, or at least contrast it to others. Like having
cake and knowing it is not a cookie.

Marcus

P.S. Last night's 60 minutes had a fun piece on functional MRI. Person
thinks `hammer' and the computer predicts from the scan data that the
user is thinking `hammer'. Person thinks `apartment', the computer
predicts apartment. Folks at LANL are working on this too
http://www.lanl.gov/quarterly/q_spring03/squid_text.shtml

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

glen e. p. ropella-2

Re: Classification of ABM's

In reply to this post by John Kennison

Thus spake John Kennison circa 05/01/09 08:34 AM:
> 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?

It might be helpful to consider Oren and Yilmaz's (I think it was
theirs) classification of:

agent-oriented simulation
agent-directed simulation
agent-based simulation

My own interpretation (which I forget how well it matches theirs) is
basically that agent-orientation only implies that, regardless of the
implementation, it is useful to _think_ of the objects and behavior as
agents. Indeed, there need not even be any well-formed (quantum/atomic)
units. E.g. a term in an equation over a continuous space might be
_thought_ of as an agent.

An agent-directed simulation is one where the implementation is
unspecified (might be agent-based, might not); but that implementation
is controlled by agents (to which executive control is delegated by the
human).

An agent-based simulation, however, requires the implementation to
consist (primarily) of agents. (However one may define "agent".)

--
glen e. p. ropella, 971-222-9095, http://agent-based-modeling.com

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