Here are a couple workarounds:
1) This is a little verbose, but you could include a flag for each global,
like so
globals [
first-param
first-param-set?
second-param
second-param-set?
]
then in `setup-globals`, you'd do:
to setup-globals
if first-param-set? != 0 [ set first-param 13 ]
if second-param-set? != 0 [ set second-param 72 ]
end
In BS, you can then specify which globals you want to override by setting
those flags, eg:
set first-param 0
set first-param-set? true
or
["first-param" [0 1 10]]
["first-param-set?" true]
2) Less verbose, but perhaps a little dirtier, and less flexible. Have a
global called `initialized-globals` or something. Then make the following
procedure:
to initialize-global [ global-name value ]
if not is-list? initialized-globals [ set initialized-globals [] ]
if not member? global-name initialized-globals [
run (word "set " global-name " " value)
set initialized-globals lput global-name initialized-globals
]
end
Then, in `setup-globals` and BS, do
initialize-global "some-param" 5
to initialize each global. `initialize-global` will only set each global
once.
This has a couple limitations. First, `initialize-global` has to be tweaked
if you need to set globals to values who's string representation doesn't
evaluate to the value itself (I think this only arises with extensions).
Second, it's a little awkward when doing parameter varying in BS. I suppose
you could do it as follows:
["first-param" [0 1 10]]
["second-param" [-5 1 5]]
and then in the BS setup, do:
set initialized-globals ["first-param" "second-param"]
or via
initialize-global "first-param" first-param
...
Hope this helps as a workaround!
Bryan
PS-
I'll cross-post this to the related github issue:
https://github.com/NetLogo/NetLogo/issues/179
On Fri, Oct 17, 2014 at 4:19 PM, Alan Isaac <[email protected]> wrote:
> There is no good workaround. The developers have not suggested a
> workaround. This is a widely recognized problem. I personally do not see
> how it will be adequately addressed unless initialization of non-interface
> globals is changed. I would love to hear how the developers are thinking
> about this problem, which poses very real problems for serious NetLogo
> users.
>
> My recommendation would be to plan a transition. Immediately, introduce a
> new keyword for the declarations section, allowing specification of the
> default value for non-interface globals. (E.g., `__global-default`.)
> Ideally, this would immediately be supported by the introduction of a new
> value (e.g., `undefined`). Users who want this functionality now would be
> able to include the declaration
>
> __global-default undefined
>
> In a future version, this would become the default behavior.
>
> I plead that the developers take this design flaw seriously and that it
> not be passed on to Tortoise!
>
> Alan
>
> --
> 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.
