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]> 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]. > 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.
