I'm sympathetic to Alan's approach, but fwiw, there's an ugly way to create lots of similar interface widgets, which I have used (not for the sake of BehaviorSpace, but simply because I wanted to play with different combinations of parameters). It relies on the fact that a NetLogo model is a text file, and on having a relative powerful text editor that you know how to exploit.
In NetLogo, create the first two interface widgets, spaced as you want them, with room below/above/next to them for the rest of the widgets you're planning to create. Open the model in your text editor/IDE/whatever. Search for the widget specifications down below the main source code by searching for the variable defined in one of the widgets. Looking at the numbers there, you'll be able to guess which are location coordinates. For example, here are two switches: SWITCH 1393 16 1513 49 cropplan-a cropplan-a 0 1 -1000 SWITCH 1393 49 1513 82 cropplan-b cropplan-b 0 1 -1000 I'm not sure what all of those numbers mean, but I can guess that 1393 and 1513 are left and right x coordinates, and that 16 and 49 in the first one are top and bottom y coordinates. That this is in fact the case is something I determined by trial and error, but I believe there's documentation somewhere about the meaning of the widget specifications. Then I can use shortcuts and macros in my editor to copy a widget, increment the coordinates, maybe change the variable name, etc. Or you could do something like writing a perl or python script to add widgets to the NetLogo model. See? Not pretty, but it works. (Back up first, obviously!) On Friday, October 31, 2014 6:06:14 PM UTC-5, Forrest wrote: > > I feel your frustration. > > I wonder, though... are you sure it isn't feasible to create interface > elements (sliders, choosers, etc) for each parameter? Any variable that is > important enough to be varying in BehaviorSpace... perhaps it would be nice > to expose that to the model's interface? If it feels cluttered, you could > simply place a big column/row of widgets "off the screen" so that you don't > see them unless you scroll over to them? (I remember there was talk of > NetLogo supporting multiple interface tabs, but as far as I know, it > remains a "wishlist" item...) > > Cheers, > > ~Forrest > > > > On Fri, Oct 31, 2014 at 4:53 PM, Alan Isaac <[email protected] > <javascript:>> wrote: > >> Thanks for spending some effort thinking about this. The most common >> problem where this flaw becomes annoying is the following. A model has >> many global variables; too many to conveniently create interface globals >> for all of them, and similarly too many too set all of them explicitly for >> every experiment. Yet there is a need to run BehaviorSpace experiments >> with some of these global values. If you set these as parameter values in >> BS, then they will be reset to 0 if you call clear-all. One thing you can >> do currently is not call `clear-all` and have your `setup-globals` >> procedure set variables to default values only if they have their >> initialized value of zero. But then, what if your *experiment* sets the >> value to 0? You are stuck with very ugly work-arounds. >> >> What I'd really like to do is to actually set global variables sensibly >> using BehaviorSpace, just like interface parameters, but without creating >> widgets for them. There are two interlinked problems here: the asymmetry >> in the treatment of the two types of globals (interface and non-interface), >> and the lack of default values for global variables of both types >> (interface and non-interface). Your proposal (allowing an initialization in >> the `globals` command) deals with the latter, but it leaves in place the >> former. So it is not a full answer. I suggest that every global have a >> default value (which can be set as you propose), and that will be the value >> set by `clear-globals`, but that additionally every variable set in >> behavior space be flagged so that its BehaviorSpace value will persist past >> a `clear-globals` command. (Just brainstorming.) That is, the core problem >> goes away if `clear-globals` does not override values set by BehaviorSpace. >> >> This addresses another issue in BehaviorSpace. Most importantly, since >> interface parameters lack default values, every interface parameter must be >> explicitly set in every experiment, or experiment safety is radically >> compromised. With the changes above, one only needs to specify in >> BehaviorSpace the parameters that must take on values other than their >> default values. >> >> Separately and less important, if you set an interface parameter in >> behavior space and it is changes at runtime, the BehaviorSpace output makes >> it look like it remained constant. (This just means that for clarity the >> output need to use different names for the initial parameter values, for >> example `bs:myparam` instead of `myparam`.) If you start fixing >> BehaviorSpace, it would be nice to fix this too. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "netlogo-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "netlogo-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
