I'm trying to make my model compatible with an interface framework that can't handle the csvs I normally export to, and requires lists. What I need to do, specifically, is export a list of lists of variables associated with each of a certain breed of agent.
Ideally:
set master-list (foreach person set traits-list list (who) (color) (heading) (xcor) (ycor) (etc...))
But the primary issue I'm having is that after the first two variables set up in the set traits-list list (items) way, it starts throwing up errors on any subsequent variables. I can just lput each individual variable, but that seems like a really unnecessarily messy way to set it up. Am I missing something?
I've tried seeing if it's the individual variable that's the issue, but the error persists no matter what the third variable is.
If anyone wants to look at the complete code in question, I'm trying to make https://github.com/efyoungud/stationfire work with https://github.com/hlynka-a/SRTI.
JenB had the answer with needing the bracket.
Final, functional code:
ask people [ foreach [self] of people [
set traits-list (list (who) (color) (heading)(xcor)(ycor)(shape)(breed)(hidden?)(size) (alarmed?) (age)(visited?)(group-number) (group-type) (group-constant)(speed) (leadership-quality) (leader) (goal) (energy)(speed-limit)
)]] ; doesn't include next-desired-patch or path because that's calculated each step and doesn't need to be exported
set master-list [traits-list] of people
end ```
Related
I am working on a model in NetLogo and I would like to separate procedures in different files, grouped by their purpose. I am doing so by writing that code in different files and using __include["name_of_file_1.nls" "name_of_file_2.nls" ...].
As I would like it to be tidy as possible, I use turtles-own[ ] in each included file, declaring the variables that will be used in the procedures from that file. So, in case I'd like to modify the name of that variable or anything else, I would only need to go to that specific included file and modifying the variable in there. Instead of modifying it in the code tab and then switching to one of the included files.
But, if I work like this, turtles won't own the variables declared in a file. For example, I have all setup procedures defined in a file. When the setup button is clicked from the interface, setup recalls all procedures contained in the included file setup_procedures.nls. However, if after setting up, I inspect some of the turtles, they don't own the variables declared with turtles-own[ ] in the setup_procedures.nls file.
Should I declare all variables in the code tab? Is there a way to make it work as I intended?
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?
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.
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.
I'm trying to modify a variable belonging to a specific patch in NetLogo.
set [informed] of target [informed] of target - floor(diff / 2)
I get the error: This isn't something you can use "set" on.
'target' is a specific patch I've defined earlier.
I've used syntax like this ([variable-name] of specific-patch) at the end of expressions to define other variables, but it doesn't work when that's the variable you're trying to define. Removing brackets just results in a different error. I'm not sure whether I'm missing some major fundamental understanding or some silly syntactic mistake. Any help would be appreciated, thanks.
this might sound like a dumb question but, does anyone know how can I get a list of the variables (including auxiliary and dummies) from my Netlogo code?
I think the Reflexion extension might be what you're looking for.
As per the documentation:
reflection:globals reports a list with the names of all global variables breeds
and:
reflection:breeds reports a list of all breed names, and all their variables, default variables included.
I am currently setting a multi-level model, and am hoping to use the NetLogo LevelSpace extension. I want the parent model to request the value of a global variable from a child model, but am having a little difficulty with the syntax. I can find examples of requests for information from agents e.g.
let turtle-id 0
(ls:report model-id [ [ color ] of turtle ? ] turtle-id)
but this doesn't seem to work for global variables e.g., I would like to do something like:
ls:report model-id [child-global-variable]
Is this possible, or am I completely missing the way that LevelSpace works?
ls:report model-id [child-global-variable]
will actually work just fine, though I slightly prefer using ls:of, just because it matches of:
[child-global-variable] ls:of model-id
That said, all the code that we're discussing right now requires the upcoming version of LevelSpace (which will run on the upcoming version of NetLogo, 6.0).
You can download the version that runs with NetLogo 5.3.1 here: https://github.com/NetLogo/LevelSpace/releases/tag/0.1
That version requires that code be passed between models in strings. So you have to do:
"child-global-variable" ls:of model-id
You can find the documentation for that version here: https://github.com/NetLogo/LevelSpace/blob/c3f78f45217e34cd31b18a246e4749e74209f29f/README.md
Sorry for the confusion!
I have found a solution: create a function in the child model that reports the variable:
to-report report-variable
report variable
end
Then, I can call this function from the parent-model:
show "report-variable" ls:of ls:models
Not sure if this is the most efficient way to do it, but it seems to work.