Dip
0.92.4
|
Add a pointer to function member which will allow a client to install their own decision algorithm to decide whether or not to call the CGL generateCuts
method. Create a default decision method that looks at the builtin criteria.
It strikes me as not good that generateCuts contains code specific to individual CGL algorithms. Another set of pointer to function members, so that the client can specify the cut generation method as well as pre- and post-generation methods? Taken a bit further, should this class contain a bunch of pointer to function members, one for each of the places where the cut generator might be referenced? Initialization, root node, search tree node, discovery of solution, and termination all come to mind. Initialization and termination would also be useful for instrumenting sbb.
Add a pointer to function member which will allow a client to install their own decision algorithm to decide whether or not to call the CGL generateCuts
method. Create a default decision method that looks at the builtin criteria.
It strikes me as not good that generateCuts contains code specific to individual CGL algorithms. Another set of pointer to function members, so that the client can specify the cut generation method as well as pre- and post-generation methods? Taken a bit further, should this class contain a bunch of pointer to function members, one for each of the places where the cut generator might be referenced? Initialization, root node, search tree node, discovery of solution, and termination all come to mind. Initialization and termination would also be useful for instrumenting sbb.
Clone a monkey.
Arm wrestle Ted.
Allow use of Alps writeParameters.
Use message handler.
Use differencing scheme.
Setup for parallel.
Add a pointer to function member which will allow a client to install their own decision algorithm to decide whether or not to call the CGL generateCuts
method. Create a default decision method that looks at the builtin criteria.
It strikes me as not good that generateCuts contains code specific to individual CGL algorithms. Another set of pointer to function members, so that the client can specify the cut generation method as well as pre- and post-generation methods? Taken a bit further, should this class contain a bunch of pointer to function members, one for each of the places where the cut generator might be referenced? Initialization, root node, search tree node, discovery of solution, and termination all come to mind. Initialization and termination would also be useful for instrumenting cbc.
Modify this class so that the number of status entries per byte and bytes per status vector allocation unit are not hardcoded. At the least, collect this into a couple of macros.
Consider separate fields for allocated capacity and actual basis size. We could avoid some reallocation, at the price of retaining more space than we need. Perhaps more important, we could do much better sanity checks.
This is a pretty generic structure, and vector diff is a pretty generic activity. We should be able to convert this to a template.
Using unsigned int as the data type for the diff vectors might help to contain the damage when this code is inevitably compiled for 64 bit architectures. But the notion of int as 4 bytes is hardwired into CoinWarmStartBasis, so changes are definitely required.