Defining constants in NetLogo - netlogo

Question

What are the available options (if any) for defining constants in NetLogo? I am looking at having the constants defined in the code, not in the interface. The value(s) are not intended to be received from the user as an input via the interface.
The goals are as follows:
Define the constant in one place in the code and use it wherever required. This would enable one to tweak the value in one place.
Prevent accidental modification of the constant value elsewhere in the code.
I am looking at creating something similar to the mathematical constants e or pi which are baked into NetLogo but at a single model level.
Is it possible to create such a constant?
Are there more than one ways to define such a constant? If yes, what are the available options and the associated pros and cons?

Answer 1

Two ways come to my mind:
(1) Use global variables that are specified upon setup
For example:
globals [
a-cool-number
a-number-that-I-don't-like
]
to setup
clear-all
set a-cool-number 7
set a-number-that-I-don't-like 44
create-turtles 1
end
to go
ask turtles [
show word "The best number is " a-cool-number
show word "The same is not true for " a-number-that-I-don't-like
]
end
Pros: It works.
Cons: The more global variables you declare, the less easy it becomes to approach your model by reading code (although using comments to single those variables out by saying that they are just constants would help). Also, in theory those variables could be accidentally modified by agents or by you (although I think this is a remote risk, if it is true that these variables are only specified upon setup and never again).
(2) Use reporter procedures
For example:
to setup
clear-all
create-turtles 1
end
to go
ask turtles [
show word "The best number is " a-cool-number
show word "The same is not true for " a-number-that-I-don't-like
]
end
to-report a-cool-number
report 7
end
to-report a-number-that-I-don't-like
report 44
end
Pros: It works. Also, there is no way the value of your constants could be inadvertently modified by agents and not even by you yourself (unless you directly go and change the code in the reporter procedure, of course).
Cons: None that I can think of now.
All in all, given the way you asked your question, I think that reporter procedures are the best option for you.

Answer 2

Matteo's answer is good, I'd use reporters, too. But I wanted to add one more method that's a little "sneaky". You can create widgets, inputs, sliders, or choosers, and then place a label widget with background transparency disabled over the top to "hide" them. Widgets are presented in the order they were added to the model, so the label widget gets drawn in last over the top of the other global variable widgets.
This lets you have a global variable that you can use in code that has no apparent backing widget. Any value you give it will be saved with the model and so will be "constant".
The only time I would use this technique would be if I really didn't want anyone looking at the model code to see where the constant value was coming from for some reason. I can't even think of too many uses for that, but hey, I just wanted to make the possibility known.
A big downside of this method is that you can change the value through the command center or other code and not notice it, as the value is hidden from sight.
Here is a picture that hopefully makes it clear. I've not completely hidden the input widgets and I've left text in the label just to make the picture not be a big blank area.