For my final year project I am trying to simulate how differing opinions can impact risk and overall HIV transmission. The part I have a problem with is a fairly simple code so I have each turtle with a different risk level 0-1, as well as educators with risk of 0, and misinformation spreaders with a risk of 1, then when they land on a patch they change to the mean of the patch.
We have added a switch to turn on and off my educators and misinfo spreaders (influencers?) as well as a chooser to swap between the mean of the patch vs the min and max. However now the simulation wont adjust and comes out with the same output no matter the adjustments.
can anyone help me with this part of the code? I think it might just be the order it is in, or if I need to add another switch to turn mean off?
""to be-influenced
if influenced-by = "mean" [
if any? other turtles-here [
set patch-risk mean [risky] of turtles-here
set risky patch-risk
]
]
if influenced-by = "max" [
if any? other turtles-here[
set patch-risk max [risky] of turtles-here
set risky patch-risk
]
]
if influenced-by = "min" [
if any? other turtles-here [
set patch-risk min [risky] of turtles-here
set risky patch-risk
]
]
if influencers? [
if any? other turtles-here with [influencer? = TRUE] [
ask one-of turtles-here with [influencer? = TRUE] [
set temptur [who] of self
set patch-risk [risky] of turtle temptur
]
set risky patch-risk
]]
end""
Related
I'm looking for a pattern.
I'm working on this query:
g.V().has('objid','7615388501660').as('location')
.in('enhabits').as('population')
.out('isInFaction').as('faction')
.in('isInFaction').out('isOfSpecies').as('species')
.path().by('name')
and I get this back:
"labels": [
["location"],
["population"],
["faction"],
[],
["species"]
],
"objects": [
"Plara",
"Se Bemon",
"Se",
"Se Bemon",
"Wan"
]
but there is an extra step [] that I feel is the wrong approach. It also traverses through all of the populations in that faction, not just the one I want. What I want is each record of the location, population, faction, species in a list. Or, in another way, for each population in that location, I want that population, it's faction, it's species.
You can often flatten these backtracking type of use cases by introducing a union step into the query. Something along the lines of :
g.V().has('objid','7615388501660').as('location').
in('enhabits').as('population').
local(
union(
out('isInFaction').as('faction'),
out('isOfSpecies').as('species')).
fold()).
path().
by(unfold().values('name').fold())
I have a cosmos DB whose size is around 100GB.
I successfully create a nice partition key, i have around 4600 partition on 70M records, but I still need to query on two datetime fields that are stored as a string, not in an epoch format.
Example json:
"someField1": "UNKNOWN",
"someField2": "DATA",
"endDate": 7014541201,
"startDate": 7054864502,
"someField3": "0",
"someField3": "0",
i notice when i do select * from tbl and when i do select * from tbl where startDate > {someDate} AND endDate<{someDate1} latency different is around 1s, so this filtering does not decrease my latency time.
Is it better to store date types as number? Does cosmos have better performance on epoch query ranges?
I am using SQL API.
Also when i try to add hash indexes on a startDate and endDate he basically convert that into two indexes.
Example:
"path": "/startDate/?",
"indexes": [
{
"kind": "Hash",
"dataType": "String",
"precision": 3
}
]
},
this is converted to
"path": "/startDate/?",
"indexes": [
{
"kind": "Range",
"dataType": "Number",
"precision": -1
},
{
"kind": "Range",
"dataType": "String",
"precision": -1
}
]
Is that a normal behaviour or it is related to my data?
Thanks.
I checked query metrics, and for 4k records query to cosmosDB is executed in 100ms. I would like to ask you is it normal behaviour that
var option = new FeedOptions { PartitionKey = new PartitionKey(partitionKey), MaxItemCount = -1};
var query= client.CreateDocumentQuery<MyModel>(collectionLink, option)
.Where(tl => tl.StartDate >= DateTimeToUnixTimestamp(startDate) && tl.EndDate <= DateTimeToUnixTimestamp(endDate))
.AsEnumerable().ToList();
this query returns 10k results (in Postman its around 9MB size) in 10-12s? This partition contains around 50k records.
Retrieved Document Count : 12,356
Retrieved Document Size : 12,963,709 bytes
Output Document Count : 3,633
Output Document Size : 3,819,608 bytes
Index Utilization : 29.00 %
Total Query Execution Time : 264.31
milliseconds
Query Compilation Time : 0.12 milliseconds
Logical Plan Build Time : 0.07 milliseconds
Physical Plan Build Time : 0.06 milliseconds
Query Optimization Time : 0.01 milliseconds
Index Lookup Time : 51.10 milliseconds
Document Load Time : 140.51 milliseconds
Runtime Execution Times
Query Engine Times : 55.61 milliseconds
System Function Execution Time : 0.00 milliseconds
User-defined Function Execution Time : 0.00 milliseconds
Document Write Time : 10.56 milliseconds
Client Side Metrics
Retry Count : 0
Request Charge : 904.73 RUs
I am from the CosmosDB engineering team.
Since your collection has 70M records, I assume that the observed latency is only on the first roundtrip (or first page) of results. Note that the observed latency can also be improved by tweaking FeedOptions.MaxDegreeOfParallelism to -1 when executing the query.
Regarding the difference between the two queries themselves, please note that SELECT * without a filter is a full scan query, which is probably a bit
faster to first return results, when compared to the other query with two filters, which does a little bit more work on the local indexes across all the partitions, which may explain the observed latency.
Regarding your other question, we no longer support the Hash indexing policy on new collections. Please see here: https://learn.microsoft.com/en-us/azure/cosmos-db/index-types#index-kind . We automatically convert Hash indexes to Range with full precision.
You may also fetch QueryMetrics for your query and analyze the results to figure out why you have latency. Details are here: https://learn.microsoft.com/en-us/azure/cosmos-db/sql-api-query-metrics#query-execution-metrics
I'm trying to make a network of friends like in this example previous to the final correction of JenB in here, since it is more comprehensible for me and Bryan Head said it would be the way he would do it with fewer agents. I'm planning to use around 200, maybe 300 agents.
My question is... how could I do it without forming pairs? I want the agents to make friends with every agent in radius x during y ticks and with the same color (I'm still working on the tick condition). I tried with if and some conditions before finding the JenB example but it was way too heavy.
I think it isn't necessary to rework the full code. But I'll write it down for you to see my version.
to make-friends
ask agentes [
let new-friendships friends - count my-friendships
if (new-friendships > 0) [
set possible-friends other agentes in-radius sight-radius with [
(count my-friendships < friends) and (color = [color] of myself) ]
create-friendships-with n-of min (list new-friendships count possible-friends) possible-friends]
end
V2 CODE
I started to work in another piece of code since I don't fully know how to do it better. This is the last version. The random-in-range 0 12 condition is in the setup.
to make-friends
ask agentes [
let new-friends max-friends - count my-friendships
let possible-friends other agentes with [color = [color] of myself] in-radius sight-radius
if new-friends > 0 [
let chosen n-of min (list new-friends count other possible-friends) other possible-friends
create-friendships-with chosen ;in-radius sight-radius [ hide-link ]
set possible-friends other possible-friends
set friends friendship-neighbors
ask chosen [
if my-friendships = friends [ set possible-friends other possible-friends ] ]
]
]
end
I have a record
record = [ [ name1:'value1', name2:'value2', name3:'value3' ],
[ name1:'value6', name2:'value7', name3:'value8' ] ]
I would like to add two more key/value pairs to with values as boolean(true/false) as below
record = [ [ name1:'value1', name2:'value2', name3:'value3', name4:false, name5:true ],
[ name1:'value6', name2:'value7', name3:'value8', name4:false, name5:true ] ]
When I tried to use add or put functions, doesnt seem to work(either replacing the existing values or not doing anything)
Just do:
record = record.collect { it + [ name4:false, name5:true ] }
Or you can also do:
record = record*.plus( name4:false, name5:true )
To add to Patricks answer above (+1), a Map contains a set not a list so all keys must be unique. So you cannot assign multiple values to a single key directly.
Among many solutions, you can alternatively, save an object:
Map<String, myObject>
that holds many different values and this will still maintain the uniqueness of the set since there will only be one key.
I compile the following graph with: dot graph.dot -Tpdf -ograph.pdf, producing:
The result is okay, but the state transition look a lot like a spagetthi monster and I have no clue what I could do to approach this problem. I tried other layouts: twopi, neato, etc. Are there parameters which allow it to force the graph to look a little bit more symmetric? Because the overall picture is okay.
To me it seems like the edges use the minimal space available to frame the edge descriptions, maybe this is the problem?
Is my graph design flawed? Should I write the different state transitions on one edge, using \n to separate the different transitions?
digraph finite_state_machine {
rankdir=LR;
edge [fontsize=26];
node [shape = doublecircle, width=2.0, fontsize=24, fixedsize=true,style=filled, colorscheme=spectral5]; New [fillcolor=3] Terminated [fillcolor=5];
node [shape = circle, width=2.0, fontsize=24, fixedsize=true, colorscheme=spectral5]; Runnable [fillcolor=4] Waiting [fillcolor=2] "Timed\nWaiting" [fillcolor=2] Blocked [fillcolor=1];
New -> Runnable [ label = "Thread.start" ];
Runnable -> Waiting [ label = "Object.wait" ];
Runnable -> Waiting [ label = "Thread.sleep" ];
Runnable -> Waiting [ label = "LockSupport.park" ];
Waiting -> Blocked [ label = "Reacquire monitor lock after\nleaving Object.wait" ]
Waiting -> Blocked [label = "Spurious wake-up"]
"Timed\nWaiting" -> Blocked [ label = "Reaquire monitor lock after\n leaving Object.wait" ]
"Timed\nWaiting" -> Terminated [ label = "Exception" ]
"Timed\nWaiting" -> Blocked [ label = "Spurious wake-up" ]
Runnable -> "Timed\nWaiting" [ label = "Object.wait" ];
Runnable -> Blocked [ label = "Contended Monitor\nEnter" ];
Blocked -> Runnable [ label = "Contended Monitor\nEntered" ];
Runnable -> Terminated [ label = "Thread finishes\nexecution" ]
Runnable -> Terminated [ label = "Exception" ]
Waiting -> Runnable [ label = "Object.notify\nObject.notifyAll" ]
Waiting -> Terminated [ label = "Exception" ]
"Timed\nWaiting" -> Runnable [ label = "Object.notify\nObject.notifyAll" ]
}
I don't think your design is flawed, I think it's ok. The dot syntax is readable and therefore maintainable, and the result is what an automatically generated graph looks typically alike.
Of course you can add small corrections to make this particular graph better (or at least different). Some of them may prove difficult to implement if for example the source for your graph is generated by an application. Here are some ideas:
To get the layout to be more symmetric, you may try to align the nodes Waiting and Terminated as well as Timed Waiting and Blocked by setting their group attribute to the same value (group=a and group=b).
It worked fine for Waiting and Teminated, but not so well for Timed Waiting and Blocked - probably because there are two edges between those nodes.
You may try to straighten them out by picking one of the edges which links them and set its weight attribute to a high value.
Other than that, I think the graph looks nicer over all because the edges are smoother and have less unnecessary curves, especially - but not only - between Runnable and Waiting.
The spaghetti effect is due to the splines - maybe it looks less spaghetti without splines? I tried by adding splines=compound or splines=ortho (same result):
The graph uses slightly less vertical space. It's not spaghetti, but it's not better in my opinion...
You may also try splines=compound without the group attributes, this should make the graph a little more compact (bug not necessarily prettier). Or simply play around with the weight of the edges to straighten out particularly unpleasant edges.
In some cases, concentrate can clear up graphs with lots of parallel edges - in this case it doesn't really help.