I am implementing a node selector. I was thinking that SCIPgetLeaves will give me the list of current nodes among which one needs to be selected for further branching. After the presolving stage, SCIPgetLeaves in NODESELSELECT() doesn't return any node. Instead, I had to use SCIPgetFocusNode().
The documentation states that the NODESELSELECT() chooses one of leaves, children and siblings, so I tried collecting all three. Is there a reason why children and siblings of the root node are not included in leaves after the presolving stage? Just trying to understand the design of SCIP.
All three node types relate to the focus node:
SCIPgetChildren() offers quick access to the children newly created via branching
SCIPgetSiblings() offers access to the sibling(s) of the focus node
SCIPgetLeaves() is the rest with more distant relationships to the focus node
Just keep in mind that with every selection, the open nodes are partitioned into the 3 types above.
The node solution process greatly benefits from the possibility of warm/hotstarting the dual Simplex Algorithm, which is why SCIP (and other solvers as well) mostly perform diving (also called "plunging") down the tree, with some limits. This requires quick access to the children of the focus node.
Have a look at src/scip/nodesel_dfs.c for a good example of a simple node selection.
Related
So, my problem is that I need to store a tree structure in an SQL database.
There are 2 types of nodes: NODES and LEAVES. Nodes store no data. Leaves store a single number.
Sometimes the new nodes and leaves may be inserted (it is okay to insert them in the middle of some hierarchy), other times they may get deleted (both leaves and nodes), they may also get updated (for example, switch parent node to another one ot get new data, for leaves).
My primary goal is to be able for each node to tell the mean value of its leaves (transitive included, i. e. leaves of child nodes, leaves of chld of child, e.t.c).
So far I have came up with multiple ideas, but I do not find them really efficient and maintainable in the means of inserting and deleting data:
Using PostgreSQL's ltree module. It allows for quick checking of a node belonging to some leaf, including, transitively. Using that we can select based on leaf being a child of a current node and then calculate a mean value. However, it seems to me, there may be issues with updating. For example, when a node switches its parent we will need to update every child node and leaf (including transitive ones) so we do not match them when, for example, try to search for leaves belonging to node before the previous parent of the switching node. (hope doesn't sound too complicated)
The second approach I've considered is using arrays in each node and leaf to store all its ancestry (like parent, grandparent, grand-grand, e.t.c). This, actually, shares the same problem considering switching parent. Moreover I have doubts about the perfomance of searching in arrays, since the hierarchy may become really deep).
Basic approaches like storing direct parent link / childs array seem not perfomant enough to me, since I will have to execute n-1 queries, where n is the depth of the tree
So now I'm wondering if there any other ideas, I have not thought of. I believe, there must be a better approach!
Is there a combination of parameter settings so that the search tree only contains "simple" node types, i.e. not SCIP_NODETYPE_{PROBINGNODE, DEADEND, JUNCTION, PSEUDOFORK, FORK, SUBROOT, REFOCUSNODE}? Even if it means disabling some functionality.
I'm also not really sure about what the different node types really mean, so any pointers to documentation would also be very useful.
The meaning of the different node types is explained here. If you have a closer look, you will understand that those types reflect the internal organization of the tree. They necessarily occur during tree search and cannot be skipped via parameters.
If you insist: setting limits/nodes = 1 will process only the root node of SCIP, and the tree will only consist of a focus node and its 2 children.
Is there a layout or an option to avoid grouping nodes to overlap eachother?
I'm getting a graph with standalone and grouped nodes, but the combinations are dependent on dynamic data. So i can not place them on my one, or would like to avoid it.
All layouts i have tried do not take care of the grouping nodes and place their sub nodes together.
For example 'circle' creates one circle of all nodes, not a circle per group.
The goal would be to create something like "http://js.cytoscape.org/demos/5b192c88616af2f75344/", but there the nodes are placed manualy..
I have seen the example "http://js.cytoscape.org/demos/59e38e9f20e25a293e44/" which seems to work as required but it is using an extension. First of all i would like to find a built in solution.
Your requirement for a non-extension solution is erroneous.
Only basic, small KB layouts are included in Cytoscape.js itself, and it makes no functional difference whether a layout is included by default or not: They are both extensions -- some are included by default, some are not.
CoSE Bilkent is the best compound node layout algorithm for graphs/networks -- bar none. You can alternatively use CoSE, which is included by default. CoSE is a more basic version of the algorithm, optimised for speed at the expense of visual results in some cases.
There is a note on the cytoscape.js website that says:
"Note that a collection is immutible by default, meaning that the set of elements within a collection can not be changed. The API returns a new collection with different elements when necessary, instead of mutating the existing collection. This allows the developer to safely use set theory operations on collections, use collections functionally, and so on."
Does this mean it is not really suitable to use in the creation of online 'network editor' ie. where the user can interact to add and delete nodes and edges to the existing graph?
If I understand the note above it would mean that adding a new node would mean reconstructing the whole graph from scratch (but with the new node) and then presumably performing a complete redraw. Is this correct?
A collection is a set of elements; the set merely points to all the individual elements. You can think of it like an array of elements: The array just holds the elements. Different arrays/sets can have different, similar, overlapping elements, etc.
Cytoscape.js is very suitable for the purpose you mention. There are already projects that have live, collaborative editors (similar to google docs, online office, etc but for graphs). For example, a simple one that I created is codenamed "Factoid" for biological processes. Though I really think it ought to have a better, more accurate name -- you can still look through the code for a live collaboration example with Cytoscape.js. Because you can listen to events easily, it's relatively straightforward to send diffs (or even just events) back and forth between the server and the client.
Adding an element is inexpensive: It just adds the single element and redraws if opportune. It's even cheaper with cy.batch() for modifying lots of elements in a row.
There are 3 different fields for User Stories for a related parent, and we have run into some confusion about them.
As I understand it:
The Parent field is for a direct parent that is another User Story
The PortfolioItem field is for a direct parent that is Feature
The Feature field is for a parent (direct or via one or more US parents) that is a
Feature
If you have the Parent and Feature fields, couldn't you compare the two of them to see if the direct parent is a US or a PI (thus rendering the PortfolioItem field unnecessary)? It seems to me the one explanation for this is that originally there were only 2 fields, "Parent" and "PortfolioItem", but that restricted the ability to see an associated feature unless you traversed the hierarchy of User Stories up to one with a Feature set as the parent.
So, my questions are:
Did I define the three fields and their uses correctly? If so,
Why are there 3 when 2 (Parent and Feature) would suffice?
Are there other cases I am not considering?
Thanks
The portfolio item field predate the feature field. When we added it to the API we had not yet created the technology to "Roll down" information in our hierarchy. Cases one and two are mainly used to show the direct parent (if any) that is shown in grids and boards.
We will probably keep the portfolioitem field around for backwards compatibility.