gee-guys Mailing List for Group Experiments Environment

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hey Michael, I'm in the middle of porting the bots over, just wanted to 
respond to your readme packaged with the bots for Andy's benefit as 
well.

>
> Hey guys,
>
>   1.  I've changed some variable names and such, so hopefully 
> everything is coherent, but there's definitely the possibility that I 
> mangled a variable or bit of logic in the transition, so contact me if 
> anything seems off or if you just want me to clarify something.  
> Whenever you've incorporated the agents, maybe we could run some 
> experiments with all agents and certain parameters, just to make sure 
> it's similar to what I was getting before.

Will do, the bot integration should be done sometime this evening if 
all goes well.

>
>   2.  An issue I hadn't thought about: I'm not sure how you guys are 
> handling movement, with continuous values or from discrete cell to 
> discrete cell.  I think Ben did the former, but I did the latter.  If 
> you're doing it continuously, it should still be really easy to 
> integrate my code, but the movement rate will be different than what I 
> used in my simulations, so we may have to calibrate it a bit to work 
> out well with humans.  A related issue is that in the future, we may 
> want some people (both humans and agents, I guess) to move faster than 
> others to see how that changes individual strategies.  From a 
> continuous standpoint, that means the faster people could just take 
> bigger steps, but from a discrete standpoint, it might mean that they 
> should have a faster tick update cycle.  Maybe a similar issue would 
> arise in the social choice experiments if you wanted some people to 
> get multiple guesses in the same amount of time as another person.

We're doing the discrete thing right now because it's much simpler to 
model and you're right, we can still simulate 'faster' people by 
modifying how often they send their updates.  So.. we should be good.  
Basically I'm grokkin the code and figuring out how I can do the least 
amount of work to get the bots to talk to the server's world instead of 
maintaining their own forager grid world of tasty food.

>
>   3.  I'm guessing that the agents' parameters will be part of the 
> input script, and if so, we'll know the params just by having recorded 
> what script was used in a particular experiment.  But if that's not 
> the case, I want to make sure we store those params for each 
> experiment so we can compare behavior based on the params.  Also, 
> we'll want to record the respective numbers of agents and humans in 
> each experiment, and I was thinking it would be best to make a clear 
> delineation between the humans and the agents in the output file.  For 
> instance, maybe the top of the output file will say that there's 9 
> humans and 11 agents, then at each time step, the file would first 
> have the locations and food acquired for each of the 9 humans, then 
> for each of the 11 agents, then the pellet locations (at least that 
> was the previous format).  For a lot of analyses, we'd probably just 
> want to look at the human data, but for some things I think it would 
> be cool to compare the human performance vs. the agents, given that we 
> know what's driving the agents.

Definitely.  How should agent parameters be configured anyhow?  Right 
now we are using a hierarchical type of configuration with a master 
configuration file specifying global parameters for the entire 
experiment server and tiny slave configuration files specifying details 
for individual rounds or sessions (multiple rounds) of experiments... 
it'd be cool to turn them into XML eventually because then we can avoid 
some ugliness in the files (specifying multiple or optional things is a 
little easier with XML, you don't have to do stuff like

num-food-regions 2
food-region1 37 23
food-region2 23 47

Instead you can do stuff like:
<food-regions>
	<location x-coord=37 y-coord=23 weight=14 />
	<location x-coord=23 y-coord=47 weight=8 />
</food-regions>

Arguably it is a bit easier to see what the config file means when its 
in XML...

I'm tending towards having the bots be wired up via a separate set of 
configuration files still under the master configuration's control.

>
>   4.  I've included two folders: forager_invis and forager_vis.  
> Forager_invis is responsible for the invisible food/invisible agents 
> condition, but it also handles the invisible food/visible agents 
> condition by doing everything the same (in terms of storing cell 
> values and increasing or decreasing the values based on their reward 
> history), but it sets the agent density parameter > 0, so that an 
> agent is weighing the desirability of a cell by also taking into 
> account how many agents are temporarily near the cell (on one hand, 
> you may not want to move there because it's too crowded, but on the 
> other hand, if you haven't figured out where any food is, it might be 
> in your best interest to go where a crowd is, and we can switch 
> between those behaviors by making the parameter negative or positive). 
>  Likewise, forager_vis handles the visible food/visible agents case, 
> and it also handles the visible food/invisible agents case by setting 
> the agent density parameter to 0, so you're still choosing between 
> pieces of food based on how close you are, goal bias, and food density 
> (which I didn't mention yesterday, but it works like agent density, 
> except a piece of food is more desirable if other pieces of food are 
> nearby), but you don't have any information on other agents' 
> locations. With both models, I calculate a couple of things -- like 
> agent density -- outside of the agent class, because it's identical 
> for everyone, so it's quicker to do it once and then pass the result 
> to everyone.
>
> For forager_invis:
> 	Main, Agent_List, and Agent_Invis_Cluster are the important files.
> Main starts the program, sets the initial params (based on the the 
> blocks of sessions I want to try, but
> for your purposes, you'll probably be able to discard all of Main), 
> and runs particular sessions via the timers for food dropping and 
> agent updating.  What actually matters to you is in AgentList and 
> Agent_Invis_Cluster.  I think all the functions in them can be 
> combined more meaningfully to just be an Agent class, but I separated 
> them at some point for dumb historic reasons of how I was running the 
> simulator and iterating through agents.
> Whenever the timer in Main (experiment()) leads to an agent update 
> call, updateAgents is called in AgentList, and it has each agent 
> decide on their next movement (based on actionSelection in AgentList, 
> which should really be part of the Agent_Invis_Cluster class), then 
> they move (based on the move function that is in Agent_Invis_Cluster),
> then "update" is called in Agent_Invis_Cluster, which essentially 
> takes care of the appropriate rewards, penalties and regeneration.  
> There's a bit of a distinction in that each grid cell's long-term 
> value is based on its starting value, then the history of rewards, 
> penalties, and possibly regeneration.  But when an agent chhoses a 
> cell in actionSelection, a cell's value can also be affected by 
> whether or not it's currently the goal (which means it was chosen at 
> the previous time step, so you're already heading towards it and are 
> therefore likely -- but not definitely -- going to continue towards 
> it) and, if agents are visible, by the density of agents around the 
> cell.
>   I've left in the code for regeneration and inertia movement bias 
> (bias to keep going in the same direction), even though they don't 
> seem necessary for the data collected so far.  You can either include 
> them and we'll just set their parameters to 0 for now, or don't worry 
> about them and we can add them in the future if necessary.
>
> For forager_vis:
> 	I didn't include FoodRegion or FoodBin beause they're the same as in 
> forager_invis.  The only thing that might be worth noticing is that I 
> have some code in FoodRegion to deposit food with uniform variance (in 
> a square, actually, not a circle) of different sizes, because I ran 
> some experiments where I wanted to compare how agents do based on food 
> density, which is harder to compare with gaussian distributions.
> 	The set-up is similar.  This time actionSelection is inside the 
> Agent_Visible class, but I calculate a couple of things -- agent 
> density and food density -- in AgentList and send the result to 
> everyone since they can all see the same thing.  If the agents were 
> invisible, then the agent density parameter would be set to 0.  One 
> minor detail is that the agents may not have anything to choose from 
> if no food is on the screen, so in that case they just keep moving 
> towards their previous goal, or stay at their goal if they've already 
> reached it.  Regardless, it's extremely rare that all of the food has 
> been eaten, and new food appears very quickly.
>

Thanks for the docs, Michael, I'll let you know if I have any questions 
in the meantime!

Allen

gee-guys Mailing List for Group Experiments Environment

gee-guys — GABEL developers' and users' discussion and support list