swarm-modeling
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Swarm-Modelling] Re: [Swarm-Support] Re: Agent communication and gr

From: Darren Schreiber
Subject: Re: [Swarm-Modelling] Re: [Swarm-Support] Re: Agent communication and grid models
Date: Tue, 27 May 2003 02:40:28 -0700
I explained the "soup" model in the parenthetical phrase after I used the term. It means that all agents are capable of interacting with all other agents. Like Russell said, you could think of this as a similar metaphor to the primordial soup. If you had pasted shaped like letters of the alphabet floating in "alphabet soup" with a stir any letter could be adjacent to any other letter.
I think that the reason many people use grid models is because the classes are there or that this is just what they have seen other people do. In many models I have looked at, the grid is not substantively motivated, which is a pretty big problem in my mind and lends credence to the concern that ABM's are just video games. So, again I would think about what your problem of interest is like and build your model accordingly. For my housing segregation model, there were both historic (docking with Schelling's models and other followups) and substantive (people don't really live on a torus) reasons for using a grid. But, again I think that the conceptual model should lead the programming not vice versa.
Soup models can be displayed graphically. For me, the idea of a GUI (graphic user interface) means that I am given some buttons and stuff to click when running the model. Even models where the output is just text can be controlled from a GUI.
I think your question is whether one can display soup models graphically. Take a look at my webpage (www.bol.ucla.edu/~dschreib) and follow the links on the party model. What I am using there is the "canvas" display. This is one way of visualizing the interactions of agents not located on a grid. In my party model, the X and Y dimensions represent two of the possible dimensions in the issue space. Each of the little circles is a "node" representing an agent. When the model is running, you can click on a node to probe the agent and find out what its current properties are. The color of the node tell you what kind of agent it is, the color of the ring around the agent tells you what main coalition the agent belongs to, and the thickness of the ring around the agent tells you how high up in the hierarchy the agent is (thicker means more senior). The lines going from node to node are called links and represent the connections among agents.
So this is one way of visualizing the interaction among agents. But again, I would suggest that you think about the substantive issues you are exploring and motivate the visualization from that. What is it that you want to know about the agents, their behavior, their choices, and their rewards? If this were my project, I would brainstorm all the questions that I might want to ask of this model and think about what the data needed to address those questions would look like. I would also suggest that you look into some of the books by Edward Tufte (http://www.edwardtufte.com) about the visual display of information. He is utterly amazing in his deep thinking about the issues involved in visualizing data. Following his insights will increase the likelihood that you can make sense of the model you are creating. It would be very cool if my models generated graphics like "The Sims", but it might not give me any insight into the model and in fact might make it harder for people to see what is really going on.
Releasing slave agents to get the best offers wouldn't be hard at all. There are no specific functions. But this would be very simple to do once you have gotten the gist of using Swarm. To amend my algorithm below, I would give my buyerAgents some threshold where they would decide that an offer is "good enough" and thus constrain how much effort it is willing to expend in going to its known traders, the traders of friends, or the random other traders. I would have the buyerAgent build a list of all the offers it receives from other agents and then just sort that from best to worst. Then, I'd have my buyerAgent accept the best off.
The bottom line is that Swarm can definitely do what you want to do. But, I think you'll need to think more about the problem before you go writing code. Also, I think that your deep thinking about the problem will make it easier for you to learn the programming skills you'll need to solve the particular problems you are interested in. In my view, programming is the easy part, good modeling is much harder.
My method for modeling is to brainstorm my most ambitious version of the model to answer all the questions I could desire. With all of these possibilities laid out before me, I then start to categorize them and prioritize them. Then I start looking for common issues that are at the core of the phenomena of interest. And, I imagine the very simplest version of the model that is a first step toward the ambitious one. Usually, my first models (version 0.00.01) simply creates a few agents and has them print their ID numbers. From there, I add feature after feature, debugging carefully along the way, making sure that I understand the behavior of the model at each step. This also means that I don't have to learn all of the programming issues involved at once, I can just learn enough to take the next very very small step. 

Best of luck.

        Darren


On Monday, May 26, 2003, at 11:16  PM, Kanagaraj Krishna wrote:


Hi,
Can i know in detail what is meant by a "soup" model. Any such examples available (java preferably)? 
It would be nice if I could get your codes too, for reference.
I've seen most examples of SWARM with GUI simulation (bugs etc..) where grids were used. Can a "soup" model be presented in a GUI simulation too?
Another one question .........would it be possible for an agent to release a few other slave agents (sub agents) to go and get the best offers from different traders and then compare&decide. Is this posibble in SWARM.......i mean any specific functions available. 

Thanks.

Kana
--

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

DATE: Mon, 26 May 2003 15:48:31
From: Darren Schreiber <address@hidden>
To: address@hidden
Cc: address@hidden


I'm following this up on the modelling list only, so reply there.  My
code is in the Objective-C version of Swarm, but let me know if you'd
like to look at it.

What I am reading from your description of the society you want to
model indicates that you really aren't looking for a "topological"
solution. Rather, I would guess that you are wanting what is sometimes called a "soup" model, where all agents are capable of interaction with 
any other agent.

What I would do is this:

Creation Phase:
        1.  As all traderAgents are created, you place them onto a
traderAllList.

        2.  All buyerAgents are put onto a buyerAllList

        3.   Each buyerAgent will be created with its own traderList of known
other traders (initially empty) and its own friendsList of other agents 
that it trusts (also empty.)

        4,  Each traderAgent is created with its own buyerList and its own
friendsList (both empty.)

Simulation Phase:

        1.  As each buyerAgent is called, it either randomly sorts its
traderList or it sorts the list by trust rating.  Then the buyer
iterates through the traderList to see if it can trade with each agent. 

        2.  If unsuccessful with its traderList, it sorts its friendsList
(either randomly or according to trust) and iterates through the
friendsList, asking each friendAgent to recommend a traderAgent.  If I
were designing it, I would make the askAFriend method recursive, so
that I can ask a friend to ask his friends to ask his friends (etc.).
You may initially only want to ask your close friends, but I could
imagine it would be worth parameterizing the friendsDepth option (0: my 
friends, 1: friends of my friends, 2: friends of my friends' friends,
etc) to explore the importance of the social network depth.

        3.  If unable to find a suitable trading partner from either my
traderList or the lists of my friends, then my buyerAgent would
randomly sample from the traderAllList.

So, since you not really using any physical construct of distance, I
would definitely avoid using a grid.  In fact, you will probably want
to visualize the model with just a series of graphs and maybe a
probeable display of agents (so you can study the performance of a
particular agent.)

        Darren


On Monday, May 26, 2003, at 11:16 AM, Kanagaraj Krishna wrote:


Hi,
Thanks for the input. Are you're simulation codes available for me to 
have a look at. I prefer refering to java examples of SWARM, so that
it would be easier for me to integate into my work.
Regarding how my model works. This models will simulate the management 
of trust among agents in a multi agent trading environment (more
applicable to internet.....e-commerce etc). I'll play around with the
parameters to study the behaviour of my new model.

I'll give a brief outline of how the agents in the society works.

-buyer agents gives priority to known trader agents first, when
sending slave agents to do trading. (experience based trust ratings)
-next if there hasn't been any experience with a trader agent
before........the buyer agents will ask its trusted friends for
support. (trust based on reputation/recommendation)
-and the last choice is to explore and take risk with the unknown
trader agent.
-the same vice versa for the trader agents in choosing a buyer.

Any comments.

Thanks again,
Kana
--

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

DATE: Mon, 26 May 2003 00:57:15
From: Darren Schreiber <address@hidden>
To: address@hidden, address@hidden
Cc:
(I am cross posting this to the modeling list, since my discussion is 
more on the theory than code related.  If your thoughts are on the
modeling side, you'd get more interesting replies by following it up
there.)

There are a lot of possible topologies that you can use, not just
grids.  If I were you, I would think more about the substantive
problem
and what kind of model topology you think would best describe the real 
world problems you are interested in studying.

Grids are nice because they are easy to visualize and it is pretty
easy
to manage proximity and distance.  Plus, there are pre-existing
examples you can work from.  But, you might also specify a hex (six
sided) grid since you don't have the "corner" problem of square grids. 

In some of my work, I have used both square grids and continuous
spaces.  My political party model envisions agents with positions on
diverse number of political issues. Each issue dimension runs from 0 
to 100, and since I use floating points to represent the position,
agents can be anywhere along that continuum (i.e. they are not
constrained to position 1, 5, or 10, but could be 1.20348 or
5.294842).

But, because of the nature of the political world I am interested in
modeling, I did not want to constrain my agents to a single issue
dimension.  So, I set the model up to handle an arbitrary number of
issues.  In later versions of this model (coming soon (like 6 months
or
so)), this model will be used to illustrate how we have one
ideological
dimension (left to right) emerge out of a space containing many issue 
dimensions.  Thus, the space that my agents traverse is a
multidimensional one.
Furthermore, because not all political issues are equally important, I 
have altered the geometry of the space so that distance is not the
typical Euclidean measure, but is instead a weighted Euclidean
distance
where some dimensions are viewed as more important than others.
Similarly, since a bundle of political issues might be related to each other (not independent) I allow the separability of the dimensions to 
be changed.  Both of these tricks are accomplished by sticking a
little
matrix of weights into the standard Euclidean distance measure. And, 
since not everyone agrees about the salience or separability of
issues,
I allow every agent in my model to have its own perceptions of the
topology of the political universe.  I may thus view our political
positions as very similar, but you might view them as very different. 
This creates a relativistic geometry quite different than the
Cartesian
grids that we learn in high school.

Rather than starting with coding constraints, I started with the
substantive problem, worked towards a plausible model, sketched some
concepts, and then got into the coding. Because my design is heavily 
parameterized, I can represent a simple two dimensional space with
integer values like a grid or a high dimensional relativistic geometry 
using the same code.
To manage communication and agent interaction, I put all of the agents onto a list as they were created. All agents have the ability to send 
and get messages.  To find nearby agents, they look through the list
of
all agents and calculate the distance to each agent.  My agents also
have the ability to form hierarchical networks, so they have a list of 
agents below them and above them in the hierarchy.
Now, the method of searching a list of all agents is not optimized in 
terms of coding, but I am willing to sacrifice that for the
flexibility
that my model has in representing my substantive beliefs.
Furthermore,
it isn't hard to think of some ways of creating subdivided the agent
lists to make it faster to find adjacent agents.

So, what I would do is think about the substantive problem you are
representing.  When your buyer sends out his representatives, is he
asking them to walk down the street to talk to other traders?  Are
they
getting in planes and flying to another city or country? Or, are they 
staying behind the desk and working the phone lines cold calling
perspective traders?  Or, perhaps the representatives exist in a
social
network of other agents who know other agents?

In my view, the programming issues here are much simpler than than
modeling issues.  And, you are more likely to useful help on the
programming once you know what you want.  As far as Swarm is
concerned,
it is incredibly flexible (good enough to handle my relativistic
hyper-dimensional hierarchically networked topology).

        Darren


On Sunday, May 25, 2003, at 10:57  PM, Kanagaraj Krishna wrote:


Hi,

-Are there any SWARM examples that involves interaction between
agents
(commuication) that can help me in designing my model (java ones).
Example: one buyer agent release few slave agents to interact with
few
trader agents to do business and then come back to report.

-Most of the examples used the grid/lattice way of designing
models......are this the only way?

-Are there any specific functions for an agent to look for another
specific agent in a world? how can this be done?

I was looking into the CharlesJavaTutorial examples on bugs looking
for food. It is more straight forward and there is no interaction
between agents.Thanks.

Regards,
Kana


____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos
Mail!
http://login.mail.lycos.com/r/referral?aid=27005
_______________________________________________
Support mailing list
address@hidden
http://www.swarm.org/mailman/listinfo/support



_______________________________________________
Support mailing list
address@hidden
http://www.swarm.org/mailman/listinfo/support





____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail! 
http://login.mail.lycos.com/r/referral?aid=27005
_______________________________________________
Modelling mailing list
address@hidden
http://www.swarm.org/mailman/listinfo/modelling








____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005
_______________________________________________
Modelling mailing list
address@hidden
http://www.swarm.org/mailman/listinfo/modelling
reply via email to
[Prev in Thread] Current Thread [Next in Thread]