I have set up a polygonal node (called area_wait) that a single type of agent remain at whilst in a queue. I'm trying to find the number of agents at a node using a function. I don't want to count the agents in the queue as I have set up one queue for all waiting agents which might be at different nodes.
I'm using the following code which always returns zero.
int count_X = area_wait.agents().size();
In fact the list is empty when I check with:
List list_X = area_wait.agents();
What am I doing wrong? Thanks in advance.
I will give you the same answer I gave in the anylogic users group which can be found here: https://www.linkedin.com/feed/update/urn:li:activity:6721800348408791040
so this function you are trying to use doesn't work... unless the thing that is inside the node is a transporter and only if the node has a speed or access restriction... this might either be a bug or something explained poorly on the documentation, but it sounds like a bug to me
If you want to know the number of agents in a node you can use the alternative method count(myAgents,a->a.getNetworkNode()!=null && a.getNetworkNode().equals(yourNode)) but this fails if you change the node position without a moveTo block or some other natural movement (such as defining your node in the agent location parameter of a block)... so.. that's another bug, but maybe it won't apply to you
So summary... no easy and safe solution as far as I know
Related
I'm working on a simulation on Anylogic where there is a buffer for containers in a port.
I use Point Nodes to mark destinations for the containers, but how can I check if there is already a container (an agent) on that Point Node (on that position) ?
PS : don't mind my mistakes, english isn't my native language.
There is no pre-build way as point nodes do not keep track of agents on top of them. You can have as many as you want.
So you have to do it manually and there are many ways. One suggestion:
create a collection of type LinkedHashMap with key=PointNode and value storing the agent currently at that node.
This way, you can keep track easily. (You might need to read up on LinkedHashMaps first, if you don't know them).
cheers
I'm very new to Gremlin. I have been going through the documentation but continue to struggle to find an answer to my problem. I'm assuming the answer is easy, but have unfortunately become a little confused with all the different API options e.g. subgraphs, side effects and would like a little help/clarity from the expert group if possible.
Basically (as an example) I have a graph that looks like the below where I first need to select 'A' and then traverse down the children of 'A' only, to find if there is Vertex that matches 'A3' or 'A4'.
Selecting the first Vertex of course is easy, I simply do something like:
.V().has("name", "A")
However, I'm not sure how I can now isolate my second vertex search to the children of 'A' only. As I mentioned before I have stumbled upon subgraphs but have not being able to fully grasp how I can leverage this capability or if I should for my purpose.
I'm using TinkerPop3 and Java 8.
Any help will be greatly appreciated!
When you start your traversal with: g.V().has('name','A') you get the "A" vertex. Any additional steps that you add after that are restricted to that one vertex. Therefore g.V().has('name','A').out() can only ever give you the "A1" vertex and related children.
To traverse through all the children of "A", you need repeat() step:
g.V().has('name','A').
repeat(out()).
until(has('name',within('A3','A4'))
So, basically find "A", then traverse through children until you run into "A3" or "A4".
In the future, please consider supplying a Gremlin script that can be pasted into the console to construct your example graph - here's an example. An example graph in that form is quite helpful.
Suppose we have a graph like this.
(User)-[:KNOWS]->(Friend)
I want to count all outgoing relationship from User and group them by user, then add some condition to filter. (Like more than 10 Knows)
This is what I did,
g.V().hasLabel("Friend").in("KNOWS").hasLabel("User").groupCount().next()
This is returning a map, so I can add the condition to filter the results. My question is , do we have any efficient alternative way to do this ?
I am not sure if I understood your question correctly, but it sounds like you just want to filter all users based on their number of outgoing edges with the label knows.
In that case you can directly start at the User vertices and filter them based on the number of their KNOWS edges instead of doing a groupCount:
g.V().hasLabel('User').where(outE('KNOWS').count().is(gt(10)))
Until now I ignored any performance constrains. But as Paul Jackson mentioned in his comment it is not efficient to execute such a query in OLTP mode like this. Neo4j will probably iterate over all vertices, check whether they have the label User and then count their KNOWS edges.
You basically have two options to speed this up:
As Paul Jackson suggested: Add the edge count as a property to the vertices, pre-compute it and then index this property or
Use something like Spark-Gremlin if you really want to compute the edge count on the fly.
I have a puzzle game that has a State depending on the arrangement of the pieces in the puzzle. I am trying to solve this puzzle using Depth First Search, however I am confused on how to approach it. From my understanding, Depth First Search will search a graph to find a solution, but my puzzle isn't in graph form. All I know is the current state and the states achievable from that state.
Am I supposed to build this graph as I discover all possible states from the state I am currently at? Wouldn't that defeat the purpose though - first building a graph with every possible state, then search the entire graph for the solution?
I have a method that can explore all the possible states from the current state using a Move, which I'm sure will come in handy except I don't know how to put it to use.
You don't have to explicitly build a graph. You can represent your problem as a graph, conceptually, where the nodes are the states and the edges are the transitions between the states. Depth first search is to follow an edge all the way until you hit an end state, before moving on to another edge. So it would look something like this (pseudocode):
def search(state):
if is_end_state(state):
# search down this branch finished, do something
return something
for move in possible_moves_from(state):
search(apply_move(state, move))
You end up implicitly building the graph, via the recursive calls and the stack state, as you go.
Note that if you have cycles (e.g. you can move left, then move right to get back to the exact same state) then you will have to keep track of already-visited states or you'll loop forever. Something like this:
def search(state, seen_states):
if state in seen_states:
# already visited, don't visit again
return
seen_states.add(state)
# same as before:
if is_end_state(state):
return something
for move in possible_moves_from(state):
search(apply_move(state, move), seen_states)
In terms of how to implement this, I recommend you have seen_states be a HashSet<State> and you make your State hashable.
Sounds to me like depth first is the wrong way about it. If you have a state, and you know all states that you can get to from that state, then breadth first may be more appropriate. With BFS you would know that the first solution you come to is the shortest solution.
If you are certain that there is a solution then you wouldn't have to worry about infinite recursion because any paths caught in a loop wouldn't be the shortest in the end anyway, they would just cause unnecessary work.
An iterative solution using a queue would work.
/** pseudocode **/
Queue q = new LinkedList();
q.put(myState)
while ( !q.isEmpty()) {
State s = q.remove();
if ( endState.equals(s)) {
return something;
}
for ( State newState : s.getNextStates()) {
q.add(newState);
}
}
If you do want to go with a depth first search, then simply change the queue to a stack but then you will have to deal with the cycles.
If your queue item was a wrapper that that contained the path to the current state instead of just the current state then you could easily get to the depth and path that was traversed for the shortest route (or at least, first shortest route discovered if there are multiple routes of the same depth.)
I'm writing a Java Tree in which tree nodes could have children that take a long time to compute (in this case, it's a file system, where there may be network timeouts that prevent getting a list of files from an attached drive).
The problem I'm finding is this:
getChildCount() is called before the user specifically requests opening a particular branch of the tree. I believe this is done so the JTree knows whether to show a + icon next to the node.
An accurate count of children from getChildCount() would need to perform the potentially expensive operation
If I fake the value of getChildCount(), the tree only allocates space for that many child nodes before asking for an enumeration of the children. (If I return '1', I'll only see 1 child listed, despite that there are more)
The enumeration of the children can be expensive and time-consuming, I'm okay with that. But I'm not okay with getChildCount() needing to know the exact number of children.
Any way I can work around this?
Added: The other problem is that if one of the nodes represents a floppy drive (how archaic!), the drive will be polled before the user asks for its files; if there's no disk in the drive, this results in a system error.
Update: Unfortunately, implementing the TreeWillExpand listener isn't the solution. That can allow you to veto an expansion, but the number of nodes shown is still restricted by the value returned by TreeNode.getChildCount().
http://java.sun.com/docs/books/tutorial/uiswing/components/tree.html#data
scroll a little down, there is the exact tutorial on how to create lazy loading nodes for the jtree, complete with examples and documentation
I'm not sure if it's entirely applicable, but I recently worked around problems with a slow tree by pre-computing the answers to methods that would normally require going through the list of children. I only recompute them when children are added or removed or updated. In my case, some of the methods would have had to go recursively down the tree to figure out things like 'how many bytes are stored' for each node.
If you need a lot of access to a particular feature of your data structure that is expensive to compute, it may make sense to pre-compute it.
In the case of TreeNodes, this means that your TreeNodes would have to store their Child count. To explain it a bit more in detail: when you create a node n0 this node has a childcount (cc) of 0. When you add a node n1 as a child of this one, you n1.cc + cc++.
The tricky bit is the remove operation. You have to keep backlinks to parents and go up the hierarchy to subtract the cc of your current node.
In case you just want to have the a hasChildren feature for your nodes or override getChildCount, a boolean might be enough and would not force you to go up the whole hierarchy in case of removal. Or you could remove the backlinks and just say that you lose precision on remove operations. The TreeNode interface actually doesn't force you to provide a remove operation, but you probably want one anyway.
Well, that's the deal. In order to come up with precomputed precise values, you will have to keep backlinks of some sorts. If you don't you'd better call your method hasHadChildren or the more amusing isVirgin.
There are a few parts to the solution:
Like Lorenzo Boccaccia said, use the TreeWillExpandListener
Also, need to call nodesWereInserted on the tree, so the proper number of nodes will be displayed. See this code
I have determined that if you don't know the child count, TreeNode.getChildCount() needs to return at least 1 (it can't return 0)