Re: [Repast-developer] Controller hierarchy

[Skye Bender-d. <sky...@st...>]

Hi nick, and folks,
   Was just remembering a conversation we had a long time ago about 
the idea of a ParameterSpaceExplorer, which seems relevant to the 
controller discussion.

Crudely, the idea is pretty much the same as doing runs from a batch 
file, but the batch file has a GUI and data presentation of its 
results.  So after someone has finished coding a model, and wants to 
explore "results" over a particular range of parameters, they could 
load the ParameterSpaceExplorer, enter the range, parameter sampling 
density, and number of repetitions per point, and come back in a 
couple of hours to a nicely collected data set.  Of course this 
requires that models have well defined stopping conditions (or a set 
number of steps), and report clear numeric results of some kinds.

In the (rare) case where there are two main input parameters of 
interest, and one result parameter, we could have nice 2.5D plots of 
results, or if multiple result params, allow switching between result 
plots...    Could also calc "pseduo"-error ranges and stdv.   Then 
the user can say, "hmm, what's this discontinuity on the graph, is it 
just randomness?  lets do another 300 runs, more closely spaced along 
parameter-x, and see what we get..click click.."

Another advantage is that it might help people (us model coders) 
focus their (our) thinking on "OK, what are my inputs, and what are 
my results, and what does it mean" instead of just, "WOW! isn't that 
pretty!"  I don't by any means mean to dis good graphical 
representations of a sim, as I think they are incredibly important, 
but I think it is also good to help formulate a "question" and 
"results" approach as well.

I know it is better to do things than suggest them, but I've got all 
the java I can handle at the moment with this network stuff.  But I 
thought I'd throw the idea out there again, just in case coordination 
between DataSource, DataRecorder, and the Controller interface might 
be useful or necessary in the future...

cheers,
   -skye

>
>I refactored the controller (small c) hierarchy over the last few days.
>The point here was to isolate the basic semantics of a controller in an
>Interface. This new Interface is IController and the basic semantics
>have to do with the execution of a model, starting, stopping etc.
>BaseController implements these semantics, and retains backward
>compatibility with all its weird little utility methods.
>BatchController and AbstractGUIController add different ways of dealing
>with parameters and Controller adds an actual GUI (buttons and so forth)
>on top of AbstractGUIController. I'd rather do this with wrapping, but
>it was easier to preserve backward compatibility w/r to Controller this
>way. Wrapping can be revisited later.
>
>just to keep y'all in the loop,
>
>Nick
>
>--
>Nick Collier
>Social Science Research Computing
>University of Chicago
>http://repast.sourceforge.net
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:
>With Great Power, Comes Great Responsibility
>Learn to use your power at OSDN's High Performance Computing Channel
>http://hpc.devchannel.org/
>_______________________________________________
>Repast-developer mailing list
>Rep...@li...
>https://lists.sourceforge.net/lists/listinfo/repast-developer


-- 
--------------------------------
Skye's fone/Vmail: 650.853.0679
--------------------------------