Is there an option in CPLEX that allows the addition of cuts only at the root?
I would expect, yes, but I can't find the name of the option.
There are several ways:
set the node limit to 1 (or 0?) so that CPLEX only work on root node. You can add your cuts, then you relax the node limit, then solve it.
When you try to add a cut, do a query first to find out the node count or something like that using the query callback. Only add when the node count is 0 (or 1?)
Drop all the integer constraints and turn it into a LP. Then add your cuts, then add the integral constraints back on and solve it.
Related
First - I've looked through similar looking questions but they did not solve my problem, this is no repetition (I hope).
I'm building and programming a robot with an Arduino Nano that is supposed to solve a maze. It gets put somewhere in the maze and then has to find an item. The next time it is supposed to go straight to the item (it does not have to be the shortest way but no dead ends allowed).
It is not necessary to know the whole maze because as long as he has one way to the item it is good. As I said, I don't need the shortest way.
The maze is 2D, I just put black tape on a white table and the robot is supposed to use a line sensor to follow the lines.
There are no other sensors to orientate himself. First I thought of making an 2D array and each field of the maze a field in there. But since it's just a normal line sensor the robot doesn't know if a straight line is one or two fields long and the whole thing does not work.
I also tried DFS or something like that but a similar problem here. The maze is circular and how is the robot supposed to know the Node was already found before and it is the same?
It would be nice if anyone had an idea!
Although orientation is a little bit fuzzy it is possible by using the decisions. A decision has to be reproducable. It could be represented by a class:
public class Decision {
boolean[] directions = new boolean[2]; // 0 = left, 1 = straight, 2 = right
// at least 2 of them should be true or it is no decision
int path; // 0-2 to mark the current path
}
Create a stack of decisions.
If there is only one possible direction at the beginning (back doesn't count and is treated later), then move forward until you meet the first decision.
Push the decision with all possible directions on the stack.
Set path to the first possible direction and move that way.
If you end up with another decision: continue at 3.
If you find the token: abort, you found a reproducible way without dead-ends.
If it is a dead-end: return to the previous decision node (the first one one the way back) and continue with 6.
Pop the decision and try the next possible direction (set the new path and push the decision) and continue at 5.
Unless you have tried all directions, then move back another decision and continue with 6.
If there are no more decisions (the special case mentioned above, we went in the wrong direction at the beginning): move forward until you meet the first decision and continue at 3. This means you need another boolean variable to indicate if you should go backwards right at the beginning.
You have to be careful when coming back from left and want to try straight next you would have to turn left and don't go straight. So there is a little calculation involved.
The algorithm has a problem for loop shaped decisions if you start the wrong way at the beginning. I think this could be escaped by setting an upper boundary, e.g. if you still haven't found the token and met 30 decision nodes (going forward), then you are probably running in circles, so go back to start and now instead of trying the directions in increasing order, try them in decreasing order.
I am wondering is it possible to fix both of them in MrBayes at the same time?
I see some previous posts about fixing the tree topology is first to define the tree and then use "fixed" function like (assuming we have defined species_topology already)
The first line fix the tree topology and the second line defines the probability of moving to other topologies is zero.
Prset topologypr=fixed(species_topology);
propset eTBR(Tau)$prob=0;
I am wondering can I do something similar to fix the branch length as well?
In terms of the proposal move to the branch lengths, I think we should use
propset nslider(V)$prob=0
But I am not sure what to put in:
Prset brlenpr=
Thanks in advance! I have searched a lot of posts in MrBayes's mailing list but they did not have questions about fixing both of them at the same time. Usually, they just fix the topology.
After searching for a lot of MrBayes tutorials, I find a way to achieve this by myself. In MrBayes 3.2, it allows us to fix both the tree topology and the branch length. We can set the prior of both topology and branch length to a fixed tree in newick format and then define the probability of moving from the initial state as zero. Remember you must define your fixed tree with fixed branch length in the nexus file where you save your sequence information data.
For example, you can define your tree in this way:
begin trees;
tree tree_1 = ((t6:0.3279207193,t9:0.9545036491):0.04205953353,t5:0.8895393161,(((t4:0.6557057991,t10:0.7085304682):0.9942697766,t3:0.5440660247):0.6405068138,((t8:0.1471136473,(t2:0.9022990451,t1:0.6907052784):0.9630242325):0.2891597373,t7:0.7954674177):0.5941420204):0.9388911405);
;
end;
Then in your MrBayes template you can use the following commands to fix the tree topology and branch length:
prset topologypr=fixed(tree_1);
prset brlenspr=fixed(tree_1);
Tau represents the topology and V denotes the branch length.
I have a grid of "blocks" (in the form of a 2D array, could be 5*5, 17*17 or whatever) where I can add or remove blocks at will, except for the one at the center that should always remain there.
I can place blocks if they have a local neighbour : on their right/left/up/down (at least one of them).
By removing some blocks, it may leave other blocks isolated with no "connection" to the center-block, and I want to avoid this.
I'm looking for a quick solution to check if all my blocks have a connection to the center, the simplest possible (in terms of coding, I can accept to have a non optimal solution since this is supposed to be on executed on very small data and not so often). The first thing that came to my mind was to implement this as a path search but that seems overkill.
I'm using C++ but that should not make any difference.
You need to find the connected components using DFS/BFS.Construct the initial graph and as you add new blocks, you can add new edges, or when you remove blocks you can remove edges.When you remove a block, temporarily delete those edges in the graph and check if it causes two pieces of the graph to disconnect.This is simple, carry out DFS again.If it does not disconnect you can remove that block.
DFS is only about 8 lines to implement, and for small data sets this is elegant.
I am binding a database table data to treeview.
In documntation it is mentioned nodes count property as integer value which is signed 2 byte.
so if the nodes exceeds this range, nodes count is becoming negative.
Is there any workaround for this?
Yes, this is a documented bug. Fortunately, no one ever encounters it in the real world because it's completely nonsensical for a single TreeView control to ever need to display more than 32,767 nodes.
As mentioned in the linked knowledge base article, the best workaround is to maintain less nodes in your TreeView control. Consider splitting the data up between multiple TreeViews, or using a different control that is better suited for such incredibly large quantities of data.
If you absolutely must use a TreeView, Microsoft recommends that you keep the following in mind:
Performance will become extremely slow as you add more and more nodes.
Do not add more than 65535 nodes. (That's the limit imposed by the native control, which uses an unsigned integer to store the node count.)
Use the SendMessage API function to obtain the true node count. Alternately, you can use a module- or public-level variable to keep track of how many nodes are in the TreeView. Each time you add or remove a node, increment or decrement the variable by one. This is necessary if you need to determine the count of nodes because the Count property of the Nodes collection will not return the correct value.
Don't rely on the Index property of a node object. For example, the Index property is 32767 for node 32767 but is -32768 for node 32768.
You can still refer to a node by using its Key or by passing a number to the Nodes collection.
For example:
TreeView1.Nodes(40000) refers to node 40000.
I was wondering if someone could help me understand this problem. I prepared a small diagram because it is much easier to explain it visually.
alt text http://img179.imageshack.us/img179/4315/pon.jpg
Problem I am trying to solve:
1. Constructing the dependency graph
Given the connectivity of the graph and a metric that determines how well a node depends on the other, order the dependencies. For instance, I could put in a few rules saying that
node 3 depends on node 4
node 2 depends on node 3
node 3 depends on node 5
But because the final rule is not "valuable" (again based on the same metric), I will not add the rule to my system.
2. Execute the request order
Once I built a dependency graph, execute the list in an order that maximizes the final connectivity. I am not sure if this is a really a problem but I somehow have a feeling that there might exist more than one order in which case, it is required to choose the best order.
First and foremost, I am wondering if I constructed the problem correctly and if I should be aware of any corner cases. Secondly, is there a closely related algorithm that I can look at? Currently, I am thinking of something like Feedback Arc Set or the Secretary Problem but I am a little confused at the moment. Any suggestions?
PS: I am a little confused about the problem myself so please don't flame on me for that. If any clarifications are needed, I will try to update the question.
It looks like you are trying to determine an ordering on requests you send to nodes with dependencies (or "partial ordering" for google) between nodes.
If you google "partial order dependency graph", you get a link to here, which should give you enough information to figure out a good solution.
In general, you want to sort the nodes in such a way that nodes come after their dependencies; AKA topological sort.
I'm a bit confused by your ordering constraints vs. the graphs that you picture: nothing matches up. That said, it sounds like you have soft ordering constraints (A should come before B, but doesn't have to) with costs for violating the constraint. An optimal algorithm for scheduling that is NP-hard, but I bet you could get a pretty good schedule using a DFS biased towards large-weight edges, then deleting all the back edges.
If you know in advance the dependencies of each node, you can easily build layers.
It's amusing, but I faced the very same problem when organizing... the compilation of the different modules of my application :)
The idea is simple:
def buildLayers(nodes):
layers = []
n = nodes[:] # copy the list
while not len(n) == 0:
layer = _buildRec(layers, n)
if len(layer) == 0: raise RuntimeError('Cyclic Dependency')
for l in layer: n.remove(l)
layers.append(layer)
return layers
def _buildRec(layers, nodes):
"""Build the next layer by selecting nodes whose dependencies
already appear in `layers`
"""
result = []
for n in nodes:
if n.dependencies in flatten(layers): result.append(n) # not truly python
return result
Then you can pop the layers one at a time, and each time you'll be able to send the request to each of the nodes of this layer in parallel.
If you keep a set of the already selected nodes and the dependencies are also represented as a set the check is more efficient. Other implementations would use event propagations to avoid all those nested loops...
Notice in the worst case you have O(n3), but I only had some thirty components and there are not THAT related :p