1

I have some netlogo code that I would like to make more descriptive. So instead of:

MOVE-TO ONE-OF PATCHES WITH [ PCOLOR = BLUE ]

It would say:

MOVE-TO ONE-OF PATCHES WITH [ WATER ]

In java I would create an enum to accomplish this. How can I do it in Netlogo?

Gabriel Fair
  • 4,081
  • 5
  • 33
  • 54
  • 1
    Hey Gabriel, great question, but you might want to take a look at https://stackoverflow.com/editing-help to see how to format code as code instead of as a citation. You might also consider avoiding code in ALL CAPS... :-) – Nicolas Payette Jun 01 '18 at 15:09

3 Answers3

3

Alan's answer is fine, but I would also consider the possibility of creating a patch variable instead of relying on the patch color. For example:

patches-own [ water? ]

If you set this to true for each water patch, you can then say things like:

move-to one-of patches with [ water? ]

The main reason for doing this is that you might want to change the color of the water patches at some point: make them a slightly darker or lighter blue, for example, or use color to temporarily highlight patches with some other characteristic.

Separating presentation and program semantics is generally good practice.

Another, different way to achieve this would be to create an agentset with your water patches during setup. For example, supposing you declare water-patches as a global variable, you would do:

set water-patches patches with [ pcolor = blue ]

And then you can do:

move-to one-of water-patches

The water-patches agentset is not affected if you change the color of a patch. It might also be a bit faster since you only construct it once instead of filtering over all patches over and over again.

Nicolas Payette
  • 14,847
  • 1
  • 27
  • 37
2
to-report water ;patch proc
  report pcolor = blue
end
Alan
  • 9,410
  • 15
  • 20
  • perfect. Thanks. I'll accept your answer when SO lets me in 10mins – Gabriel Fair Jun 01 '18 at 14:09
  • Just to be clear, I agree with the points made by Nicolas and Jen about separating display and program logic. I was trying to stick narrowly to the question asked and to provide an answer applicable to any attribute. – Alan Jun 01 '18 at 21:11
2

Alan's answer is perfectly fine, but this question suggests to me a different conceptualisation. What you really mean is that the patch is coloured blue because it is water, but you are coding it the other way around so that colour is indicating its status as water. If other aspects of your model (eg travel speed, type of crops) depend on whether it is water or not, then you could consider a different construction.

patches-own
[ water?
]

to setup
  ask patches
  [ set water? FALSE
    if random-float 1 < 0.2
    [ set water? TRUE
      set pcolor blue
    ]
  ]
end

In this construction, you have a true/false variable for each patch that indicates it is water (if true). Then you can directly have statements such as ask patches with [water?] []. You can also set up a global variable that holds the patch-set of water patches and then make statements like ask water-patches []

If you have multiple types of land style (eg water, sand, soil, rock...) then you colour is more likely to be the way to go since you don't want separate variables for all of these. Even then, though, you could have one attribute for land style and have constructions that are ask patches with [ type = "water"]

JenB
  • 17,620
  • 2
  • 17
  • 45
  • 1
    Woah... great minds think alike, I guess. We pretty much gave the exact same answer at a few seconds interval! – Nicolas Payette Jun 01 '18 at 15:07
  • 1
    or fools seldom differ, but your version is better for my ego :) I just saw yours, we give different reasons and examples so might as well keep both – JenB Jun 01 '18 at 15:09