CODEWITHSUNDEEP
netlogo
Nimesh Neema
Nimesh Neema

Reputation: 2015

Defining constants in NetLogo

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:

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

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

  1. Is it possible to create such a constant?

  2. Are there more than one ways to define such a constant? If yes, what are the available options and the associated pros and cons?

Upvotes: 1

Views: 321

Answers (2)

Jasper
Jasper

Reputation: 2780

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.

input widgets covered with a label widget

Upvotes: 0

Matteo
Matteo

Reputation: 2926

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.

Upvotes: 3

Related Questions