SSup: Re: Parameter Managers and all that...

[Ginger Booth]

Loved Sven's "2 cents". :)

One thing I'd really like to underscore in this discussion:  Notice how once
the basic problem is solved ("hey, I gotta set these parameters to something,
and for each run result, I gotta know what the settings were"), a whole new 
world of fiddly bits opens up: 

    "Hey, parameters have ranges of values!
     Their values are RELATED to each other!  
     At the control level, times and events to schedule are parameters, too!
     With ranges!  
     I wanta do -everything- from my protocol!  
     Specify it all, cyclic and asynchronous events, colors, comments!
     Even re-run what the interactive user did!  Log that, too!
     This is really nifty for running demos!  I wanna slide show!
     I need a thousand runs with an algorithmic driver on 12 machines!
     Hey, waitaminute, which program is which, and where?
     Gosh, there's META-levels all over the place here!"

Several observations:

    1. The way this opens up lots of issues, related to -why- someone is
       doing a Swarm application, what it's for, is why I consider the
       "parameter manager" fundamental.  
       
    2. This is not about typing a "2" in a popup menu.  For a real app,
       no one in their right mind would enter 15-50 intricately
       interdependent values by hand.  "2" is a pop quiz.  15-50 real
       interdependent values is information that was -hard- to get.
       
    3. Though one would ideally like to avoid opening Pandora's Box, it
       may be a necessary stage on the road to the simple & elegant.
       
    4. Opening Pandora's Box does not put one at a moral obligation to
       close it--you CAN do part, not all.  This is definitely a case
       where a partial solution helps enormously, and there are diminishing
       returns as you turn on more and more fiddly bits.  (E.g., you won't
       find a Swarm application which has no parameters.  You will find
       Swarm apps where keystroke logging is simply turned off, if it's
       ever enabled in the first place.)
       
    5. Therefore I'd like to suggest to the developers that they consider
       all the wish list fiddlies when thinking how to design the PM, but
       keep very much in mind that the above/below-the-line line can be
       drawn where it's best for the software and fits in with funding and
       time constraints.  I.e., do what you can do cheap, and try not to
       close any doors, so that you can do what's expensive when you've got 
       the timemoney.

Some clarifications on Sven's:

> I have one question for Ginger: are all your Grandma objects created at
> 'the same level', so to speak? How would you deal with a situation where
> there's a hierarchy? (E.g. A-agents create B-agents, who create C-agents
> and so on.)

I only use the term "grandma" for the on-the-fly agents, and each is a
"species" (at the moment), so at the moment, yes sort of.  However, note that
my controller "knows" to expect a world model, which "knows" to expect sites
and species and composites.  That's a nesting.  Not elegantly done, now.

> a) (this may actually be in Ginger's implementation) there needs to be a
> way to specify that we want 100 Boids created, and for those Boids certain
> parameters are distributed Uniformly[a,b] or Normally(c,d) over the 
> population;

My mandatory Species parameters include when the species is born into the
world and how many.  Taking that out of the Species into the asynchronous 
events world would be better, but not mandatory.  If left to extend my own 
model rather than using a Swarm generic, I'd probably put the range capacity 
in the agents (proto-member grandma, not book-keeper Species), as I consider 
phenotypic variation a "behavior" of an organism.

> b) I take Ginger's discussion of 'observePop' to mean this is the name of
> a message being sent rather than a data value being set. 

FWIW(NM), all my dumb protocol reader does is check whether it's a parameter.
If so, set it.  If not, try to execute it.  If still confused, complain and
die. ;)

> The generalization is this: the Parameter Manager concept is kind of
> static, in that it envisions everything being applied at t=0. Now just
> add the ability to specify the time parameter!

One caveat:  I do need to "apply" everything at t=0.  If I am "applying" a
specification for what happens at t=200, that means at t=0 I enqueue an
asynchronous event to execute at t=200.  Not running from a protocol along
the way.  (Yes, it matters.)

Ciao,
    Ginger
    

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================