patches-own a vector in netlogo

Question

In the patches-own section at the start, can I index one of the variables over a breed, so it's a vector rather than a single variable?

Specifically, I've got a breed called Developers (it's an ABM of house-building), and patches own a land-price, but I want them to own a different land price for each developer. Is this possible?

My failed attempt, with 2 developers, is

patches-own [ land-price ( n-values 2 developer ) ]

Thanks.

mattsap · Accepted Answer · 2017-04-27T14:00:10.063

3

This can be solved a numerous ways.

One solution can be to let the patch-variable be a list. You can't initialize it inside the patches-own block. Instead, initialize it in your setup method.

patches-own [land-prices]

to setup
    ca
    create-developers 10
    let initial-price 10
    ask patches [ set land-prices (count developers) initial-price]
end

You'll need to be careful about ordering though. For example, alot of the commands like of produces a list of random size. You may want to use the developer's who to index them.

One way to get around that is to use the table extension to create a table of who to price. You'd need to include table in your extensions and modify your setup. See: https://ccl.northwestern.edu/netlogo/docs/table.html

Consider this for the table solution, where I make use of the from-list function in tables to initialize the table:

patches-own [land-prices]
breed [developers developer]
extensions [table]
to setup
  ca
  create-developers 10
  let initial-price 10
  ask patches [ set land-prices table:from-list [(list who initial-price)] of developers]
end

Both of these are memory intensive operations. You may want to tread lightly or explain why it's necessary to store so much information.

edited Apr 27 '17 at 14:00

answered Apr 27 '17 at 13:26

mattsap

3,790
1
15
36

1

I would strongly advise against using a raw list, for the reasons of ordering that you mention. And I think using `who` for indexing items in the list would create more problems than it would solve. Your suggestion of using `who` as a table key, however, is perfectly sensible and probably the way to go. – Nicolas Payette Apr 27 '17 at 13:40
Sorry, using a raw...? – mattsap Apr 27 '17 at 13:42
1

Sorry: a raw _list_. Fixed above. – Nicolas Payette Apr 27 '17 at 13:43
What is `initial-price` here- is that a value from your interface (I can't get it to work)? I think for ease-of-use I'd lean towards storing the land prices in the developers- is there an argument against doing so? – Luke C Apr 27 '17 at 13:46
initial-price is just a place holder for the initial-pricing. There is an argument against and for storing the prices in the developers; however, I think that it really depends on what type of operations the rest of the code uses (i.e. how much memory is being accessed at a time on the program's side of things). I wouldn't want to state an argument until I see more written. – mattsap Apr 27 '17 at 13:59
Thanks both. I managed to cobble together a particular inelegant solution for 2 developers in the interim, which involved giving each patch two prices, one for each developer. I've not really used tables before, but I think they could help me in other ways, so I'll have a go. – MikePB Apr 27 '17 at 14:25

Nicolas Payette · Answer 2 · 2017-04-27T14:19:09.857

@mattsap's suggestion of using the table extension is probably the way to go, but just for the record: you might also consider using links.

The problem, in this case, is that a link can only be between a turtle and a turtle, never between turtle and a patch.

You could, however, consider making your "lands" turtles, and just put one on each patch. Here is a full example of what I mean:

breed [ lands land ]
breed [ developers developer ]
undirected-link-breed [ price-links price-link ]
price-links-own [ price ]

to setup
  clear-all
  set-default-shape lands "square"
  create-developers 10
  ask patches [
    sprout-lands 1 [
      set color green - 3
      create-price-links-with n-of 2 developers [
        hide-link
        set price random 100
      ]
    ]
  ]
end

Depending on what you're trying to do, there might be some trade offs involved (memory being one) but conceptually, this is a very clean way to proceed.

And NetLogo makes it very easy and pleasant to work with links (much more pleasant than using the table extension in my opinion). The main advantage is that you can query links from both directions:

observer> ask one-of developers [ show [ price ] of my-price-links ]
(developer 6): [85 68 79 26 40 60 72 85 94 50 63 75 81 97 15 46 71 34 75 15 87 0 30 9 57 23 14 63 73 66 5 13 94 20 78 8 36 12 18 49 43 35 24 38 93 34 15 72 63 68 15 86 46 21 30 67 19 89 73 62 83 33 14 13 62 46 54 17 12 35 58 7 29 51 35 99 95 96 78 74 81 36 98 45 86 2 3 45 24 35 35 43 11 63 72 11 50 16 14 60 36 89 83 50 64 65 11 38 92 75 78 94 76 12 77 30 6 61 79 63 39 68 20 99 43 72 74 1 12 18 70 98 23 72 2 15 11 44 29 17 24 73 74 53 42 63 23 53 86 45 6 60 17 49 98 79 69 96 54 6 19 20 99 46 1 31 66 85 22 42 74 2 19 60 93 54 37 20 77 75 64 42 78 40 82 11 91 13 56 56 28 34 42 5 75 7 46 91 69 83 76 92 69 71 14 35 30 85 78 95 25 3 2 1 77 73 92 31 54 83 5 89 2 32 19 10 59 72 80 93 60 62 44 92 49 49]
observer> ask one-of lands [ show [ price ] of my-price-links ]
(land 997): [43 70]

Or you can get to the developers directly from the land (and vice versa):

observer> ask one-of lands [ show sort price-link-neighbors ]
(land 112): [(developer 4) (developer 5)]

To show the price of a specific developer for a specific land:

observer> ask developer 2 [ show [ price ] of price-link-with land 737 ]
(developer 2): 94

See the Links section of the NetLogo dictionnary for all the neat things that you can do...

patches-own a vector in netlogo

2 Answers2