Friam

Fwd: ABM

Classic

List

Threaded

53 messages Options

123

Robert Holmes

Fwd: ABM

On 6/2/07, Douglas Roberts <doug at parrot-farm.net> wrote:
>
> <snip>
> [*Footnote from the (or should be) above: I know people who have written
> applications with no object-oriented technologies at all, using FORTRAN or
> C, (or worse, purely procedural Java) and who claim to have developed an
> ABM. I contend, that while they may have developed a really neato
> simulation, it isn't an ABM. Where are the agents? Rows of an array?
> Elements of a struct? An array of structs? I really don't think so.

Why? Logically that position doesn't make sense - it seems to confuse the
model with the implementation of the model. For example, Epstein & Axtell's
Sugarscape model is an ABM. If I code it up, does it only remain an ABM if I
code in C++? Does the Sugarscape model suddenly stop being an ABM if I code
it in FORTRAN?

It might be easier to code in one type of language rather than the other,
but that's not the point. ABM-ness is a property of the model, not the code.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20070604/0ac05709/attachment.html

Douglas Roberts-2

Fwd: ABM

Why use OO methodologies to implement an application that is inherently
object-based?

For the same reason you don't use assembly language to write business
applications: it would be bad computer science. You could write an ABM in
any language, including assembly, but why in the world would you want to do
that?

This is not confusing the agent based design with its implementation.
Rather, it is recognizing the characteristics of the design and picking an
implementation environment that makes sense. Also note that I never
suggested which OO languages should be used -- that choice depends on the
implementation requirements for the project.

As a side note, it is interesting to observe the growth in usage of
higher-level languages for implementing ABMs in the HPC environment. We are
currently investigating with The MathWorks the use of MATLAB's OO
capabilities and their Distributed Computing Toolkit (DCT) to implement
distributed ABMs on one of our Linux clusters...

--Doug

--
Doug Roberts, RTI International
droberts at rti.org
doug at parrot-farm.net
505-455-7333 - Office
505-670-8195 - Cell

On 6/4/07, Robert Holmes <robert at holmesacosta.com> wrote:

>
>
>
> On 6/2/07, Douglas Roberts <doug at parrot-farm.net> wrote:
> >
> > <snip>
> > [*Footnote from the (or should be) above: I know people who have
> > written applications with no object-oriented technologies at all, using
> > FORTRAN or C, (or worse, purely procedural Java) and who claim to have
> > developed an ABM. I contend, that while they may have developed a really
> > neato simulation, it isn't an ABM. Where are the agents? Rows of an array?
> > Elements of a struct? An array of structs? I really don't think so.
>
>
> Why? Logically that position doesn't make sense - it seems to confuse the
> model with the implementation of the model. For example, Epstein &
> Axtell's Sugarscape model is an ABM. If I code it up, does it only remain an
> ABM if I code in C++? Does the Sugarscape model suddenly stop being an ABM
> if I code it in FORTRAN?
>
> It might be easier to code in one type of language rather than the other,
> but that's not the point. ABM-ness is a property of the model, not the code.
>
> Robert
>
>
> ============================================================
> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20070604/b446e72d/attachment.html

Marcus G. Daniels

Fwd: ABM

Douglas Roberts wrote:

> Why use OO methodologies to implement an application that is
> inherently object-based
I think that the term `OO methodologies', at least in its popular usage
(e.g. C++, Java), is an inadequate foundation for the diversity of
ABMs. Specifically, constraints like classes that have fixed layouts,
fixed sets of methods, no practical way to mutate method
implementations, etc.
There are clearly large classes of models where the OOP features of C++
and Java are just fine, and they are the right tool for the job.

But it seems to me that because the actual work that goes into making a
industrial strength compiler is so much bigger than the work that goes
into an ABM (by orders of magnitude), that ABMs have tended to become
restricted by what popular OOP tools can do.
> You could write an ABM in any language, including assembly, but why in
> the world would you want to do that?
Some reasons:

1) because the use of OO methodologies used in many ABMs are often very
basic and require very little software support, e.g. just containers and
messaging

2) simple code is easier to explain to non-programmers

3) simple things can be optimized effectively, and computer performance
is often a rate limiting factor in ABM

John Goekler-2

Fwd: ABM

In reply to this post by Tom Johnson

Ah . . . the Zen of Complexity. (Or, is that the Complexity of Zen?)

What about continuous multi-directionality of information flow as each agent
/ entity continuously scans its horizons, assigns meanings to identified
patterns (accurately or not!), sends that out over its network(s) and adapts
its behavior according to the degree of perturbation? (Thus also impacting
the behavior of the larger systems within which it is nested, which may in
turn engender pushback or other repressive adaptations.)

Further, I would suggest that in Complex Adaptive Social Systems (the kind
we all live and work in) structures generate patterns of behavior, but
patterns can also be structures. (To complicate it further, structures can
also be seen as the 'physical' manifestation of relationships among the
agents, continually arising, being present and operational for a time, then
condensing and dissolving to make way for new relationships and structures.)

This aligns with the observation by Fontana and others that, initially,
agents shape networks. Later, networks shape agents, often to the point
that the agents can be exchanged in significant numbers without
substantially altering the behavior of the system.

The classic example of this is how change initiatives in organizations so
often excite the organism's 'immune response' which then stamps out the
invading idea / carrier.

At that stage, the question (in my mind) becomes, 'If the system's
reinforcement of its patterns have become the dominant initial condition,
what then are the high leverage interventions we can take to alter the
system's behavior?'

On 6/3/07, Tom Johnson <tom at jtjohnson.com> wrote:

>
> Robert:
>
> It seems to me that there is usually (always?) bi-directionality involved
> in a dynamic system, especially between the individual and the collective.
> The collective often (Usually? Always?) provides a context that generates
> and governs data flow, a time frame, rugged landscapes or not, etc. Such
> data flows can hinder or enhance the individual's decisions and actions and,
> possibly, those of the collective.
>
> -Tom
>
>
> On 6/3/07, Robert Howard <rob at symmetricobjects.com> wrote:
> >
> > Interesting paper!
> >
> > I do like seeing the phrase:
> >
> >
> >
> > Individual-based models (IBMs) allow researchers to study how system
> > level properties emerge from the adaptive behaviour of individuals
> >
> >
> >
> > The collective presupposes the individual.
> >
> > Information and properties of the part flow to the whole?not the other
> > way around.
> >
> > The cause-and-effect arrow of implication is one-way.
> >
> >
> >
> > Robert Howard
> > Phoenix, Arizona
> >
> >
> > ------------------------------
> >
> > *From:* friam-bounces at redfish.com [mailto:friam-bounces at redfish.com] *On
> > Behalf Of *Douglas Roberts
> > *Sent:* Friday, June 01, 2007 11:25 AM
> > *To:* The Friday Morning Applied Complexity Coffee Group
> > *Subject:* [FRIAM] Fwd: ABM
> >
> >
> >
> > FRIAMers,
> >
> > I received this today from several of my co-workers and thought I'd pass
> > it on.
> >
> > I still can't help but feeling that in general, *way* too many words are
> > being used to describe ABM (and IBM) methodologies. The underlying concept
> > of object-oriented software design as the basis for ABM simulation
> > architecture is just so straight forward and intuitive that I am repeatedly
> > amazed at how people continue to make such a big, mysterious deal out of it.
> >
> >
> > But, I suppose that's just me, and my opinion...
> >
> > --Doug
> >
> > --
> > Doug Roberts, RTI International
> > droberts at rti.org
> > doug at parrot-farm.net
> > 505-455-7333 - Office
> > 505-670-8195 - Cell
> >
> >
> > ****************************************************
> >
> > This is a very interesting resource re: Agent Based Modeling.
> >
> >
> >
> > http://www.openabm.org/site/
> >
> >
> >
> > Note also the current efforts re: ODD (Overview, Design Concepts and
> > Details) ?based descriptions (cf. attached manuscript).
> >
> >
> >
> >
> >
> >
> >
> > ============================================================
> > 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
> >
>
>
>
> --
> ==========================================
> J. T. Johnson
> Institute for Analytic Journalism -- Santa Fe, NM USA
> www.analyticjournalism.com
> 505.577.6482(c) 505.473.9646(h)
> http://www.jtjohnson.com tom at jtjohnson.us
>
> "You never change things by fighting the existing reality.
> To change something, build a new model that makes the
> existing model obsolete."
> -- Buckminster Fuller
> ==========================================
> ============================================================
> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20070604/b7806060/attachment.html

Prof David West

Fwd: ABM

You are describing culture and the problem of culture change - I am
reading into your post a description of culture and the problem of
culture change.

An extended metaphor:

Begin with Hopfield's topographic, metaphorical, explanation of
neural net function. The topography is shaped by the weights
assigned to each node in the network. Inputs are akin to rain
falling on a landscape, flowing downhill and collecting in low spots
which are the outputs of the system. Basic feedback mechanisms
allow for changing of weights based on "correct" correspondence
between inputs and outputs.

Consider the effect of making node weights dependent on the constancy
of inputs (constancy = consistency + frequency) and allow for outputs
to alter the context generating the inputs to increase or decrease
constancy. Now you have a continuous mult-directional information
flows - a model of co-evolution of context and agent. You see the
same kind of patterns as are evident in observation of the
interaction of individuals with their culture.

Every time an individual adopts a specific behavior (or dons a
particular form of clothing, or places a particular idol in her
household, or sings a particular jingle) constancy of inputs changes,
the topography changes, and the likelyhood of particular outputs is
altered.

"The high leverage interventions we can take to alter the system's
behavior" = anything that affects constancy - which is everything,
unfortunately. Interventions always arise from an individual act and
there is not way to determine in advance which individual act is
likely to be replicated by others in sufficient numbers to
precipitate a tipping point and a macro-change in culture (the
enveloping system).

You can observe some "tipping points" and predict general properties
of a resulting macro-change but not a lot. Some examples from
anthropology:
Individual farmers generate a storable food surplus (better
agronomy, better preservation, whatever) - tipping point is roughly
a years supply of stored food for the community - result is
invention of organized religion with specialist priests followed
shortly by some sort of "kingship" supported by the organized
church.
Individuals acquire rapid mobility (roughly one day's horseback ride
in less than an hour) - tipping point is roughly half the population
having this access - result is sexual revolution, breakdown of
nuclear extended family, and degeneration of "traditional values."

davew

On Mon, 4 Jun 2007 11:15:50 -0600, "John Goekler"
<bluesbearsf at gmail.com> said:

> Ah . . . the Zen of Complexity. (Or, is that the Complexity of Zen?)
>
>
>
> What about continuous multi-directionality of information flow as each
> agent
> / entity continuously scans its horizons, assigns meanings to identified
> patterns (accurately or not!), sends that out over its network(s) and
> adapts
> its behavior according to the degree of perturbation? (Thus also
> impacting
> the behavior of the larger systems within which it is nested, which may
> in
> turn engender pushback or other repressive adaptations.)
>
>
>
> Further, I would suggest that in Complex Adaptive Social Systems (the
> kind
> we all live and work in) structures generate patterns of behavior, but
> patterns can also be structures. (To complicate it further, structures
> can
> also be seen as the 'physical' manifestation of relationships among the
> agents, continually arising, being present and operational for a time,
> then
> condensing and dissolving to make way for new relationships and
> structures.)
>
>
>
> This aligns with the observation by Fontana and others that, initially,
> agents shape networks. Later, networks shape agents, often to the point
> that the agents can be exchanged in significant numbers without
> substantially altering the behavior of the system.
>
>
>
> The classic example of this is how change initiatives in organizations so
> often excite the organism's 'immune response' which then stamps out the
> invading idea / carrier.
>
>
>
> At that stage, the question (in my mind) becomes, 'If the system's
> reinforcement of its patterns have become the dominant initial condition,
> what then are the high leverage interventions we can take to alter the
> system's behavior?'
>
>
>
>
>
>
>
>
>
>
> On 6/3/07, Tom Johnson <tom at jtjohnson.com> wrote:
> >
> > Robert:
> >
> > It seems to me that there is usually (always?) bi-directionality involved
> > in a dynamic system, especially between the individual and the collective.
> > The collective often (Usually? Always?) provides a context that generates
> > and governs data flow, a time frame, rugged landscapes or not, etc. Such
> > data flows can hinder or enhance the individual's decisions and actions and,
> > possibly, those of the collective.
> >
> > -Tom
> >
> >
> > On 6/3/07, Robert Howard <rob at symmetricobjects.com> wrote:
> > >
> > > Interesting paper!
> > >
> > > I do like seeing the phrase:
> > >
> > >
> > >
> > > Individual-based models (IBMs) allow researchers to study how system
> > > level properties emerge from the adaptive behaviour of individuals
> > >
> > >
> > >
> > > The collective presupposes the individual.
> > >
> > > Information and properties of the part flow to the whole—not the other
> > > way around.
> > >
> > > The cause-and-effect arrow of implication is one-way.
> > >
> > >
> > >
> > > Robert Howard
> > > Phoenix, Arizona
> > >
> > >
> > > ------------------------------
> > >
> > > *From:* friam-bounces at redfish.com [mailto:friam-bounces at redfish.com] *On
> > > Behalf Of *Douglas Roberts
> > > *Sent:* Friday, June 01, 2007 11:25 AM
> > > *To:* The Friday Morning Applied Complexity Coffee Group
> > > *Subject:* [FRIAM] Fwd: ABM
> > >
> > >
> > >
> > > FRIAMers,
> > >
> > > I received this today from several of my co-workers and thought I'd pass
> > > it on.
> > >
> > > I still can't help but feeling that in general, *way* too many words are
> > > being used to describe ABM (and IBM) methodologies. The underlying concept
> > > of object-oriented software design as the basis for ABM simulation
> > > architecture is just so straight forward and intuitive that I am repeatedly
> > > amazed at how people continue to make such a big, mysterious deal out of it.
> > >
> > >
> > > But, I suppose that's just me, and my opinion...
> > >
> > > --Doug
> > >
> > > --
> > > Doug Roberts, RTI International
> > > droberts at rti.org
> > > doug at parrot-farm.net
> > > 505-455-7333 - Office
> > > 505-670-8195 - Cell
> > >
> > >
> > > ****************************************************
> > >
> > > This is a very interesting resource re: Agent Based Modeling.
> > >
> > >
> > >
> > > http://www.openabm.org/site/
> > >
> > >
> > >
> > > Note also the current efforts re: ODD (Overview, Design Concepts and
> > > Details) –based descriptions (cf. attached manuscript).
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ============================================================
> > > 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
> > >
> >
> >
> >
> > --
> > ==========================================
> > J. T. Johnson
> > Institute for Analytic Journalism -- Santa Fe, NM USA
> > www.analyticjournalism.com
> > 505.577.6482(c) 505.473.9646(h)
> > http://www.jtjohnson.com tom at jtjohnson.us
> >
> > "You never change things by fighting the existing reality.
> > To change something, build a new model that makes the
> > existing model obsolete."
> > -- Buckminster Fuller
> > ==========================================
> > ============================================================
> > 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

Fwd: ABM

In reply to this post by Marcus G. Daniels

In that case, you will positively *hate* Charm++:

Charm++, is a fairly sophisticated parallel programming language and runtime
system that facilitates load balancing, latency hiding, and fault tolerance
through processor virtualization. Applications built upon Charm++ create
parallel objects (""chares"") which then communicate through the runtime
system. Through virtualization and asynchronous communication, portably
scalable applications can be developed, with interconnect- and
communications layer-specific optimizations efficiently and transparently
handled in the Charm++ runtime system. The runtime system can also be tuned
for virtually any architecture to manage object creation for data locality
and to schedule execution of virtual processes to overlap communication with
computation. Charm++ features most relevant to performance on many-core
petascale architectures include data object prioritizing and dynamic load
balancing.

Each parallel task is implemented in Charm++ as an object, which is
scheduled for execution by the runtime engine. Through categorization of the
parallel task objects, the runtime system can selectively prioritize
communications to exploit data locality and to maximize bandwidth. On
many-core architectures, we will apply dynamic object prioritizing to
differentiate objects having data dependencies with only within their
respective nodes from objects that have off-node dependencies. Such
differentiation will reduce traffic on the network interconnect and increase
the overlap of communication and computation.

Dynamic load balancing greatly increases the scalability of Charm++
applications. The runtime system tracks statistics for communication and
computation of each object. The execution statistics are periodically
compared, and because Charm++ parallel objects are not
processornode-centric, objects that are taking excessive amounts of time are
migrated to processors nodes that are less heavily loaded. Load balancing
can be performed across the whole machine or a subset of the machine. For
example, in molecular dynamics simulations, the movement of large- scale
molecular systems is relatively small in relation to the small time steps,
so load balancing after several 100s to 1000s of time steps achieves optimal
layouts that apply with little modification for the remainder of the
simulation. These types of algorithms are among the most difficult of to
load balance, ing cases and Charm++ has unique capabilities include for
local load- balancing and topology awareness which will be absolutely
essential for providing maximum performance on many-core petascale
architectures.

On 6/4/07, Marcus G. Daniels <marcus at snoutfarm.com> wrote:

>
> Douglas Roberts wrote:
>
>
> > You could write an ABM in any language, including assembly, but why in
> > the world would you want to do that?
> Some reasons:
>
> 1) because the use of OO methodologies used in many ABMs are often very
> basic and require very little software support, e.g. just containers and
> messaging
>
> 2) simple code is easier to explain to non-programmers
>
> 3) simple things can be optimized effectively, and computer performance
> is often a rate limiting factor in ABM
>
>
> ============================================================
> 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
>

--
Doug Roberts, RTI International
droberts at rti.org
doug at parrot-farm.net
505-455-7333 - Office
505-670-8195 - Cell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20070604/8471f73b/attachment.html

Robert Howard-2-3

Fwd: ABM

In reply to this post by Marcus G. Daniels

Maybe we're thinking differently on the definition of bi-directionality. I'm
using the term as similar to circular logic. One of the fundamental
principles of programming discipline is to remove cycles in the dependencies
between objects. It's called the Acyclic
<http://ifacethoughts.net/2006/03/24/design-principles/> Dependency
Principle (ADP). Compilers work more efficiently. Components can be
unit-tested in isolation.

When modeling a dynamic system, finite state
<http://en.wikipedia.org/wiki/Finite_state_machine> transition diagrams are
used. It is important to understand (1) why cycles are a bad thing; and (2)
why they initially seem to make intuitive sense. First, cycles are bad
because they cause paradoxes. When a paradox occurs (i.e. a cycle), it's
almost always a result of using the wrong model, or not thinking hard enough
about a problem. Cycles prevent formal causal analysis; i.e. scientific
analysis. For example, "Which came first, the chicken or the egg?" This
sounds like a paradox because we often use the wrong model; i.e. "chickens
cause eggs, and eggs cause chickens." But the correct model is: "All
chickens come from eggs. But not all eggs come from chickens." And this
resolves the paradox. The egg came first!

So when you see something like Figure 1 appear in a design, you can get rid
of the long-term adverse affects in the system by restructuring it to Figure
2.

Black arrows represent direct composition or "has a" relationships, where
white arrows represent inheritance or "is a" relationships. In short, Figure
1 says A calls B directly and B calls A directly. Figure 2 says A calls the
interface IB, and B calls the interface of IA. And A implements IA and B
implements IB. There are no cycles in Figure B. Figure B works exactly like
Figure A, but Figure A will cause more bug, have more errors, cost more, and
take longer to evolve than Figure B-at least in software architecture.

Robert Howard

Phoenix, Arizona

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf
Of Marcus G. Daniels
Sent: Sunday, June 03, 2007 9:13 PM
To: The Friday Morning Applied Complexity Coffee Group
Subject: Re: [FRIAM] Fwd: ABM

Tom Johnson wrote:

> It seems to me that there is usually (always?) bi-directionality

> involved in a dynamic system

i.e. http://en.wikipedia.org/wiki/Stigmergy

============================================================

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20070604/c078e089/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 6245 bytes
Desc: not available
Url : http://redfish.com/pipermail/friam_redfish.com/attachments/20070604/c078e089/attachment.jpe

Robert Howard-2-3

Fwd: ABM

In reply to this post by Douglas Roberts-2

I agree. OO is a better modeling tool for ABM?s.

OO gives us something that structured programming (SP) does not?more
constraints!

SP gives us something that machine language (ML) does not?more constraints!

With ML, we can jump around all over the place, ignoring stack, types, and
other rules. It?s spaghetti city!

SP constrains jumps to WHILE, FOR, and IF statements. But SP allows lots of
global variables and functions that are disconnected from their types.

OO constrains scope far more, and insists that functions (i.e. methods) are
connected to their types. In fact, OO compilers force the subject (the main
object of interest) to be the first parameter in a calling convention, and
then hides that fact from the programmer. The code becomes far more readable
and easier for a reader to get the authors idea.

The more ?good? constraints (or boundaries) we adopt and practice in our
lives, which require wisdom and self discipline, the easier it becomes to
formally analyze our inventions and communicate them to others for peer
review.

Robert Howard
Phoenix, Arizona

_____

From: [hidden email] [mailto:[hidden email]] On Behalf
Of Douglas Roberts
Sent: Monday, June 04, 2007 8:59 AM
To: The Friday Morning Applied Complexity Coffee Group
Subject: Re: [FRIAM] Fwd: ABM

Why use OO methodologies to implement an application that is inherently
object-based?

For the same reason you don't use assembly language to write business
applications: it would be bad computer science. You could write an ABM in
any language, including assembly, but why in the world would you want to do
that?

This is not confusing the agent based design with its implementation.
Rather, it is recognizing the characteristics of the design and picking an
implementation environment that makes sense. Also note that I never
suggested which OO languages should be used -- that choice depends on the
implementation requirements for the project.

As a side note, it is interesting to observe the growth in usage of
higher-level languages for implementing ABMs in the HPC environment. We are
currently investigating with The MathWorks the use of MATLAB's OO
capabilities and their Distributed Computing Toolkit (DCT) to implement
distributed ABMs on one of our Linux clusters...

--Doug

--
Doug Roberts, RTI International
droberts at rti.org
doug at parrot-farm.net
505-455-7333 - Office
505-670-8195 - Cell

On 6/4/07, Robert Holmes <robert at holmesacosta.com> wrote:

On 6/2/07, Douglas Roberts <doug at parrot-farm.net > wrote:

<snip>
[*Footnote from the (or should be) above: I know people who have written
applications with no object-oriented technologies at all, using FORTRAN or
C, (or worse, purely procedural Java) and who claim to have developed an
ABM. I contend, that while they may have developed a really neato
simulation, it isn't an ABM. Where are the agents? Rows of an array?
Elements of a struct? An array of structs? I really don't think so.

Why? Logically that position doesn't make sense - it seems to confuse the
model with the implementation of the model. For example, Epstein & Axtell's
Sugarscape model is an ABM. If I code it up, does it only remain an ABM if I
code in C++? Does the Sugarscape model suddenly stop being an ABM if I code
it in FORTRAN?

It might be easier to code in one type of language rather than the other,
but that's not the point. ABM-ness is a property of the model, not the code.

Robert

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20070604/9424aaef/attachment.html

Marcus G. Daniels

Fwd: ABM

Robert Howard wrote:
>
> The more ?good? constraints (or boundaries) we adopt and practice in
> our lives, which require wisdom and self discipline, the easier it
> becomes to formally analyze our inventions and communicate them to
> others for peer review.
>
Unless they are "bad" constraints and only limit one's imagination about
what the way the ways the world actually might work. Of course, even
machine language (of Von Neumann CPU type architectures) is a
constraint. The question is not whether to accept some constraints
(there is no practical choice in that), it's whether the constraints
ones chooses turn out to be well matched to the thing being studied.
It's not like there is always this clean line between the known and
unknown. I think one must have a repertoire of approaches to try.

It would be nice if there was a clean line between the known and
unknown. Then it would be an argument about software engineering.
The situation is more like a modeler thinks that that something acts
within some range of parameters or plausible mechanisms and the details
parameters and behaviors are arguable or need to be found. Nailing them
down into some rigid type system won't necessarily help do that. It
could even obscure insight.
> With ML, we can jump around all over the place, ignoring stack, types,
> and other rules. It?s spaghetti city!
Do you expect a terrorist or virus to follow these nice rules and proper
software engineering practice?
> The code becomes far more readable and easier for a reader to get the
> authors idea.
Yes, if the author (or machine learning system) even has a model that
works at all..

glen ep ropella

Fwd: ABM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcus G. Daniels wrote:
> It would be nice if there was a clean line between the known and
> unknown. Then it would be an argument about software engineering.
> The situation is more like a modeler thinks that that something acts
> within some range of parameters or plausible mechanisms and the details
> parameters and behaviors are arguable or need to be found. Nailing them
> down into some rigid type system won't necessarily help do that. It
> could even obscure insight.

Worse yet, the modeler might rapidly squeeze a round peg into a square
hole late one night just to get the damn code working, then 9 months
down the line find herself concluding that the pegs actually are square.

I.e. the more one relies on frameworks (like OOP), the more difficult it
is to make conclusions independent of the assumptions of those
frameworks. That means that frameworks might lead to question begging
results.... circular arguments.

- --
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
I have the heart of a child. I keep it in a jar on my shelf. -- Robert Bloch

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZIQoZeB+vOTnLkoRAkBlAJ9ciB1cAjU8g6zim+n2XruztjRsnQCgxR1V
/oGjC10ru2uOGXRrJFh7yn0=
=ao7r
-----END PGP SIGNATURE-----

Robert Howard-2-3

Fwd: ABM

That's what modeling is! A framework for understanding! A tool for
communication!

The less constrained a framework is, the less useful it is.

Think about it. A hammer is useful because it has a rigid body that hits
nails on the head. No one would use it if the handle was made of flexible
rubber that went all over the place.

If we have many different interpretations for words and symbols, is not our
language less accurate and useful? We'd spend more time explaining what our
interpretation du jour is and waste time assuming we both are on the same
page when we're really not.

A framework is a catalyst for communication! When it inhibits knowledge
transfer, it's abandoned by better ones. Relativity is a more accurate,
useful framework than Newtonian because it adds more constraining rules,
like the space-time invariant and E=MC^2.

A good constrained framework prevents a modeler from putting a square peg in
a round hole. The less constrained ones allow more entropy.

Robert Howard

Phoenix, Arizona

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf
Of Glen E. P. Ropella
Sent: Monday, June 04, 2007 2:29 PM
To: The Friday Morning Applied Complexity Coffee Group
Subject: Re: [FRIAM] Fwd: ABM

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Marcus G. Daniels wrote:

> It would be nice if there was a clean line between the known and

> unknown. Then it would be an argument about software engineering.

> The situation is more like a modeler thinks that that something acts

> within some range of parameters or plausible mechanisms and the details

> parameters and behaviors are arguable or need to be found. Nailing them

> down into some rigid type system won't necessarily help do that. It

> could even obscure insight.

Worse yet, the modeler might rapidly squeeze a round peg into a square

hole late one night just to get the damn code working, then 9 months

down the line find herself concluding that the pegs actually are square.

I.e. the more one relies on frameworks (like OOP), the more difficult it

is to make conclusions independent of the assumptions of those

frameworks. That means that frameworks might lead to question begging

results.... circular arguments.

- --

glen e. p. ropella, 971-219-3846, http://tempusdictum.com

I have the heart of a child. I keep it in a jar on my shelf. -- Robert Bloch

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZIQoZeB+vOTnLkoRAkBlAJ9ciB1cAjU8g6zim+n2XruztjRsnQCgxR1V

/oGjC10ru2uOGXRrJFh7yn0=

=ao7r

-----END PGP SIGNATURE-----

============================================================

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20070604/a33db01c/attachment.html

Marcus G. Daniels

Fwd: ABM

Robert Howard wrote:
>
> Think about it. A hammer is useful because it has a rigid body that
> hits nails on the head. No one would use it if the handle was made of
> flexible rubber that went all over the place.
>
And when all you have is hammer, everything starts to look like a nail..

Robert Howard-2-3

Fwd: ABM

That's why we have many different highly-constrained tools in a tool box
rather than a single super-flexible unconstrained one.

Robert Howard
Phoenix, Arizona

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf
Of Marcus G. Daniels
Sent: Monday, June 04, 2007 3:55 PM
To: The Friday Morning Applied Complexity Coffee Group
Subject: Re: [FRIAM] Fwd: ABM

Robert Howard wrote:
>
> Think about it. A hammer is useful because it has a rigid body that
> hits nails on the head. No one would use it if the handle was made of
> flexible rubber that went all over the place.
>
And when all you have is hammer, everything starts to look like a nail..

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

Fwd: ABM

In reply to this post by Robert Howard-2-3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Howard wrote:
> That's what modeling is! A framework for understanding! A tool for
> communication!

I disagree. Modeling is not _a_ framework. It is the _process_ of
building a framework. Modeling is a behavior, not a state. The outcome
of modeling is the framework.

More specifically, modeling is rhetoric. When you build a model, you
are making an argument that proceeds from premises to conclusion.

When one uses a pre-existing framework (e.g. continuum math) in which to
couch their argument, then one has to ensure that all the assumptions in
the framework are satisfied by the rest of the rhetoric. And the
argument does not apply if any of those assumptions are not satisfied by
the referent. Worse yet, it's inconsistent if any sentence in the
argument contradicts one of the others. (Note that circular arguments
can be useful, particularly in models of complex systems, as long as the
circularity is clear and identified.)

> The less constrained a framework is, the less useful it is.

No. A less complicated framework is good for less complicated
arguments. A more complicated framework is good for more complicated
arguments. Both are equally useful depending on what they're being used
for.

More specifically, a less complicated framework is good for
_generalizable_ (abstract) results. A more complicated framework is
good for more particular (concrete) results.

This is one of the reasons ABM is considered good for very particular
(concrete) situations and analytically soluble models are often less
applicable. It's also the reason why, if you can achieve them,
analytically soluble models are much more powerful than ABMs. (Hence
all the yammering we hear about "over-parameterized" or "over-fitted".)

> If we have many different interpretations for words and symbols, is not
> our language less accurate and useful? We'd spend more time explaining
> what our interpretation du jour is and waste time assuming we both are
> on the same page when we're really not.

No. Multiple meanings for symbols doesn't make the language less
accurate or less useful. It only means that an argument, built using
the language, must be more specific than the language, itself.

Very ambiguous human languages are quite useful and are in no danger of
being replaced by unambiguous languages. Further, an argument can be
made that the ambiguity in languages makes them _more_ useful than
strict languages. Even further, most (perhaps _all_) models that show
actual, practical impact on our world are built up using ambiguous human
language, not rigid unambiguous ones. Even in those cases where part of
the model is rigidly specified with, say, math, the rigid part is bathed
in a gloriously ambiguous soup of unending prose.

These arguments (sentences) can be excruciatingly detailed even though
the symbols in the underlying language are very ambiguous.

> A framework is a catalyst for communication! When it inhibits knowledge
> transfer, it's abandoned by better ones. Relativity is a more accurate,
> useful framework than Newtonian because it adds more constraining rules,
> like the space-time invariant and E=MC^2.

[grin] No _sane_ person would abandon Newtonian physics. Instead, what
we do is use one when it's appropriate and the other when it's
appropriate. Appropriateness is determined in our usual ambiguous way.

> A good constrained framework prevents a modeler from putting a square
> peg in a round hole. The less constrained ones allow more entropy.

Exactly! But only the gods know what that slimy programmer did when the
modeler wasn't looking.

- --
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
Cynics regarded everybody as equally corrupt... Idealists regarded
everybody as equally corrupt, except themselves. -- Robert Anton Wilson

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZKnMZeB+vOTnLkoRAk0eAJ0T9bOkJwpuVg5pb1jYpbVo/iTvdACfbmDC
useMaG6WTTvQsLdukq7JkyM=
=uhQq
-----END PGP SIGNATURE-----

Robert Howard-2-3

Fwd: ABM

Yes. Modeling is a verb, and a framework is a noun. I concede.

Should I say that modeling is the process of creating a framework for
understanding?

(Note that circular arguments can be useful, particularly in models of
complex systems, as long as the circularity is clear and identified.)

My mind rejects circular arguments. I can't help it! Maybe it's genetic. I'm
embarrassed when I do it.

Multiple meanings for symbols doesn't make the language less accurate or
less useful.

The more we truly agree on a set of definitions, the more and faster we can
communicate.

No sane person would abandon Newtonian physics.

You don't have to with Relativity. It already includes Newtonian physics.

Exactly! But only the gods know what that slimy programmer did when the
modeler wasn't looking.

LOL

Robert Howard

Phoenix, Arizona

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf
Of Glen E. P. Ropella
Sent: Monday, June 04, 2007 5:10 PM
To: The Friday Morning Applied Complexity Coffee Group
Subject: Re: [FRIAM] Fwd: ABM

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Robert Howard wrote:

> That's what modeling is! A framework for understanding! A tool for

> communication!

I disagree. Modeling is not _a_ framework. It is the _process_ of

building a framework. Modeling is a behavior, not a state. The outcome

of modeling is the framework.

More specifically, modeling is rhetoric. When you build a model, you

are making an argument that proceeds from premises to conclusion.

When one uses a pre-existing framework (e.g. continuum math) in which to

couch their argument, then one has to ensure that all the assumptions in

the framework are satisfied by the rest of the rhetoric. And the

argument does not apply if any of those assumptions are not satisfied by

the referent. Worse yet, it's inconsistent if any sentence in the

argument contradicts one of the others. (Note that circular arguments

can be useful, particularly in models of complex systems, as long as the

circularity is clear and identified.)

> The less constrained a framework is, the less useful it is.

No. A less complicated framework is good for less complicated

arguments. A more complicated framework is good for more complicated

arguments. Both are equally useful depending on what they're being used

for.

More specifically, a less complicated framework is good for

_generalizable_ (abstract) results. A more complicated framework is

good for more particular (concrete) results.

This is one of the reasons ABM is considered good for very particular

(concrete) situations and analytically soluble models are often less

applicable. It's also the reason why, if you can achieve them,

analytically soluble models are much more powerful than ABMs. (Hence

all the yammering we hear about "over-parameterized" or "over-fitted".)

> If we have many different interpretations for words and symbols, is not

> our language less accurate and useful? We'd spend more time explaining

> what our interpretation du jour is and waste time assuming we both are

> on the same page when we're really not.

No. Multiple meanings for symbols doesn't make the language less

accurate or less useful. It only means that an argument, built using

the language, must be more specific than the language, itself.

Very ambiguous human languages are quite useful and are in no danger of

being replaced by unambiguous languages. Further, an argument can be

made that the ambiguity in languages makes them _more_ useful than

strict languages. Even further, most (perhaps _all_) models that show

actual, practical impact on our world are built up using ambiguous human

language, not rigid unambiguous ones. Even in those cases where part of

the model is rigidly specified with, say, math, the rigid part is bathed

in a gloriously ambiguous soup of unending prose.

These arguments (sentences) can be excruciatingly detailed even though

the symbols in the underlying language are very ambiguous.

> A framework is a catalyst for communication! When it inhibits knowledge

> transfer, it's abandoned by better ones. Relativity is a more accurate,

> useful framework than Newtonian because it adds more constraining rules,

> like the space-time invariant and E=MC^2.

[grin] No _sane_ person would abandon Newtonian physics. Instead, what

we do is use one when it's appropriate and the other when it's

appropriate. Appropriateness is determined in our usual ambiguous way.

> A good constrained framework prevents a modeler from putting a square

> peg in a round hole. The less constrained ones allow more entropy.

Exactly! But only the gods know what that slimy programmer did when the

modeler wasn't looking.

- --

glen e. p. ropella, 971-219-3846, http://tempusdictum.com

Cynics regarded everybody as equally corrupt... Idealists regarded

everybody as equally corrupt, except themselves. -- Robert Anton Wilson

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZKnMZeB+vOTnLkoRAk0eAJ0T9bOkJwpuVg5pb1jYpbVo/iTvdACfbmDC

useMaG6WTTvQsLdukq7JkyM=

=uhQq

-----END PGP SIGNATURE-----

============================================================

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20070604/976b1d2a/attachment-0001.html

Marcus G. Daniels

Fwd: ABM

In reply to this post by Douglas Roberts-2

Douglas Roberts wrote:
> In that case, you will positively *hate* Charm++:
>
One disappointing thing about it is that they made a new language that
is mostly like C++ and translate it to C++ code (instead of, say, adding
features to the GCC OpenMP implementation for C++ and cross box thread
migration, or writing a new GCC front end). Seems like it is mostly
an MPI-like object layer, but they maddeningly don't enhance OpenMPI to
their own needs, they do their own thing.

The array stuff reminds me of Chapel (http://chapel.cs.washington.edu),
but this has the benefit of being implemented! Interesting they have
the NAMD molecular dynamics package running on the Cell..

Douglas Roberts-2

Fwd: ABM

There, see? I knew you'd hate it. All I can say is that Charm++ evolved to
its current state to meet a need: to support massively parallel (> 1
million processor) HPC computing environments. It addresses fault tolerance
and dynamic load balancing requirements which become incredibly important
when computing on this scale. It also supports OO software development
methodology, which in spite of a few dissenting voices on this list is
generally viewed as a superior environment for software development (to
include ABM systems) than the old, hoary procedural environments.

--Doug

--
Doug Roberts, RTI International
droberts at rti.org
doug at parrot-farm.net
505-455-7333 - Office
505-670-8195 - Cell

On 6/5/07, Marcus G. Daniels <marcus at snoutfarm.com> wrote:

>
> Douglas Roberts wrote:
> > In that case, you will positively *hate* Charm++:
> >
> One disappointing thing about it is that they made a new language that
> is mostly like C++ and translate it to C++ code (instead of, say, adding
> features to the GCC OpenMP implementation for C++ and cross box thread
> migration, or writing a new GCC front end). Seems like it is mostly
> an MPI-like object layer, but they maddeningly don't enhance OpenMPI to
> their own needs, they do their own thing.
>
> The array stuff reminds me of Chapel (http://chapel.cs.washington.edu),
> but this has the benefit of being implemented! Interesting they have
> the NAMD molecular dynamics package running on the Cell..
>
>
> ============================================================
> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20070605/8e088da4/attachment.html

Douglas Roberts-2

Fwd: ABM

In reply to this post by Marcus G. Daniels

I'm currently at the TeraGrid '07 conference in Madison, WI (
http://www.union.wisc.edu/teragrid07/), and I took an opportunity at one of
the social gatherings last night to share some of the high points of this
thread with a few of the other conference attendees, mostly as a sanity
check for my own benefit.

When I mentioned that there were a few people on this list who felt that OO
methodologies were an impediment to ABM development rather than a benefit,
the general response was disbelief. In the words of one of my Pittsburgh
Supercomputer Center colleagues, "I can't believe any ABM practitioner would
feel that way. OO and ABM fit each other like hand in glove."

But, I suppose it's our differences that continue to make things
interesting.

--Doug

--
Doug Roberts, RTI International
droberts at rti.org
doug at parrot-farm.net
505-455-7333 - Office
505-670-8195 - Cell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20070605/acfdef1b/attachment.html

Marcus G. Daniels

Fwd: ABM

In reply to this post by Douglas Roberts-2

Douglas Roberts wrote:
> It addresses fault tolerance and dynamic load balancing requirements
> which become incredibly important when computing on this scale.
I'd much rather have checkpointing and load balancing done at the
operating system level, like by Linux kernel features (e.g.
http://kvm.qumranet.com/kvmwiki/Migration), Then all the queuing system
would have to do is send suspend/resume signals to processes -- users
could assume processes to persist until killed or finished. Further,
any program would be supported. I find that fitting random jobs
within queueing system resource constraints is a bigger productivity
sink than jobs actually failing from bugs or system problems. The
stakes get higher as the job size gets bigger because you are waiting
longer to get scheduled and once you do you can still absorb a lot of
system resources for a job that ultimately does not complete the way you
want (which in turn increases the wait for future jobs).

It's just nuts this hasn't been addressed properly because the costs are
so high for users (not to mention energy usage).
> It also supports OO software development methodology, which in spite
> of a few dissenting voices on this list is generally viewed as a
> superior environment for software development (to include ABM systems)
> than the old, hoary procedural environments.
OO is just one methodology. Not even everyone that studies typing
systems would say they are doing OOP research.
E.g. some don't really fit at all, like linear typing which lends itself
more to functional programming. And there are other whole viable ways
to approach modeling, e.g. combinatory logic. It's a false choice
between OOP and procedural programming.

glen ep ropella

Fwd: ABM

In reply to this post by Douglas Roberts-2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It sounds like you misrepresented the thread, to me. The point is to
build software according to requirements. Sometimes those requirements
require OO and sometimes they don't.

Those "few who believe OO is an impediment" are actually saying that OO
_can_ sometimes be too much overhead for the task at hand.

Saying some thing _can_ be an impediment is very different from saying
that it is _always_ an impediment.

Douglas Roberts wrote:

> I'm currently at the TeraGrid '07 conference in Madison, WI
> (http://www.union.wisc.edu/teragrid07/), and I took an opportunity at
> one of the social gatherings last night to share some of the high points
> of this thread with a few of the other conference attendees, mostly as a
> sanity check for my own benefit.
>
> When I mentioned that there were a few people on this list who felt that
> OO methodologies were an impediment to ABM development rather than a
> benefit, the general response was disbelief. In the words of one of my
> Pittsburgh Supercomputer Center colleagues, "I can't believe any ABM
> practitioner would feel that way. OO and ABM fit each other like hand
> in glove."
>
> But, I suppose it's our differences that continue to make things
> interesting.

- --
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
Philosophy is a battle against the bewitchment of our intelligence by
means of language. -- Ludwig Wittgenstein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZYOdZeB+vOTnLkoRAk4XAJwMxHt3tkAkw2KefTE9j3vOkWFJygCdEZRc
SEppYOUdPSvypcvPzeHhbHs=
=LMWK
-----END PGP SIGNATURE-----

123