Re: Considering a new project & wanting something for nothing

[glen e. p. ropella]

Hey Paul,

A few suggestions: 1) make the "tally" ambiguous, 2) allow for 
varying clique dynamics, and 3) put a cost function on travelling
from clique to clique.

(1) means to put some kind of "modeling" capability into the
individuals' heads so that the information they exchange about
each other (or even about their expert knowledge) tolerates and
propogates error.  This can be as mundane as a simple approximate
encoding or compression scheme.

What that acheives, I think, is a built-in flexibility for the motivations
of different individuals.  If the *tally* is too well-defined, then the 
*optimum* will be well-defined (even if it's dynamic).  And if the 
optimum is well-defined, then it's more difficult to get agents who
only want hamburgers to develop strategies that are complex enough
to allow them to interact with non-hamburger-owners.  I.e. the 
model is too idealized to model things like "I don't like Joe because
Joe doesn't have a hamburger.  Tim has one hamburger, but he 
never gives his hamburgers away.  Joe does, however, know Cindy
who has, in the past given her hamburger away.  So, it might be
better for me to hang out with Joe in order to cozy up to Cindy."

Obviously, one could model stuff like this explicitly with well-defined
a well-defined tally as long as there was sufficient cognate-modeling
tools.  But, my conjecture would be that you could arrive at this 
kind of stuff without those tools as long as you add some error
to the evaluation function.

(2) means that an agent's lexicon or conversational style or 
whatever might distinguish "pleasant" from "unpleasant" might
be easier, more effective, or just plain dominant in one clique
and the opposite in another clique.  What I think this implies is
that you shouldn't use simple lists for the cliques in the MoGrid.
I think some higher-order data structure is in order.  Don't quite
know what, though.

What I think (2) gives you is the flexibility of making clique 
preferences explicit (by defining them as properties of the 
space -- e.g. a moderated email list as opposed to an anarchic
one) or implicit (by defining them as behaviors of the agents
themselves) or both.  If you use simple lists as the data structures
that define the cliques, then you are forced to warp your mind 
around trying to make clique preferences implicit.  Not that this
is a bad thing; but, you might get where you're going sooner if 
you allow for explicit encodings first then gradually shift to 
implicit encodings.

(3) means that some energy must be expended by an agent to 
hop from clique to clique or room to room or whatever.  You've
already got a metric for doing this by using MoGrid; so the 
implementation burden should be minimal.

What I think this buys you is the ability to add a kind of 
malthusian resource to the mix, energy.  With that you will
allow for a kind of trump card that can override "preferences"
by "needs".  For example, discussant X really dislikes all 
the cliques he's visited in his neighborhood.  Making a 
random walk expensive will give that guy a tendency to 
find a satisficing solution rather than wander forever looking
for his most comfortable clique like some 60's teenager justifying
his laziness for years because he's "searching for himself". [grin]

But, again, this is just another parameter.  You could vary
the ambient energy to create a spectrum from depression
economies to boom years, or create non-isotropic distributions
of energy to create energetic-class distinctions.

Anyway, just some suggestions.

glen


At 05:08 PM 6/9/99 -0500, you wrote:
>   1. Individuals who look about for "discussion partners".  They search
>within a "neighborhood" for people they expect will give pleasant
>conversation.  They choose at random among all targets that are equally
>likely to be pleasant.  Pleasant is some combination of agreement with
>own opinion and usefulness in other respects (they may have a hamburger
>you want, etc.)
>   2. There can be discussion between the partners and certain amounts
>of information revealed.  A friend who is a professor at Indiana has
>done lots of empirical work and claims that the other person's opinion
>will have more impact if that person is seen as knowledgable, for
>example.  There are plenty of little details that may have to be ignored
>in the model.
>   3. On the basis of their discussion, individuals can change their
>opinions.  Their knowledge level may be incremented as well, if they
>were a less knowledgable person talking to a more knowledgable person.
>   4. Then they proceed to look for more discussion partners.  There has
>to be some ingredient that creates a tendency to go back to the same
>discussion partners, but also a willingness to look for new ones.
>
>I have been thinking about this for a little while, but didn't work yet
>on designing a simulation.  If you have ideas about it, I'd be glad to
>hear.
>
>Anyway, I got to looking at an app that Pietro Terna is distributing
>called LangtonAntSpace.  I've got version 0.8, but there may be newer
>ones. Anyway, he has an updated version of Sven's upgraded MoGrid2d
>class in there.  That is a  class in which there is a 2d grid, and at
>each one there can be a list of occupants.  The class looks to be well
>designed (thanks, Sven) and updated (thanks Pietro).  Takes into account
>Swarmlib changes through 1.4.
>
>So I got to thinking like this.  What if the world of each agent is
>thought of as a MoGrid2d, and an agent can enter a space on the lattice,
>and then discuss with some elements from the list, then form an opinion
>about the people in that space, and possibly decide to stay or go.  If
>the agent stays, then its participation will affect other agents looking
>to move as well.
>
>Then I started to wonder how I would design record-keeping for each
>agent, a tally of experiences in each cell.  I think I would create a
>Tally object for each cell visited, and in there store whatever
>information was obtained.
>
>I started thinking about creating a Grid2D object inside each agent and
>hanging the Tally objects on the right spots. (Even though the Grid2D
>documentation says it is a space for agents, I don't think it would mind
>holding some other kinds of objects :).    
>
>But then I wondered if there is a way to get something for nothing. 
>Since the MoGrid2d class can answer a message like "getListatX:Y:", and
>it returns a Swarm list object, it seems like I'm getting something for
>nothing by using a Swarm Map with the return from "getListatX:Y:" as the
>key and the Tally object as the item.  I don't have to allocate any
>dynamic memory that way, but I do pay a performance penalty of slow
>searches through the Map for a particular list.
>
>I see a major danger in either of these approaches, however. If a spot
>in the MoGrid2d goes "empty" after an agent has been there, then the
>agent will still possess a Tally for that spot, even though the spot
>does not exist.  If an interation over a Map tries to use a key that no
>longer exists, I think that agent would meet Mr. Segmentation Fault.  
>
>But I don't want to have the MoGrid2d class having to notify every agent
>when a list goes empty in the grid, right? 
>   
>
>-- 
>Paul E. Johnson                       email: address@hidden
>Dept. of Political Science            http://lark.cc.ukans.edu/~pauljohn
>University of Kansas                  Office: (785) 864-9086
>Lawrence, Kansas 66045                FAX: (785) 864-5700
>
>
>                  ==================================
>   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.
>                  ==================================


--
glen e. p. ropella =><= Feeding the hamster wheel.  Hail Eris!
Home: http://www.trail.com/~gepr/home.html      (505) 424-0448
Work: http://www.swarm.com                      (505) 995-0818


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