Todo List

Member SbbBranchingObject::numberBranches () const

The hardwired `2' has to be changed before sbb can do branches with more than two arms.

Member SbbBranchingObject::numberBranchesLeft_

Compare with SbbNodeInfo::numberBranchesLeft_, and check for redundancy.

Class SbbCutGenerator

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.

Class SbbFullNodeInfo

While there's no explicit statement, the code often makes the implicit assumption that an SbbFullNodeInfo structure will appear only at the root node of the search tree. Things will break if this assumption is violated.

Member SbbModel::branchAndBound ()

Normally, it looks like we enter here from command dispatch in the main routine, after calling the solver for an initial solution (SbbModel::initialSolve, which simply calls the solver's initialSolve routine.) The first thing we do is call resolve. Presumably there are circumstances where this is nontrivial? There's also a call from SbbModel::originalModel (tied up with integer presolve), which should be checked.

Member SbbModel::solveWithCuts (OsiCuts &cuts, int numberTries, SbbNode *node, int &numberOldActiveCuts, int &numberNewCuts, int &maximumWhich, int *&whichGenerator)

Why do I need to resolve the problem? What has been done between the last relaxation and calling solveWithCuts?

Looks to me that if numberTries is 0, we'll generate cuts until minimumDrop is triggered (no a priori limit on the number of rounds).

Member SbbModel::integerPresolve (bool weak=false)

It remains to work out the cleanest way of getting a solution to the original problem at the end. So this is very preliminary.

Member SbbModel::findIntegers (bool startAgain)

Note the assumption in sbb that the first numberIntegers_ objects are SbbSimpleInteger. In particular, the code which handles the startAgain case assumes that if the object_ array exists it can simply replace the first numberInteger_ objects. This is arguably unsafe.

Member SbbModel::addCuts1 (SbbNode *node, CoinWarmStartBasis *&lastws)

addCuts1() is called in contexts where it's known in advance that all that's desired is to determine a list of cuts and do the bookkeeping (adjust the reference counts). The work of installing bounds and building a basis goes to waste.

Member SbbNodeInfo::numberBranchesLeft_

There seems to be redundancy between this field and SbbBranchingObject::numberBranchesLeft_. It'd be good to sort out if both are necessary.

Class SbbObject

The notion that all branches are binary (two arms) is wired into the implementation of SbbObject, SbbBranchingObject, and SbbBranchDecision. Changing this will require a moderate amount of recoding.

---