Is it possible to subtract previously diffused values?
I have a land-use model where residential use (yellow patches) diffuses its land value with the diffuse primitive:
diffuse land-value 1
In the first image below, land value is represented as white tones, the brighter the tone, the higher the land value. Residential use sometimes abandons the patch, but their land value influence stays (second image). Is there a way that, when the land use disappears, the value it previously diffused to all patches be subtracted and also disappear?
Following comments under the question and following Luke's suggestion of framing the diffusion of land-value as a function of distance instead of a recurring diffuse, I have set up the following solution (in point 1).
Below (in point 2), you find a possible approach (not fully coded, but sketched-out enough) for addressing the issue if you want to stick to diffuse.
1 - Approach with function of distance
What happens here is that, when a patch gains residential status (to create-residence), all other patches in a certain radius calculate how much spill-over land-value they get based on the residential value of the new residential patch and on how much it is distant (to-report diffused-value).
The advantage of this approach is that this calculation is fully replicable at any moment because it is based on two constants: the distance between patches and the initial residential value of the patch in question (for which I created the patches-own own-residential-value, distinct from the general land-value).
For this reason, when a patch loses residential use (to dismantle-residence) it is possible to perform the same calculation but, instead of having patches add diffused-value to their land-value, they will subtract it.
I think the code I place below best illustrates its functionality if you create the create-residence and dismantle-residence buttons in the Interface, and play with them to see how overlapping land-values add and subtract in the View.
globals [
; Agentsets for patches.
residence
non-residence
]
patches-own [
land-value
own-residential-value
]
to setup
clear-all
set non-residence (patch-set patches)
set residence (patch-set)
end
to create-residence
let new-res one-of non-residence
ask new-res [
set non-residence (patch-set other non-residence)
set residence (patch-set self residence)
set own-residential-value (random 10) + 1
set land-value (land-value + own-residential-value)
set pcolor yellow
diffuse-value
]
update-colours
end
to diffuse-value
ask other patches in-radius 10 [
set land-value (land-value + diffused-value)
]
end
to dismantle-residence
let target one-of residence
ask target [
set residence (patch-set other residence)
set non-residence (patch-set self non-residence)
; As opposed to 'to create-residence', where 'diffuse-value' is at the end of this block of commands,
; here 'subtract-value' has to be placed before the patch updates its 'own-residential-value' to 0,
; because that value is needed to calculate 'diffused-value'.
subtract-value
set land-value (land-value - own-residential-value)
set own-residential-value 0
]
update-colours
end
to subtract-value
ask other patches in-radius 10 [
set land-value (land-value - diffused-value)
]
end
to-report diffused-value
; Here, 'myself' is the new residential patch (as 'new-res' in 'to create-residence') or
; the new non-residential patch (as 'target' in 'to dismantle-residence').
let d distance myself
let v [own-residential-value] of myself
report v * (0.9 / d) ; Just an arbitrary function of value and distance.
end
to update-colours
ask non-residence [
set pcolor scale-color white land-value 0 15
]
end
2 - Approach if sticking to diffuse
I have though of an approach for this case too, but I also want to understand if diffuse really is what you want to use.
As we know, diffuse is a zero-sum game: what is diffused by a patch is also lost by a patch.
Therefore, I imagine you will not be just using diffuse land-value 1, because in that case land-value of the residential patch will be 0 after one tick, will very slightly recover on the subsequent tick, and will then progressively approach 0 from the third tick on.
For example, the following code gives the results as in the table below:
patches-own [
land-value
]
to setup
clear-all
reset-ticks
ask patch 0 0 [set land-value 50]
end
to go
diffuse land-value 1
tick
end
I doubt this is anything you are interested in replicating, so I assume the approach would be something like:
patches-own [
land-value
temp
]
to setup
clear-all
reset-ticks
ask patch 0 0 [set land-value 50]
end
to go
diffuse-value
tick
end
to diffuse-value
ask patches [
set temp land-value
]
diffuse land-value 1
ask patches [
set land-value (land-value + temp)
]
end
However, I think that even in this case diffuse seems to be not fit for representing a residential value spreading to near-by areas. By using the code above, in fact, the result is the following:
The table above shows that, in 15 ticks, the patch which should be the one diffusing some value in the area experienced a 93593% increase (no, I didn't forget any decimal point!) in its land value. I know of course this might be mitigated with some formula, but I think it shows the tendency of diffuse in this case: to create an escalating positive feedback between patches, so that a small residential value grows without control.
I'm not the expert of residential values here, but I felt these results (from both the former and the latter use of diffuse) were worth pointing out from a NetLogo perspective.
That said, if the idea is to stick to diffuse...
patches-own [
land-value
own-residential-value
residential-start
temp
]
to setup
; Some code.
end
to go
; Some code.
end
to create-residence ; Executed by the observer. This procedure cannot be executed by the patch becoming residence because it contains 'diffuse'.
let target ; <- Identify here the patch that needs to become residence.
ask target [
; Set 'own-residential-value' to something.
set land-value (land-value + own-residential-value)
set residential-start ticks
]
; Have some code here that uses 'diffuse own-residential-value'.
end
to dismantle-residence ; Executed by the observer. This procedure cannot be executed by the patch being dismantled because it contains 'diffuse'.
ask patches [set temp 0] ; This is crucial in order to avoid any overlap among patches when using 'diffuse'.
let target ; <- Identify here the patch that needs to be dismantled.
let time-as-residence (ticks - [residential-start] of target)
ask target [
set temp own-residential-value
]
repeat time-as-residence [
; Insert here the exact same code that
; was used for using 'diffuse' but
; diffusing the 'temp' variable instead
; (e.g. 'diffuse temp 1').
]
ask patches with [temp > 0] [
set land-value (land-value - temp)
]
end
What happens above is that, whenever a patch loses residential use, the program performs exactly the same number of diffuse operations as it performed when actually diffusing land-value during the residential life of the patch at stake, but on temp instead of land-value. This way, all the surrounding patches will store in temp the same value they gained over time from the patch being dismantled - so they can subtract this value from their current land-value.
The success of this approach depends on the ask patches [set temp 0] statement: given that diffuse operates on each patch, by setting all temp to 0 and then doing ask target [set temp own-residential-value] we make sure that we only reproduce the pattern of value-diffusion that can be attributed to the patch being dismantled - avoiding any overlap that might have occurred over time, when patches may have gathered (and then re-diffused) value from other residential patches.
(This is based on the assumption that you use diffuse at every tick, as you said in a comment to the question. Even if that ceases to be the case, it will be easy to set time-as-residence in an alternative way according to the number of times that diffuse took place since a particular patch became residential)
Potential problem This is something that you will have to untangle yourself, but consider that there remains a possible issue: you have to decide whether you want to diffuse own-residential-value or land-value, with both options presenting some problem.
Diffusing own-residential-value seems intuitive to me, since that is the added value; however, this means that the diffused value would go into own-residential-value of the other patches (and not into their land-value) even if they really do not have any residential value of their own, which will create the need for extra computation (a possible option could be to rename own-residential-value to something more appropriate, like residential-value, and create a further tot-value patches-own variable that is updated at every tick as set tot-value land-value + residential-value).
On the other hand, diffusing land-value would be more straightforward in terms of coding (land-value would just propagate to other patches' land-value) but seems less precise based on what I can understand, given residential patches would be propagating land-value which often will not be just the new residential value that they bring, but also the result of that positive feedback discussed before, building on other patches' residential values.
Conclusions
While I'm quite confident that the second approach is viable and technically good, I definitely prefer the first based on the doubts that I expressed over the use of diffuse for this particular goal (at least based on the understanding I have of your intentions, which I might not understand fully) - and the feeling that a function of distance looks like a neat approach to diffusion of value in this scenario.
I am trying to change a variable (score) of a particular agent in the agent set if it meets the specific condition of a patch. This is called by an another agent. To be more clear. My idea is for instance if there is a breed (horse) and it sees the patch (grass) and it is standing on another breed (vertices - since horse move along a path connected by nodes represented by vertices) - a score variable to added to vertices-own where if the grass quality <=3, it would add a score to the vertex on which it stands.
ask horses[
ask patches in-cone 50 60 [
if grass-quality <= 3 ask vertices with [min-one-of vertices in-radius 0 [distance myself] [set vertex-score vertex-score + 1 ]]]]
I know something is wrong with this code logic. I am trying to convert my mentioned thought into codes. Kindly suggest me.
Thank you all.
Regards,
Heng wah
NetLogo agent (turtle) positions are continuous numbers so it is generally wrong to try and say something like 'if another turtle is where I am'. While you may have got there using move-to, it's probably safer to have the horse identify a vertex that is very close to it rather than in the exact position. You have used radius 0 but I'm going to change that to 0.001 to allow for potential errors in position.
ask horses
[ if any? patches in-cone 50 60 with [ grass-quality <= 3 ]
[ let my-vertex min-one-of vertices in-radius 0.001 [distance myself]
ask my-vertex
[ set vertex-score vertex-score + 1 ]
]
]
]
This is not tested, but I have simply reorganised your code. You had some bracketing issues and you were also asking vertices to find the closest vertex (which would have been itself), rather than having the horse find the closest vertex.
It's also not necessary to separate the let and the ask but I thought that would be easier for you to see how it works.
There is a model in NetLogo based on simple preferential attachment. Agents create links thusly:
to go
if count turtles > num-nodes [ stop ]
let partner one-of [both-ends] of one-of links
create-turtles 1 [
set color red
move-to partner
fd 1
create-link-with partner
]
layout
tick
end
In this model, a node's chance of being selected is directly proportional to the number of connections it already has. I want to edit this code so that there is a variable, prestige, which also determines the probability that a node will be selected. I understand that I need to create a variable for turtles called prestige, but I'm stuck on how to make it so that the probability that a link will be created is also proportional to the amount of prestige a turtle has.
For example, I have 10 turtles at one patch, how do I move a specific turtle (turtle with [color = red]) to the top?
Thank you for your help!
I will assume that the question is about the "z-order" of the turtles and that "moving a turtle to the top", means "have it painted on top of the other ones".
There are two factors that determine the painting order in NetLogo: breeds, and ẁho numbers. Breeds have precedence. As per the Breeds section in the Programming Guide:
The order in which breeds are declared is also the order in which they are layered in the view. So breeds defined later will appear on top of breeds defined earlier;
Turtles within the same breed are painted in their order of creation (inferable in NetLogo by their who number): the older ones are painted first, and the newer ones are painted on top.
The order of creation is not modifiable, but if nothing in your code is holding on to turtle references or who numbers (the latter being inadvisable anyway), you could use hatch to create a clone of a turtle and then kill the old one immediately. For example:
to setup
clear-all
create-ordered-turtles 10 [ set size 10 ]
ask turtles with [ color = red ] [
hatch 1
die
]
end
The last line would bring all the red turtles (only one in this case) on top.
What if you can't do that, for some reason? Then you can use breeds:
breed [ background-turtles background-turtle ]
breed [ foreground-turtles foreground-turtle ]
to setup
clear-all
create-ordered-background-turtles 10 [ set size 10 ]
ask turtles with [ color = red ] [
set breed foreground-turtles
]
end
You would need as many breeds as you want "layers" of turtles. This may or may not be convenient. The best approach will depend on your specific use case.
There is some ambiguity.
To move the turtle to the top of the patch
Set ycor pycor + .5
To move it to the top of the view
Set ycor max-pycor
To make it the top of the stack in the photoshop kind of way. Not so easy.
turtles are displayed in order of their who ids. Who ids can not be changed. So if you want red to be on top either create it last or have it swap values with the turtle on top. Sorry.
I am developing a model in Netlogo. I have many agents in my model. each agents must have a radio scope. Two agents can communicate with each other and transfer some critical data When they place in a common scope area.
Imagine that i have 100 agents with 5px scope and 200 agents with 3px scope. I have also 1 master agents that move around in the word. This master agent have a scope too(for example 7px) . Agents can communicate with each other when they place in common scope area. When they communicate they can transfer some of their data. At first just master agent have this critical data and just master agent can transfer this important data. But after he transfer its data to the other agents, those other agents that have this data can transfer this data too. The important condition is being in the common scope.
How can I do this?
Thank you
You just gave a very general statement of your problem. You will get better answers if you make the effort to actually start implementing something and ask about more specific difficulties that you are facing.
That being said, I made a small model that more or less fits with your description. Perhaps it could be useful for you as a starting point and you can ask separate (more precise) follow up questions if you have some.
turtles-own [ scope data ]
to setup
clear-all
; make a big world so agents don't
; bump into one another right away:
resize-world -100 100 -100 100
set-patch-size 3
; create turtles and distribute them around:
crt 100 [ set scope 5 set data "" ]
crt 200 [ set scope 3 set data "" ]
crt 1 [ set scope 7 set data "important data" ]
ask turtles [
set size 3
setxy random-xcor random-ycor
recolor
]
end
to go
ask turtles [ travel ]
ask turtles with [ not empty? data ] [ share-info ]
ask turtles [ recolor ]
end
to travel
; you haven't specified how turtles should move
; so here's a classic "wiggle":
rt random 30
lt random 30
fd 1
end
to share-info
ask other turtles in-radius scope with [ empty? data and distance myself < scope ] [
set data [ data ] of myself
]
end
to recolor
set color ifelse-value empty? data [ grey ] [ red ]
end
Edit:
Following Seth's comment that my first version probably didn't capture the idea of a common scope, I've added and distance myself < scope. This way, only turtles that can see each other can share information.
I've also added a with [ not empty? data ] clause when asking turtles to share info, because there is no use in having turtles with empty data share it.