I am setting up a branch-and-cut algorithm using the generic callback framework through the C API of CPLEX 12.10.
At each node, the separation problem is based on the current node LP and detects locally valid cuts, that if violated are added for every child node of the current node.
To my understanding, the information of a current node LP is not readily available in the generic callbacks. However, I would like to use cuts generated for a parent node, to generate better cuts in the child nodes.
Is it necessary to do book-keeping about which cuts are generated at all the nodes or can this information somehow be passed on using CPLEX functionality? If the only possibility is to keep track of all generated cuts, how can this book-keeping be made thread-safe, if CPLEX calls the callback from different threads and in different nodes?
There is no way to make CPLEX keep track of this information for you. You have to roll your own.
One way to do this is to implement a dictionary that maps a node's unique id (see CPXCALLBACKINFO_NODEUID) to the information you want to store along with that node. With respect to thread-safety you only have to protect the accesses to that dictionary. To do that, use a lock (pthread_mutex on non-Windows, CRITICAL_SECTION on Windows, for example) and lock and lookup or update operation on that dictionary.
Related
I wrote a script that loads data from 2 tables.
Using this script I need to just match corresponding elements in these 2 columns.
I am using angular-ui-tree for managing columns, but can't come up with an idea how to visually and programmatically match corresponding elements between 2 trees?
Thanks
Not quite sure what is your problem here. I assuming by "matching visually" you do not mean you need some AI API to actually do visual match, so you just want to get objects that are in the same location in the UI tree?
Using $nodeScope (type: Scope of ui-tree-node) should give you that information, as the property of $nodeScope is something like "1.1.1" or "1.1.2" etc. So you can just parse the "parent" node to get all children belonging to same node.
Scope also has a method isParent(nodeScope) which can check if a certain node (that calls the method) is a parent of targeted node. Similarly Scope has isSibling(targetNodeScope) and isChild(targetNodeScope) methods to help you identify the relationships. As a general guide, you just follow the (array) of nodes in a (nested) loop and pick the elements or objects you need. You can pick the objects from both UI trees at the same time, so they should be from the same node at that point.
I am implementing a depth first tree traversal code a large tree. It's single traversal process can span several days because of the long processing time at each node and in between the system might crash or shutdown.
Therefore I want to make the whole process resumable if it the process stops in between for some reason. For that reason I am planning make the whole process backed by persistent datastore which essentially stores the state of the process.
As I figured out that for depth first traversal I will need a Stack type of data structure and which can be realized through a linked list type of array implementation. So my question is if there is some datastore which provides the ability to persist large array to maintain the order of the entities to represent a stack by it. Or if there is some other way through which I can maintain the state of my traversal in a persistent storage.
Thanks.
IMHO: You can implement a custom class of stack behavior using link list. This custom class should be serializable. Storing the state of object intermittently. So even when the system crashes you will loose some data and recreate the complete structure by de-serializing the object from persistent store.
E.g. in Linux driver development one can find the container_of macro. In essence it is the reverse operator to an ->, yielding the pointer to the containing structure if you got a pointer to a member.
Besides from Greg Kroah's blog I found this pattern in the list and hash implementation of Pintos.
The real name of this pattern is "container_of()." Attempting to fit this C-ism into a Java or C++ design pattern taxonomy is futile. The point is not to chain responsibility, or to designate or delegate anything. If you must think in these terms then it's a "messy generalized inheritance." If you don't have to think in these terms then it's a lot less messy.
I'd say it's a not-very featureful Chain Of Responsibility. The only reason you need a pointer back to your parent container structure is to place parent container functionality within reach of the contained elements. As such, it could be seen as an implementation detail required to allow a request to trickle up the "chain" until it gets handled at the correct "level".
With a container / contained relationship, that "correct" level is just one level up, and the trickle up doesn't go through enough levels (since there is only one level) to generate much interest as an ideal example of the pattern. Still, the general ideas behind Chain of Responsibility still hold; a request is made at a point in the chain which cannot handle it, and is handled at a different point in the change which can.
With a small non-generic container / contained relationship, the coupling of this two link chain can get quite tight. For example, your examples lack of a generic "command" handling framework (since the command language set is small), and such a framework generally requires (for type safety) a Command / Message Object. That's a lot of overhead, for a list that just wants to let it's elements directly notify at the element level that they want to be removed from the list.
And yes, there is a C2 pattern's page for it... If you agree with my reasoning.
struct node
{
void *data;
struct node *link;
};
Given such a structure we call it as generic linked list.what is the use of such a list in terms of its real time application use.
It's genericness allows you to create some (tested and reliable) library code around it, which can then be reused.
Of course it's not typesafe this way, that's why C++ introduced (among other things) generic template classes.
As for the use of a linked list per se: you use it where you want to store and retrieve a variable number of similar objects. Typically you don't know the number of the objects in advance and you are fine with getting them in the order you stored them. It's also quite efficient to delete an object from a linked list (once you have a pointer to its list entry).
You have a service which accepts requests from multiple applications and provides handle to each of them. The service can maintain the contexts per request in a linked list and when its done serving them delete the node from the list. A empty linked list in that case would mean no application has registered to the service.
For Eg, Consider the service built over SIP stack and multiple applications like IM, Presence information can register with the service which uses the SIP stack for signalling. Now the service maintains the data pertaining to each of the application in a linked list(well that is again a question of design but lets assume we have a limit to serve 5 applications). The SIP response has to be redirected to the application sending the request and say you hold the callback pointer as one value of the node it is simple to call it once you find the corresponding node for the response.
Each node saves lot of information about every application and uses it for sending back the response to the application.
Probably you may want to have a look at this.
what is the use of such a list in terms of its real time application use
If all you have is that definition and a pointer to the head of the list, then its only good for creating a arbitrary stack of objects. This is because to do anything except add or remove an object to the head of the list you have to iterate through it. Even with this limited "efficiency", such a list has its uses e.g. as a cache for unused heap objects that you are going to recycle to avoid mallocs.
If you also have a pointer to the tail of the list, you can add objects to either end in O(1) time. This means you can use it as a queue.
If each item has a pointer to its predecessor as well as successor, you can also insert/delete items from any point in the list in O(1) time. Of course, you still need to find the object which might involve a linear scan.
I'm interested in using db4o as my persistence mechanism in my Desktop application but I'm concerned about a couple things.
1st concern: Accidentally clipping very complex object graphs.
Say I have a tree with a height of 10 and I fetch the root, how does it handle me storing the root object again?
From my understanding, it doesn't fetch the entire tree it fetches the first 5 referenced layers.
So.. If I make a trivial change to the root and then store it, will it clip away the nodes further down the tree, in essence deleting them.
If not.. how does it handle this?
2nd concern: Extracting subgraphs in a larger object graph
Using my tree example from above... If the database contains 1 massive tree can I query for a single node within it? Since .store was called only once, does my database think it contains only 1 "record"?
Thank you.
You have to be very careful, because two things can happen: you can pull whole db into memory, or just partial graph (rest of objects will be null).
In db4o there's notion of Activator and Update depth, which can be configured upon dbv40 configuration, or when objects are fetched. Its the way you tell db40 how deep you want him to go when fetching referenced objects. Check db4o web site, there's documentation about it:
http://developer.db4o.com/Resources/view.aspx/Reference/Object_Lifecycle/Activation
http://developer.db4o.com/Resources/view.aspx/Reference/Object_Lifecycle/Update_Depth
DB4O's Transparent Activation should resolve most of the fears you've expressed here.