Re: [Gabel-guys] experiment waiting room

[Allen L. <al...@cs...>]

Does the identity of the mini experiment matter so long as all of its
configuration parameters are written out?  I was under the impression that
there wouldn't be as many canned mini experiments because of the always-on
nature of the new experiments..

On Thu, Jul 08, 2004 at 08:36:41PM -0700, Robert Goldstone wrote:
> It might not hurt to have the sampling rate be configurable.  I could see
> different kinds of experiments wanting different resolutions.  It's no big
> deal though.  If you want a single rate, I'd recommend sampling once every 2
> seconds -- that's what we did before.  More often than that and we tend to
> get files that are too big.
> 
> Each line of data should have the {X,Y} location of each subject, their
> total amount of food, and also the number of food pieces on the screen and
> their {X,Y} locations.  I don't think you need to write out client numbers
> if we assume that the data is printed out in order -- the first set of
> coordinates and #food eaten belongs to Agent #1 for example.
> 
> Also, at the beginning of each experiment, you should write out in the same
> output file the number of pools, their coordinates, their replenishment
> rates if this isn't clear from the configuration file, the number of agents,
> and a number that reflects WHICH mini-experiment is being run (because each
> experiment consists of several mini-experiments with different parameters
> potentially).
> 
> 
> > Hey Rob, another quick question - how often do we need to sample the data
> > collection, and what data needs to be collected (currently client number,
> > location, total amount of food consumed).  Does this need to be configurable
> > as well?  
> > 
> > Allen
> > 
> > On Thu, Jul 01, 2004 at 11:07:56AM -0500, Rob Goldstone wrote:
> >> Hi Allen,
> >> An experiment can't really be a set of rounds, because people will be coming
> >> in and out.  If we could imprison subjects for an hour or so, then we could
> >> be sure of having the same subjects, but we can't do this.  So, the short
> >> answer to your question is that a "per round" makes sense.  Each 5-10 minute
> >> experiment is logically independent of the others, even though there may be
> >> an orderly arrangement to which configurations of an experiment are
> >> presented when.  In terms of statistical analyses, this means that we'll be
> >> using "between-subjects" rather than "within-subject" designs.
> >> 
> >> The rest of what you describe makes good sense.  For Forager and social
> >> choice I'm not envisioning any upper limit to the number of people involved.
> >> So, I don't expect we'll be spawning new experiments if one is filled up.
> >> This is fine functionality to include though, because I could imagine it
> >> coming up down the road.
> >> Ciao,
> >> Rob
> >> 
> >>> Andy and I have come up with an issue that I thought would be good to have
> >>> some feedback on.  We've been discussing how we want to implement the
> >>> 'waiting
> >>> room' functionality.  Right now we're leaning towards the following
> >>> interaction model:
> >>> 
> >>> 1. User hits the web page listing available games.  Web page checks KNS to
> >>> see
> >>> which services are available and dynamically generates hyperlinks encoded
> >>> with
> >>> the specific host and port information for that particular server.
> >>> 
> >>> 2. User clicks on a specific hyperlink, that takes them to the applet,
> >>> automatically connecting them to that experiment server.
> >>> 
> >>> 3. Here's where we need some clarification or at least a "yes keep doing
> >>> that".  We decided to 'throttle' connections at the experiment server end,
> >>> not
> >>> the KNS end.  This means that people will be making connections to the
> >>> experiment server regardless of whether or not an experiment is already in
> >>> progress, etc.  What we plan to do here is the following:
> >>>   a. If there is no experiment session is in progress, or all current
> >>>   experiment sessions are already full, a new experiment session is started.
> >>>   We're going to have to worry about dealing with a maximum allowable limit
> >>>   to this, of course, but we're leaving that for later since it's not
> >>>   immediately needed.
> >>> 
> >>>   b. If there is an experiment session in progress and it is not full, the
> >>>   user gets queued up for that particular experiment session and begins
> >>>   playing in that experiment session in the next round.  I was wary of this
> >>>   idea when Andy first mentioned it because I had some artificial notion
> >>>   that an experiment was a logical set of rounds, and the participants for a
> >>>   given experiment should remain static throughout this set to keep it
> >>>   cohesive.  Since experiments will be randomized anyhow, we're leaning
> >>>   towards the per-round implementation, so a user connects to the forager
> >>>   server and gets slapped into the next round of forager.
> >>> 
> >>> DING: Here's where we need confirmation/clarification.  Do participants join
> >>> on a per-round basis or on a per experiment session basis?  Will this change
> >>> for other experiments? Also, how long do we keep running these rounds?  Do
> >>> we
> >>> let someone play forager for 37 hours?  Do you need to interpret their data
> >>> differently?
> >>> 
> >>> This is a pretty trivial question, but it's kind of a stumbling block right
> >>> now.
> >>> 
> >>> Thoughts?
> >>> 
> >>> 
> >>> 
> >>> -------------------------------------------------------
> >>> This SF.Net email sponsored by Black Hat Briefings & Training.
> >>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> >>> digital self defense, top technical experts, no vendor pitches,
> >>> unmatched networking opportunities. Visit www.blackhat.com
> >>> _______________________________________________
> >>> gabel-guys mailing list
> >>> gab...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/gabel-guys
> >>> 
> >>> 
> >>> 
> > 
> > 
> > 
> 
> ___________________________________________________
> Dr. Robert Goldstone
> Professor of Psychology, Program in Cognitive Science
> Psychology Building
> 1101 E 10th St.
> Indiana University
> Bloomington, IN. 47405-7007.
> 812-855-4853 (work).  812-333-0152 (home).  812-855-4691 (fax)
> Email: rgo...@in...
> Percepts and Concepts Laboratory: http://cognitrn.psych.indiana.edu/