|
From: Skye Bender-d. <sky...@st...> - 2002-12-12 20:12:34
|
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 -------------------------------- |