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 netlogo-devel+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
