Changeset 1364


Ignore:
Timestamp:
Dec 5, 2009 10:54:48 AM (4 years ago)
Author:
EdwinStraver
Message:

Added comments from Lou

Location:
branches/sandbox/Cbc/src
Files:
7 edited

Legend:

Unmodified
Added
Removed

  • branches/sandbox/Cbc/src/CbcBranchDecision.hpp

    r1357 r1364  
    9090    /* If chooseMethod_ id non-null then the rest is fairly pointless 
    9191       as choosemethod_ will be doing all work 
    92     */ 
     92     This comment makes more sense if you realise that there's a conversion in 
     93     process from the Cbc branching classes to Osi branching classes. The test 
     94     for use of the Osi branching classes is CbcModel::branchingMethod_ 
     95     non-null (i.e., it points to one of these CbcBranchDecision objects) and 
     96     that branch decision object has an OsiChooseVariable method set. In which 
     97     case, we'll use it, rather than the choose[*]Variable methods defined in 
     98     CbcNode. 
     99        */ 
     100 
    93101    OsiChooseVariable * chooseMethod() const { 
    94102        return chooseMethod_; 

  • branches/sandbox/Cbc/src/CbcFathom.hpp

    r1286 r1364  
    55#define CbcFathom_H 
    66#include "CbcConfig.h" 
     7 
     8/* 
     9  This file contains two classes, CbcFathom and CbcOsiSolver. It's unclear why 
     10  they're in the same file. CbcOsiSolver is a base class for CbcLinked. 
     11 
     12  --lh, 071031 -- 
     13*/ 
     14 
    715 
    816class CbcModel; 
    … …  
    7482 
    7583This is for codes where solver needs to know about CbcModel 
     84  Seems to provide only one value-added feature, a CbcModel object. 
     85 
    7686*/ 
    7787 

  • branches/sandbox/Cbc/src/CbcHeuristicFPump.cpp

    r1286 r1364  
    221221    char pumpPrint[LEN_PRINT]; 
    222222    pumpPrint[0] = '\0'; 
     223/* 
     224  Decide if we want to run. Standard values for when are described in 
     225  CbcHeuristic.hpp. If we're off, or running only at root and this isn't the 
     226  root, bail out. 
     227 
     228  The double test (against phase, then atRoot and passNumber) has a fair bit 
     229  of redundancy, but the results will differ depending on whether we're 
     230  actually at the root of the main search tree or at the root of a small tree 
     231  (recursive call to branchAndBound). 
     232 
     233  FPump also supports some exotic values (11 -- 15) for when, described in 
     234  CbcHeuristicFPump.hpp. 
     235*/ 
    223236    if (!when() || (when() == 1 && model_->phase() != 1)) 
    224237        return 0; // switched off 
    … …  
    283296    int numberIterationsLastPass = 0; 
    284297    // 1. initially check 0-1 
     298/* 
     299  I'm skeptical of the above comment, but it's likely accurate as the default. 
     300  Bit 4 or bit 8 needs to be set in order to consider working with general 
     301  integers. 
     302*/ 
    285303    int i, j; 
    286304    int general = 0; 
    … …  
    290308    bool doGeneral = (accumulate_ & 4) != 0; 
    291309    j = 0; 
     310/* 
     311  Scan the objects, recording the columns and counting general integers. 
     312 
     313  Seems like the NDEBUG tests could be made into an applicability test. If 
     314  a scan of the objects reveals complex objects, just clean up and return 
     315  failure. 
     316*/ 
    292317    for (i = 0; i < numberIntegers; i++) { 
    293318        int iColumn = integerVariableOrig[i]; 
    … …  
    308333        } 
    309334    } 
     335/* 
     336  If 2/3 of integers are general integers, and we're not going to work with 
     337  them, might as well go home. 
     338 
     339  The else case is unclear to me. We reach it if general integers are less than 
     340  2/3 of the total, or if either of bit 4 or 8 is set. But only bit 8 is used 
     341  in the decision. (Let manyGen = 1 if more than 2/3 of integers are general 
     342  integers. Then a k-map on manyGen, bit4, and bit8 shows it clearly.) 
     343 
     344  So there's something odd here. In the case where bit4 = 1 and bit8 = 0, 
     345  we've included general integers in integerVariable, but we're not going to 
     346  process them. 
     347*/ 
    310348    if (general*3 > 2*numberIntegers && !doGeneral) { 
    311349        delete [] integerVariable; 
    … …  
    326364        printf("DOing general with %d out of %d\n", general, numberIntegers); 
    327365#endif 
     366/* 
     367  This `closest solution' will satisfy integrality, but violate some other 
     368  constraints? 
     369*/ 
    328370    // For solution closest to feasible if none found 
    329371    int * closestSolution = general ? NULL : new int[numberIntegers]; 
    … …  
    345387    } 
    346388    double time1 = CoinCpuTime(); 
     389/* 
     390  Obtain a relaxed lp solution. 
     391*/ 
    347392    model_->solver()->resolve(); 
    348393    if (!model_->solver()->isProvenOptimal()) { 
    … …  
    363408        } 
    364409    } 
     410/* 
     411  I have no idea why we're doing this, except perhaps that saveBasis will be 
     412  automagically deleted on exit from the routine. 
     413*/ 
    365414    CoinWarmStartBasis saveBasis; 
    366415    CoinWarmStartBasis * basis = 
    … …  
    638687        // 5. MAIN WHILE LOOP 
    639688        //bool newLineNeeded=false; 
     689/* 
     690  finished occurs exactly twice in this routine: immediately above, where it's 
     691  set to false, and here in the loop condition. 
     692*/ 
    640693        while (!finished) { 
    641694            double newTrueSolutionValue = 0.0; 
    … …  
    19652018        } 
    19662019    } 
     2020/* 
     2021  End of the `exitAll' loop. 
     2022*/ 
    19672023#ifdef RAND_RAND 
    19682024    delete [] randomFactor; 

  • branches/sandbox/Cbc/src/CbcHeuristicFPump.hpp

    r1286 r1364  
    5555          14 - also fix all continuous variables staying at same internal value throughout 
    5656          15 - as 13 but no internal integers 
     57      And beyond that, it's apparently possible for the range to be between 21 
     58      and 25, in which case it's reduced on entry to solution() to be between 
     59      11 and 15 and allSlack is set to true. Then, if we're not processing 
     60      general integers, we'll use an all-slack basis to solve ... what? Don't 
     61      see that yet. 
    5762    */ 
    5863    virtual int solution(double & objectiveValue, 
    … …  
    151156         3 - reuse solves, accumulate integer solutions for local search 
    152157         If we add 4 then use second form of problem (with extra rows and variables for general integers) 
     158       At some point (date?), I added 
     159 
     160       And then there are a few bit fields: 
     161       4 - something about general integers 
     162       So my (lh) guess for 4 was at least in the ballpark, but I'll have to 
     163       rethink 8 entirely (and it may well not mean the same thing as it did 
     164       when I added that comment. 
     165       8 - determines whether we process general integers 
     166 
     167       And on 090831, John added 
     168 
     169       If we add 4 then use second form of problem (with extra rows and 
     170       variables for general integers) 
    153171         If we add 8 then can run after initial cuts (if no solution) 
    154172    */ 

  • branches/sandbox/Cbc/src/CbcHeuristicLocal.cpp

    r1359 r1364  
    122122    } 
    123123} 
     124/* 
     125  Run a mini-BaB search after fixing all variables not marked as used by 
     126  solution(). (See comments there for semantics.) 
     127 
     128  Return values are: 
     129    1: smallBranchAndBound found a solution 
     130    0: everything else 
     131 
     132  The degree of overload as return codes from smallBranchAndBound are folded 
     133  into 0 is such that it's impossible to distinguish return codes that really 
     134  require attention from a simple `nothing of interest'. 
     135*/ 
    124136// This version fixes stuff and does IP 
    125137int 
    … …  
    128140                               const int * /*keep*/) 
    129141{ 
     142/* 
     143  If when is set to off (0), or set to root (1) and we're not at the root, 
     144  return. If this heuristic discovered the current solution, don't continue. 
     145*/ 
     146 
    130147    numCouldRun_++; 
    131148    // See if to do 
    … …  
    135152    if (this == model_->lastHeuristic()) 
    136153        return 0; 
     154/* 
     155  Load up a new solver with the solution. 
     156 
     157  Why continuousSolver(), as opposed to solver()? 
     158*/ 
    137159    OsiSolverInterface * newSolver = model_->continuousSolver()->clone(); 
    138160    const double * colLower = newSolver->getColLower(); 
    … …  
    141163    int numberIntegers = model_->numberIntegers(); 
    142164    const int * integerVariable = model_->integerVariable(); 
     165/* 
     166  The net effect here is that anything that hasn't moved from its lower bound 
     167  will be fixed at lower bound. 
     168 
     169  See comments in solution() w.r.t. asymmetric treatment of upper and lower 
     170  bounds. 
     171*/ 
    143172 
    144173    int i; 
    … …  
    157186        } 
    158187    } 
     188/* 
     189  Try a `small' branch-and-bound search. The notion here is that we've fixed a 
     190  lot of variables and reduced the amount of `free' problem to a point where a 
     191  small BaB search will suffice to fully explore the remaining problem. This 
     192  routine will execute integer presolve, then call branchAndBound to do the 
     193  actual search. 
     194*/ 
    159195    int returnCode = 0; 
    160196#ifdef CLP_INVESTIGATE2 
    … …  
    198234        returnCode = smallBranchAndBound(newSolver, numberNodes_, newSolution, objectiveValue, 
    199235                                         objectiveValue, "CbcHeuristicLocal"); 
    200         if (returnCode < 0) { 
     236 /* 
     237  -2 is return due to user event, and -1 is overloaded with what look to be 
     238  two contradictory meanings. 
     239*/ 
     240       if (returnCode < 0) { 
    201241            returnCode = 0; // returned on size 
    202242            int numberColumns = newSolver->getNumCols(); 
    … …  
    262302        } 
    263303    } 
     304/* 
     305  If the result is complete exploration with a solution (3) or proven 
     306  infeasibility (2), we could generate a cut (the AI folks would call it a 
     307  nogood) to prevent us from going down this route in the future. 
     308*/ 
    264309    if ((returnCode&2) != 0) { 
    265310        // could add cut 
    … …  
    273318  First tries setting a variable to better value.  If feasible then 
    274319  tries setting others.  If not feasible then tries swaps 
    275   Returns 1 if solution, 0 if not */ 
     320  Returns 1 if solution, 0 if not  
     321  The main body of this routine implements an O((q^2)/2) brute force search 
     322  around the current solution, for q = number of integer variables. Call this 
     323  the inc/dec heuristic.  For each integer variable x<i>, first decrement the 
     324  value. Then, for integer variables x<i+1>, ..., x<q-1>, try increment and 
     325  decrement. If one of these permutations produces a better solution, 
     326  remember it.  Then repeat, with x<i> incremented. If we find a better 
     327  solution, update our notion of current solution and continue. 
     328 
     329  The net effect is a greedy walk: As each improving pair is found, the 
     330  current solution is updated and the search continues from this updated 
     331  solution. 
     332 
     333  Way down at the end, we call solutionFix, which will create a drastically 
     334  restricted problem based on variables marked as used, then do mini-BaC on 
     335  the restricted problem. This can occur even if we don't try the inc/dec 
     336  heuristic. This would be more obvious if the inc/dec heuristic were broken 
     337  out as a separate routine and solutionFix had a name that reflected where 
     338  it was headed. 
     339 
     340  The return code of 0 is grossly overloaded, because it maps to a return 
     341  code of 0 from solutionFix, which is itself grossly overloaded. See 
     342  comments in solutionFix and in CbcHeuristic::smallBranchAndBound. 
     343  */ 
    276344int 
    277345CbcHeuristicLocal::solution(double & solutionValue, 
    278346                            double * betterSolution) 
    279347{ 
     348/* 
     349  Execute only if a new solution has been discovered since the last time we 
     350  were called. 
     351*/ 
    280352 
    281353    numCouldRun_++; 
    … …  
    283355        return 0; 
    284356    numberSolutions_ = model_->getSolutionCount(); 
     357/* 
     358  Exclude long (column), thin (row) systems. 
     359 
     360  Given the n^2 nature of the search, more than 100,000 columns could get 
     361  expensive. But I don't yet see the rationale for the second part of the 
     362  condition (cols > 10*rows). And cost is proportional to number of integer 
     363  variables --- shouldn't we use that? 
     364 
     365  Why wait until we have more than one solution? 
     366*/ 
    285367    if ((model_->getNumCols() > 100000 && model_->getNumCols() > 
    286368            10*model_->getNumRows()) || numberSolutions_ <= 1) 
    … …  
    292374    const double * rowUpper = solver->getRowUpper(); 
    293375    const double * solution = model_->bestSolution(); 
     376/* 
     377  Shouldn't this test be redundant if we've already checked that 
     378  numberSolutions_ > 1? Stronger: shouldn't this be an assertion? 
     379*/ 
    294380    if (!solution) 
    295381        return 0; // No solution found yet 
    … …  
    338424    // space to save values so we don't introduce rounding errors 
    339425    double * save = new double[numberRows]; 
     426/* 
     427  Force variables within their original bounds, then to the nearest integer. 
     428  Overall, we seem to be prepared to cope with noninteger bounds. Is this 
     429  necessary? Seems like we'd be better off to force the bounds to integrality 
     430  as part of preprocessing.  More generally, why do we need to do this? This 
     431  solution should have been cleaned and checked when it was accepted as a 
     432  solution! 
     433 
     434  Once the value is set, decide whether we can move up or down. 
     435 
     436  The only place that used_ is used is in solutionFix; if a variable is not 
     437  flagged as used, it will be fixed (at lower bound). Why the asymmetric 
     438  treatment? This makes some sense for binary variables (for which there are 
     439  only two options). But for general integer variables, why not make a similar 
     440  test against the original upper bound? 
     441*/ 
    340442 
    341443    // clean solution 
    … …  
    364466        } 
    365467        cost[i] = direction * objective[iColumn]; 
     468/* 
     469  Given previous computation we're checking that value is at least 1 away 
     470  from the original bounds. 
     471*/ 
    366472        int iway = 0; 
    367473 
    … …  
    372478        way[i] = static_cast<char>(iway); 
    373479    } 
     480/* 
     481  Calculate lhs of each constraint for groomed solution. 
     482*/ 
    374483    // get row activities 
    375484    double * rowActivity = new double[numberRows]; 
    … …  
    387496        } 
    388497    } 
     498/* 
     499  Check that constraints are satisfied. For small infeasibility, force the 
     500  activity within bound. Again, why is this necessary if the current solution 
     501  was accepted as a valid solution? 
     502 
     503  Why are we scanning past the first unacceptable constraint? 
     504*/ 
    389505    // check was feasible - if not adjust (cleaning may move) 
    390506    // if very infeasible then give up 
    … …  
    401517        } 
    402518    } 
     519/* 
     520  This bit of code is not quite totally redundant: it'll bail at 10,000 
     521  instead of 100,000. Potentially we can do a lot of work to get here, only 
     522  to abandon it. 
     523*/ 
    403524    // Switch off if may take too long 
    404525    if (model_->getNumCols() > 10000 && model_->getNumCols() > 
    405526            10*model_->getNumRows()) 
    406527        tryHeuristic = false; 
     528/* 
     529  Try the inc/dec heuristic? 
     530*/ 
    407531    if (tryHeuristic) { 
    408532 
    409533        // best change in objective 
    410534        double bestChange = 0.0; 
     535/* 
     536  Outer loop to walk integer variables. Call the current variable x<i>. At the 
     537  end of this loop, bestChange will contain the best (negative) change in the 
     538  objective for any single pair. 
     539 
     540  The trouble is, we're limited to monotonically increasing improvement. 
     541  Suppose we discover an improvement of 10 for some pair. If, later in the 
     542  search, we discover an improvement of 9 for some other pair, we will not use 
     543  it. That seems wasteful. 
     544*/ 
    411545 
    412546        for (i = 0; i < numberIntegers; i++) { 
    … …  
    418552            int goodK = -1; 
    419553            int wayK = -1, wayI = -1; 
     554/* 
     555  Try decrementing x<i>. 
     556*/ 
    420557            if ((way[i]&1) != 0) { 
    421558                int numberInfeasible = 0; 
     559/* 
     560  Adjust row activities where x<i> has a nonzero coefficient. Save the old 
     561  values for restoration. Mark any rows that become infeasible as a result 
     562  of the decrement. 
     563*/ 
    422564                // save row activities and adjust 
    423565                for (j = columnStart[iColumn]; 
    … …  
    433575                    } 
    434576                } 
    435                 // try down 
     577  /* 
     578  Run through the remaining integer variables. Try increment and decrement on 
     579  each one. If the potential objective change is better than anything we've 
     580  seen so far, do a full evaluation of x<k> in that direction.  If we can 
     581  repair all infeasibilities introduced by pushing x<i> down, we have a 
     582  winner. Remember the best variable, and the direction for x<i> and x<k>. 
     583*/ 
     584              // try down 
    436585                for (k = i + 1; k < numberIntegers; k++) { 
    437586                    if ((way[k]&1) != 0) { 
    … …  
    494643                    } 
    495644                } 
     645/* 
     646  Remove effect of decrementing x<i> by restoring original lhs values. 
     647*/ 
    496648                // restore row activities 
    497649                for (j = columnStart[iColumn]; 
    … …  
    502654                } 
    503655            } 
     656/* 
     657  Try to increment x<i>. Actions as for decrement. 
     658*/ 
    504659            if ((way[i]&2) != 0) { 
    505660                int numberInfeasible = 0; 
    … …  
    586741                } 
    587742            } 
     743/* 
     744  We've found a pair x<i> and x<k> which produce a better solution. Update our 
     745  notion of current solution to match. 
     746 
     747  Why does this not update newSolutionValue? 
     748*/ 
    588749            if (goodK >= 0) { 
    589750                // we found something - update solution 
    … …  
    601762                } 
    602763                newSolution[kColumn] += wayK; 
    603                 // See if k can go further ? 
     764/* 
     765  Adjust motion range for x<k>. We may have banged up against a bound with that 
     766  last move. 
     767*/ 
     768               // See if k can go further ? 
    604769                const OsiObject * object = model_->object(goodK); 
    605770                // get original bounds 
    … …  
    618783            } 
    619784        } 
     785/* 
     786  End of loop to try increment/decrement of integer variables. 
     787 
     788  newSolutionValue does not necessarily match the current newSolution, and 
     789  bestChange simply reflects the best single change. Still, that's sufficient 
     790  to indicate that there's been at least one change. Check that we really do 
     791  have a valid solution. 
     792*/ 
    620793        if (bestChange + newSolutionValue < solutionValue) { 
    621794            // paranoid check 
    … …  
    662835                    } 
    663836                } 
     837/* 
     838  Copy the solution to the array returned to the client. Grab a basis from 
     839  the solver (which, if it exists, is almost certainly infeasible, but it 
     840  should be ok for a dual start). The value returned as solutionValue is 
     841  conservative because of handling of newSolutionValue and bestChange, as 
     842  described above. 
     843*/ 
    664844                // new solution 
    665845                memcpy(betterSolution, newSolution, numberColumns*sizeof(double)); 
    … …  
    679859        } 
    680860    } 
     861/* 
     862  We're done. Clean up. 
     863*/ 
    681864    delete [] newSolution; 
    682865    delete [] rowActivity; 
    … …  
    685868    delete [] save; 
    686869    delete [] mark; 
     870/* 
     871  Do we want to try swapping values between solutions? 
     872  swap_ is set elsewhere; it's not adjusted during heuristic execution. 
     873 
     874  Again, redundant test. We shouldn't be here if numberSolutions_ = 1. 
     875*/ 
    687876    if (numberSolutions_ > 1 && swap_ == 1) { 
    688877        // try merge 

  • branches/sandbox/Cbc/src/CbcMain.cpp

    r1286 r1364  
    22// copyright (C) 2002, International Business Machines 
    33// Corporation and others.  All Rights Reserved. 
     4 
     5/*! \file CbcMain.cpp 
     6    \brief Obsolete main routine for stand-alone cbc. 
     7 
     8    Unused since at least 2006. JJF forked off a clp-specific version, which 
     9    evolved into CoinSolve and CbcSolver. LH changed to a completely different 
     10    structure for CbcGeneric. 
     11*/ 
    412 
    513#include "CbcConfig.h" 

  • branches/sandbox/Cbc/src/CbcModel.cpp

    r1357 r1364  
    16521652    bool noObjects = (numberObjects_ == 0); 
    16531653    // Set up strategies 
     1654/* 
     1655  See if the user has supplied a strategy object and deal with it if present. 
     1656  The call to setupOther will set numberStrong_ and numberBeforeTrust_, and 
     1657  perform integer preprocessing, if requested. 
     1658 
     1659  We need to hang on to a pointer to solver_. setupOther will assign a 
     1660  preprocessed solver to model, but will instruct assignSolver not to trash the 
     1661  existing one. 
     1662*/ 
    16541663    if (strategy_) { 
    16551664        // May do preprocessing 
    … …  
    20202029        return ; 
    20212030    } 
     2031/* 
     2032  See if we're using the Osi side of the branching hierarchy. If so, either 
     2033  convert existing CbcObjects to OsiObjects, or generate them fresh. In the 
     2034  first case, CbcModel owns the objects on the object_ list. In the second 
     2035  case, the solver holds the objects and object_ simply points to the 
     2036  solver's list. 
     2037 
     2038  080417 The conversion code here (the block protected by `if (obj)') cannot 
     2039  possibly be correct. On the Osi side, descent is OsiObject -> OsiObject2 -> 
     2040  all other Osi object classes. On the Cbc side, it's OsiObject -> CbcObject 
     2041  -> all other Cbc object classes. It's structurally impossible for any Osi 
     2042  object to descend from CbcObject. The only thing I can see is that this is 
     2043  really dead code, and object detection is now handled from the Osi side. 
     2044*/ 
    20222045    // Convert to Osi if wanted 
    20232046    bool useOsiBranching = false; 
    … …  
    20682091            //} 
    20692092        } else { 
     2093/* 
     2094  As of 080104, findIntegersAndSOS is misleading --- the default OSI 
     2095  implementation finds only integers. 
     2096*/ 
    20702097            // do from solver 
    20712098            deleteObjects(false); 
    … …  
    22632290    double * upperBefore = new double [numberColumns] ; 
    22642291    /* 
     2292  Set up to run heuristics and generate cuts at the root node. The heavy 
     2293  lifting is hidden inside the calls to doHeuristicsAtRoot and solveWithCuts. 
     2294 
     2295  To start, tell cut generators they can be a bit more aggressive at the 
     2296  root node. 
     2297 
     2298  QUESTION: phase_ = 0 is documented as `initial solve', phase = 1 as `solve 
     2299            with cuts at root'. Is phase_ = 1 the correct indication when 
     2300            doHeurisiticsAtRoot is called to run heuristics outside of the main 
     2301            cut / heurisitc / reoptimise loop in solveWithCuts? 
    22652302 
    22662303      Generate cuts at the root node and reoptimise. solveWithCuts does the heavy 
    … …  
    23452382        } 
    23462383    } 
     2384/* 
     2385  Run heuristics at the root. This is the only opportunity to run FPump; it 
     2386  will be removed from the heuristics list by doHeuristicsAtRoot. 
     2387*/ 
    23472388    // Do heuristics 
    23482389    doHeuristicsAtRoot(); 
     2390/* 
     2391  Grepping through the code, it would appear that this is a command line 
     2392  debugging hook.  There's no obvious place in the code where this is set to 
     2393  a negative value. 
     2394*/ 
    23492395    if ( intParam_[CbcMaxNumNode] < 0) 
    23502396        eventHappened_ = true; // stop as fast as possible 
    … …  
    23612407        //eventHappened_=true; // stop as fast as possible 
    23622408    } 
     2409/* 
     2410  Set up for statistics collection, if requested. Standard values are 
     2411  documented in CbcModel.hpp. The magic number 100 will trigger a dump of 
     2412  CbcSimpleIntegerDynamicPseudoCost objects (no others). Looks like another 
     2413  command line debugging hook. 
     2414*/ 
    23632415    statistics_ = NULL; 
    23642416    // Do on switch 
    … …  
    23712423    if (noObjects && numberIntegers_ < solver_->getNumCols() && (specialOptions_&65536) != 0 && !parentModel_) 
    23722424        AddIntegers(); 
    2373  
     2425/* 
     2426  Do an initial round of cut generation for the root node. Depending on the 
     2427  type of underlying solver, we may want to do this even if the initial query 
     2428  to the objects indicates they're satisfied. 
     2429 
     2430  solveWithCuts does the heavy lifting. It will iterate a generate/reoptimise 
     2431  loop (including reduced cost fixing) until no cuts are generated, the 
     2432  change in objective falls off,  or the limit on the number of rounds of cut 
     2433  generation is exceeded. 
     2434 
     2435  At the end of all this, any cuts will be recorded in cuts and also 
     2436  installed in the solver's constraint system. We'll have reoptimised, and 
     2437  removed any slack cuts (numberOldActiveCuts_ and numberNewCuts_ have been 
     2438  adjusted accordingly). 
     2439*/ 
    23742440    int iObject ; 
    23752441    int preferredWay ; 
    … …  
    69006966    //solver_->writeMps("saved"); 
    69016967#ifdef CBC_THREAD 
     6968/* 
     6969  Thread mode makes a difference here only when it specifies using separate 
     6970  threads to generate cuts at the root (bit 2^1 set in threadMode_). In which 
     6971  case we'll create an array of empty CbcModels (!). Solvers will be cloned 
     6972  later. 
     6973*/ 
    69026974    CbcModel ** threadModel = NULL; 
    69036975    Coin_pthread_t * threadId = NULL; 
    … …  
    69667038            onOptimalPath = (debugger->onOptimalPath(*solver_)) ; 
    69677039    } 
     7040/* 
     7041  As the final action in each round of cut generation (the numberTries loop), 
     7042  we'll call takeOffCuts to remove slack cuts. These are saved into slackCuts 
     7043  and rechecked immediately after the cut generation phase of the loop. 
     7044*/ 
    69687045    OsiCuts slackCuts; 
    69697046    /* 
    6970       Resolve the problem. If we've lost feasibility, might as well bail out right 
     7047    lh: 
     7048          Resolve the problem 
     7049 
     7050  The resolve will also refresh cached copies of the solver solution 
     7051  (cbcColLower_, ...) held by CbcModel. 
     7052  This resolve looks like the best point to capture a warm start for use in 
     7053  the case where cut generation proves ineffective and we need to back out 
     7054  a few tight cuts. 
     7055  I've always maintained that this resolve is unnecessary. Let's put in a hook 
     7056  to report if it's every nontrivial. -lh 
     7057 
     7058        Resolve the problem. If we've lost feasibility, might as well bail out right 
    69717059      after the debug stuff. The resolve will also refresh cached copies of the 
    69727060      solver solution (cbcColLower_, ...) held by CbcModel. 
    … …  
    69847072    cut_obj[CUT_HISTORY-1] = lastObjective; 
    69857073    //double firstObjective = lastObjective+1.0e-8+1.0e-12*fabs(lastObjective); 
     7074/* 
     7075  Contemplate the result of the resolve. 
     7076    - CbcModel::resolve() has a hook that calls CbcStrategy::status to look 
     7077      over the solution. The net result is that resolve can return 
     7078      0 (infeasible), 1 (feasible), or -1 (feasible, but do no further work). 
     7079    - CbcFeasbililityBase::feasible() can return 0 (no comment), 
     7080      1 (pretend this is an integer solution), or -1 (pretend this is 
     7081      infeasible). As of 080104, this seems to be a stub to allow overrides, 
     7082      with a default implementation that always returns 0. 
     7083 
     7084  Setting numberTries = 0 for `do no more work' is problematic. The main cut 
     7085  generation loop will still execute once, so we do not observe the `no 
     7086  further work' semantics. 
     7087 
     7088  As best I can see, allBranchesGone is a null function as of 071220. 
     7089*/ 
    69867090    if (node && node->nodeInfo() && !node->nodeInfo()->numberBranchesLeft()) 
    69877091        node->nodeInfo()->allBranchesGone(); // can clean up 
    … …  
    69927096        feasible = false; // pretend infeasible 
    69937097    } 
     7098/* 
     7099  NEW_UPDATE_OBJECT is defined to 0 when unthreaded (CBC_THREAD undefined), 2 
     7100  when threaded. No sign of 1 as of 071220. 
     7101 
     7102  At present, there are two sets of hierarchies for branching classes. Call 
     7103  them CbcHier and OsiHier. For example, we have OsiBranchingObject, with 
     7104  children CbcBranchingObject and OsiTwoWayBranchingObject. All 
     7105  specialisations descend from one of these two children. Similarly, there is 
     7106  OsiObject, with children CbcObject and OsiObject2. 
     7107 
     7108  In the original setup, there's a single CbcBranchDecision object attached 
     7109  to CbcModel (branchingMethod_). It has a field to hold the current CbcHier 
     7110  branching object, and the updateInformation routine reaches through the 
     7111  branching object to update the underlying CbcHier object. 
     7112 
     7113  NEW_UPDATE_OBJECT = 0 would seem to assume the original setup. But, 
     7114  if we're using the OSI hierarchy for objects and branching, a call to a 
     7115  nontrivial branchingMethod_->updateInformation would have no effect (it 
     7116  would expect a CbcObject to work on) or perhaps crash.  For the 
     7117  default CbcBranchDefaultDecision, updateInformation is a noop (actually 
     7118  defined in the base CbcBranchDecision class). 
     7119 
     7120  NEW_UPDATE_OBJECT = 2 looks like it's prepared to cope with either CbcHier or 
     7121  OsiHier, but it'll be executed only when threads are activated. See the 
     7122  comments below. The setup is scary. 
     7123 
     7124  But ... if the OsiHier update actually reaches right through to the object 
     7125  list in the solver, it should work just fine in unthreaded mode. It would 
     7126  seem that the appropriate thing to do in unthreaded mode would be to choose 
     7127  between the existing code for NEW_UPDATE_OBJECT = 0 and the OsiHier code for 
     7128  NEW_UPDATE_OBJECT = 2. But I'm going to let John hash that out. The worst 
     7129  that can happen is inefficiency because I'm not properly updating an object. 
     7130*/ 
    69947131 
    69957132    // Update branching information if wanted 
    … …  
    73077444 
    73087445          The need to resolve here should only happen after a heuristic solution. 
     7446  optimalBasisIsAvailable resolves to basisIsAvailable, which seems to be part 
     7447  of the old OsiSimplex API. Doc'n says `Returns true if a basis is available 
     7448  and the problem is optimal. Should be used to see if the BinvARow type 
     7449  operations are possible and meaningful.' Which means any solver other the clp 
     7450  is probably doing a lot of unnecessary resolves right here. 
    73097451          (Note default OSI implementation of optimalBasisIsAvailable always returns 
    73107452          false.) 
    … …  
    73677509        //probingInfo_->initializeFixing(); 
    73687510        int i; 
     7511/* 
     7512  threadMode with bit 2^1 set indicates we should use threads for root cut 
     7513  generation. 
     7514*/ 
    73697515        if ((threadMode_&2) == 0 || numberNodes_) { 
    73707516# ifdef COIN_HAS_CLP 
    … …  
    75677713                } 
    75687714            } 
     7715/* 
     7716  End of loop to run each cut generator. 
     7717*/ 
    75697718            if (!node) { 
    75707719                handler_->message(CBC_ROOT_DETAIL, messages_) 
    … …  
    83758524        } 
    83768525    } while (numberTries > 0 || keepGoing) ; 
     8526/* 
     8527  End cut generation loop. 
     8528*/ 
    83778529    { 
    83788530        // switch on 
    … …  
    84488600    } 
    84498601    /* 
     8602  End of code block to check for a solution, when cuts may be added as a result 
     8603  of a feasible solution. 
     8604 
    84508605      Reduced cost fix at end. Must also check feasible, in case we've popped out 
    84518606      because a generator indicated we're infeasible. 
    … …  
    85218676    //printf("XXb sum obj changed by %g\n",sumChangeObjective2_); 
    85228677    /* 
     8678        lh: 
     8679          Is this a full scan interval? If so, consider if we want to disable or 
     8680  adjust the frequency of use for any of the cut generators. If the client 
     8681  specified a positive number for howOften, it will never change. If the 
     8682  original value was negative, it'll be converted to 1000000+|howOften|, and 
     8683  this value will be adjusted each time fullScan is true. Actual cut 
     8684  generation is performed every howOften%1000000 nodes; the 1000000 offset is 
     8685  just a convenient way to specify that the frequency is adjustable. 
     8686-lh 
    85238687      End of cut generation loop. 
    85248688 
    … …  
    85378701      TODO: All this should probably be hidden in a method of the CbcCutGenerator 
    85388702      class. 
    8539  
     8703lh: 
     8704  TODO: Can the loop that scans over whichGenerator to accumulate per 
     8705        generator counts be replaced by values in countRowCuts and 
     8706        countColumnCuts? 
     8707 
     8708        << I think the answer is yes, but not the other way 'round. Row and 
     8709           column cuts are block interleaved in whichGenerator. >> 
     8710 
     8711  The root is automatically a full scan interval. At the root, decide if 
     8712  we're going to do cuts in the tree, and whether we should keep the cuts we 
     8713  have. 
     8714 
     8715  Codes for willBeCutsInTree: 
     8716    -1: no cuts in tree and currently active cuts seem ineffective; delete 
     8717        them 
     8718     0: no cuts in tree but currently active cuts seem effective; make them 
     8719        into architecturals (faster than treating them as cuts) 
     8720     1: cuts will be generated in the tree; currently active cuts remain as 
     8721        cuts 
     8722-lh 
    85408723    */ 
    85418724#ifdef NODE_LOG 
    … …  
    85578740        double densityNew = numberRowsAdded ? (static_cast<double> (numberElementsAdded)) / static_cast<double> (numberRowsAdded) 
    85588741                            : 0.0; 
     8742/* 
     8743  If we're at the root, and we added cuts, and the cuts haven't changed the 
     8744  objective, and the cuts resulted in a significant increase (> 20%) in nonzero 
     8745  coefficients, do no cuts in the tree and ditch the current cuts. They're not 
     8746  cost-effective. 
     8747*/ 
    85598748        if (!numberNodes_) { 
    85608749            if (numberRowsAdded) 
    … …  
    86738862            } 
    86748863        } 
     8864/* 
     8865  Noop block 071219. 
     8866*/ 
    86758867        if ((numberRowsAdded > 100 + 0.5*numberRowsAtStart 
    86768868                || numberElementsAdded > 0.5*numberElementsAtStart) 
    … …  
    86828874            //     numberRowsAdded,densityNew); 
    86838875        } 
     8876/* 
     8877  Noop block 071219. 
     8878*/ 
    86848879        if (densityNew > 100.0 && numberRowsAdded > 2 && densityNew > 2.0*densityOld) { 
    86858880            //if (thisObjective-startObjective<0.1*fabs(startObjective)+1.0e-5) 
    … …  
    86898884        } 
    86908885        // Root node or every so often - see what to turn off 
     8886/* 
     8887  Hmmm ... > -90 for any generator will overrule previous decision to do no 
     8888  cuts in tree and delete existing cuts. 
     8889*/ 
    86918890        int i ; 
    86928891        for (i = 0; i < numberCutGenerators_; i++) { 
    … …  
    87018900            << currentPassNumber_ 
    87028901            << CoinMessageEol ; 
     8902/* 
     8903  Count the number of cuts produced by each cut generator on this call. Not 
     8904  clear to me that the accounting is equivalent here. whichGenerator_ records 
     8905  the generator for column and row cuts. So unless numberNewCuts is row cuts 
     8906  only, we're double counting for JUST_ACTIVE. Note too the multiplier applied 
     8907  to column cuts. 
     8908*/ 
    87038909        if (!numberNodes_) { 
    87048910            double value = CoinMax(minimumDrop_, 0.005 * (thisObjective - startObjective) / 
    … …  
    87318937            totalCuts += value; 
    87328938        } 
     8939/* 
     8940  Open up a loop to step through the cut generators and decide what (if any) 
     8941  adjustment should be made for calling frequency. 
     8942*/ 
    87338943        int iProbing = -1; 
    87348944        double smallProblem = (0.2 * totalCuts) / 
    … …  
    87378947            int howOften = generator_[i]->howOften() ; 
    87388948            /*  Probing can be set to just do column cuts in treee. 
    8739             But if doing good then leave as on */ 
     8949            But if doing good then leave as on 
     8950  Ok, let me try to explain this. rowCuts = 3 says do disaggregation (1<<0) and 
     8951  coefficient (1<<1) cuts. But if the value is negative, there's code at the 
     8952  entry to generateCuts, and generateCutsAndModify, that temporarily changes 
     8953  the value to 4 (1<<2) if we're in a search tree. 
     8954 
     8955  Which does nothing to explain this next bit. We set a boolean, convert 
     8956  howOften to the code for `generate while objective is improving', and change 
     8957  over to `do everywhere'. Hmmm ... now I write it out, this makes sense in the 
     8958  context of the original comment. If we're doing well (objective improving) 
     8959  we'll keep probing fully active. 
     8960                         
     8961                        */ 
    87408962            bool probingWasOnBut = false; 
    87418963            CglProbing * probing = dynamic_cast<CglProbing*>(generator_[i]->generator()); 
    … …  
    87538975                } 
    87548976            } 
     8977/* 
     8978  Convert `as long as objective is improving' into `only at root' if we've 
     8979  decided cuts just aren't worth it. 
     8980*/ 
    87558981            if (willBeCutsInTree < 0 && howOften == -98) 
    87568982                howOften = -99; 
     8983/* 
     8984  And check to see if the objective is improving. But don't do the check if 
     8985  the user has specified some minimum number of cuts. 
     8986 
     8987  This exclusion seems bogus, or at least counterintuitive. Why would a user 
     8988  suspect that setting a minimum cut limit would invalidate the objective 
     8989  check? Nor do I see the point in comparing the number of rows and columns 
     8990  in the second test. 
     8991*/ 
    87578992            if (!probing && howOften == -98 && !generator_[i]->numberShortCutsAtRoot() && 
    87588993                    generator_[i]->numberCutsInTotal()) { 
    … …  
    87689003                    howOften = -99; // switch off 
    87699004            } 
     9005/* 
     9006  Below -99, this generator is switched off. There's no need to consider 
     9007  further. Then again, there was no point in persisting this far! 
     9008*/ 
    87709009            if (howOften < -99) 
    87719010                continue ; 
     9011/* 
     9012  Adjust, if howOften is adjustable. 
     9013*/ 
    87729014            if (howOften < 0 || howOften >= 1000000) { 
    87739015                if ( !numberNodes_) { 
     9016/* 
     9017  If root only, or objective improvement but no cuts generated, switch off. If 
     9018  it's just that the generator found no cuts at the root, give it one more 
     9019  chance. 
     9020*/ 
    87749021                    // If small number switch mostly off 
    87759022#ifdef JUST_ACTIVE 
    … …  
    87979044                            } 
    87989045                        } 
     9046/* 
     9047  Not productive, but not zero either. 
     9048*/ 
    87999049                    } else if ((thisCuts + generator_[i]->numberColumnCuts() < smallProblem) 
    88009050                               && !generator_[i] ->whetherToUse()) { 
     9051/* 
     9052  Not unadjustable every node, and not strong probing. 
     9053*/ 
    88019054                        if (howOften != 1 && !probingWasOnBut) { 
     9055/* 
     9056  No depth spec, or not adjustable every node. 
     9057*/ 
    88029058                            if (generator_[i]->whatDepth() < 0 || howOften != -1) { 
    88039059                                int k = static_cast<int> (sqrt(smallProblem / thisCuts)) ; 
     9060/* 
     9061  Not objective improvement, set to new frequency, otherwise turn off. 
     9062*/ 
    88049063                                if (howOften != -98) 
    88059064                                    howOften = k + 1000000 ; 
    88069065                                else 
    88079066                                    howOften = -100; 
     9067/* 
     9068  Depth spec, or adjustable every node. Force to unadjustable every node. 
     9069*/ 
    88089070                            } else { 
    88099071                                howOften = 1; 
    88109072                            } 
     9073/* 
     9074  Unadjustable every node, or strong probing. Force unadjustable every node and 
     9075  force not strong probing? I don't understand. 
     9076*/ 
    88119077                        } else { 
    88129078                            howOften = 1; 
    … …  
    88149080                            probingWasOnBut = false; 
    88159081                        } 
     9082/* 
     9083  Productive cut generator. Say we'll do it every node, adjustable. But if the 
     9084  objective isn't improving, restrict that to every fifth depth level 
     9085  (whatDepth overrides howOften in generateCuts). 
     9086*/ 
    88169087                    } else { 
    88179088                        if (thisObjective - startObjective < 0.1*fabs(startObjective) + 1.0e-5 && generator_[i]->whatDepth() < 0) 
    … …  
    88209091                    } 
    88219092                } 
     9093/* 
     9094  End root actions. 
     9095 
     9096  sumChangeObjective2_ is the objective change due to cuts. If we're getting 
     9097  much better results from branching over a large number of nodes, switch off 
     9098  cuts. 
     9099 
     9100  Except it doesn't, really --- it just puts off the decision 'til the 
     9101  next full scan, when it'll put it off again unless cuts look better. 
     9102*/ 
    88229103                // If cuts useless switch off 
    88239104                if (numberNodes_ >= 100000 && sumChangeObjective1_ > 2.0e2*(sumChangeObjective2_ + 1.0e-12)) { 
    … …  
    88269107                } 
    88279108            } 
     9109/* 
     9110  Ok, that's the frequency adjustment bit. 
     9111 
     9112  Now, if we're at the root, force probing back on at every node, for column 
     9113  cuts at least, even if it looks useless for row cuts. Notice that if it 
     9114  looked useful, the values set above mean we'll be doing strong probing in 
     9115  the tree subject to objective improvement. 
     9116*/ 
    88289117            if (!numberNodes_) { 
    88299118                if (probingWasOnBut && howOften == -100) { 
    … …  
    88379126                    willBeCutsInTree = 1; 
    88389127            } 
     9128/* 
     9129  Set the new frequency in the generator. If this is an adjustable frequency, 
     9130  use the value to set whatDepth. 
     9131 
     9132  Hey! Seems like this could override the user's depth setting. 
     9133*/ 
    88399134            generator_[i]->setHowOften(howOften) ; 
    88409135            if (howOften >= 1000000 && howOften < 2000000 && 0) { 
    … …  
    88779172            } 
    88789173        } 
     9174/* 
     9175  End loop to adjust cut generator frequency of use. 
     9176*/ 
    88799177        delete [] count ; 
    88809178        if ( !numberNodes_) { 
    … …  
    88849182                generator_[i]->setNumberActiveCutsAtRoot(generator_[i]->numberCutsActive()); 
    88859183            } 
     9184/* 
     9185  Garbage code 071219 
     9186*/ 
    88869187            // decide on pseudo cost strategy 
    88879188            int howOften = iProbing >= 0 ? generator_[iProbing]->howOften() : 0; 
    … …  
    89089209            if (willBeCutsInTree == -2) 
    89099210                willBeCutsInTree = 0; 
     9211/* 
     9212  End garbage code. 
     9213 
     9214  Now I've reached the problem area. This is a problem only at the root node, 
     9215  so that should simplify the issue of finding a workable basis? Or maybe not. 
     9216*/ 
    89109217            if ( willBeCutsInTree <= 0) { 
    89119218                // Take off cuts 
    … …  
    92589565    return numberDropped; 
    92599566} 
    9260  
     9567/* 
     9568  Return values: 
     9569    1:  feasible 
     9570    0:  infeasible 
     9571   -1:  feasible and finished (do no more work on this subproblem) 
     9572*/ 
    92619573int 
    92629574CbcModel::resolve(CbcNodeInfo * parent, int whereFrom, 
    … …  
    95739885    int returnStatus = feasible ? 1 : 0; 
    95749886    if (strategy_) { 
     9887/* 
     9888  Possible returns from status: 
     9889    -1: no recommendation 
     9890     0: treat as optimal 
     9891     1: treat as optimal and finished (no more resolves, cuts, etc.) 
     9892     2: treat as infeasible. 
     9893*/ 
    95759894        // user can play clever tricks here 
    95769895        int status = strategy_->status(this, parent, whereFrom); 
    … …  
    96449963    const double * rowLower = getRowLower(); 
    96459964    const double * rowUpper = getRowUpper(); 
     9965/* 
     9966  Scan the rows, looking for individual rows that are clique constraints. 
     9967*/ 
    96469968 
    96479969    for (iRow = 0; iRow < numberRows; iRow++) { 
    … …  
    96529974        bool good = true; 
    96539975        int slack = -1; 
     9976/* 
     9977  Does this row qualify? All variables must be binary and all coefficients 
     9978  +/- 1.0. Variables with positive coefficients are recorded at the low end of 
     9979  which, variables with negative coefficients the high end. 
     9980*/ 
    96549981        for (j = rowStart[iRow]; j < rowStart[iRow] + rowLength[iRow]; j++) { 
    96559982            int iColumn = column[j]; 
    … …  
    968210009        int iUpper = static_cast<int> (floor(upperValue + 1.0e-5)); 
    968310010        int iLower = static_cast<int> (ceil(lowerValue - 1.0e-5)); 
     10011/* 
     10012  What do we have? If the row upper bound is greater than 1-numberM1, this 
     10013  isn't a clique. If the row upper bound is 1-numberM1, we have the classic 
     10014  clique (an SOS1 on binary variables, if numberM1 = 0). If the upper bound 
     10015  equals numberM1, we can fix all variables. If the upper bound is less than 
     10016  numberM1, we're infeasible. 
     10017   
     10018  A similar analysis applies using numberP1 against the lower bound. 
     10019*/ 
    968410020        int state = 0; 
    968510021        if (upperValue < 1.0e6) { 
    … …  
    969910035                state = -3; 
    970010036        } 
    9701         if (good && state) { 
     10037  /* 
     10038  What to do? If we learned nothing, move on to the next iteration. If we're 
     10039  infeasible, we're outta here. If we decided we can fix variables, do it. 
     10040*/ 
     10041      if (good && state) { 
    970210042            if (abs(state) == 3) { 
    970310043                // infeasible 
    … …  
    972310063                } 
    972410064            } else { 
     10065/* 
     10066  And the final case: we have a clique constraint. If it's within the allowed 
     10067  size range, make a clique object. 
     10068*/ 
    972510069                int length = numberP1 + numberM1; 
    972610070                if (length >= atLeastThisMany && length < lessThanThis) { 
    … …  
    972810072                    bool addOne = false; 
    972910073                    int objectType; 
     10074/* 
     10075  Choose equality (type 1) or inequality (type 0). If we're forcing equalities, 
     10076  add a slack. 
     10077*/ 
    973010078                    if (iLower == iUpper) { 
    973110079                        objectType = 1; 
    … …  
    974010088                        } 
    974110089                    } 
     10090/* 
     10091  Record the strong values for the variables. Variables with positive 
     10092  coefficients force all others when set to 1; variables with negative 
     10093  coefficients force when set to 0. If the clique is formed against the row 
     10094  lower bound, convert to the canonical form of a clique against the row 
     10095  upper bound. 
     10096*/ 
    974210097                    if (state > 0) { 
    974310098                        totalP1 += numberP1; 
    … …  
    980410159    } 
    980510160#endif 
     10161/* 
     10162  If required, augment the constraint matrix with clique slacks. Seems like we 
     10163  should be able to add the necessary integer objects without a complete 
     10164  rebuild of existing integer objects, but I'd need to look further to confirm 
     10165  that (lh, 071219). Finally, add the clique objects. 
     10166*/ 
    980610167    if (numberCliques > 0 && numberSlacks && makeEquality) { 
    980710168        printf("adding %d integer slacks\n", numberSlacks); 
    … …  
    1251812879    return solver->isProvenOptimal() ? 1 : 0; 
    1251912880} 
     12881/*! 
     12882    \todo It'd be really nice if there were an overload for this method that 
     12883          allowed a separate value for the underlying solver's log level. The 
     12884          overload could be coded to allow an increase in the log level of the 
     12885          underlying solver. 
     12886 
     12887          It's worth contemplating whether OSI should have a setLogLevel method 
     12888          that's more specific than the hint mechanism. 
     12889*/ 
    1252012890 
    1252112891// Set log level 
    … …  
    1261312983} 
    1261412984/* Encapsulates choosing a variable - 
    12615    anyAction -2, infeasible (-1 round again), 0 done 
     12985   anyAction: -2 infeasible 
     12986              -1 round again 
     12987               0 done 
     12988 
     12989   At the point where chooseBranch is called, we've decided that this problem 
     12990   will need to be placed in the live set and we need to choose a branching 
     12991   variable. 
     12992 
     12993   Parameters: 
     12994     newNode:   the node just created for the active subproblem. 
     12995     oldNode:   newNode's parent. 
     12996     lastws:    oldNode's basis 
     12997     lowerBefore, upperBefore: column bound arrays for oldNode 
     12998     cuts:      list of cuts added to newNode. 
     12999 
     13000     resolved:  (o)  set to true if newNode is resolved during processing 
     13001     branches:  (o) will be filled in with ... ? Null on entry 
    1261613002*/ 
    1261713003int 
    … …  
    1263013016      4 - no solution but many nodes 
    1263113017         add 10 if depth >= K 
     13018    K is currently hardcoded to 8, a few lines below. 
     13019 
     13020    CBCMODEL_DEBUG: Seems like stateOfSearch_ should be 2 if 
     13021               numberHeuristicSolutions_ == numberSolutions_. 
     13022 
    1263213023    */ 
    1263313024    stateOfSearch_ = 1; 
    … …  
    1268213073#endif 
    1268313074    currentNode_ = newNode; // so can be used elsewhere 
     13075/* 
     13076  Enough preparation. Get down to the business of choosing a branching 
     13077  variable. 
     13078*/ 
    1268413079    while (anyAction == -1) { 
    1268513080        // Set objective value (not so obvious if NLP etc) 
    … …  
    1268713082        //if (numberPassesLeft<=0) 
    1268813083        //branchingState=1; 
     13084/* 
     13085  Is there a CbcBranchDecision object installed? Does it specify a 
     13086  chooseVariable method? If not, we're using the old (Cbc) side of the branch 
     13087  decision hierarchy.  In quick summary, CbcNode::chooseBranch uses strong 
     13088  branching on any objects, while CbcNode::chooseDynamicBranch uses dynamic 
     13089  branching, but only on simple integers (-3 is the code for punt due to 
     13090  complex objects). Serious bugs remain on the Cbc side, particularly in 
     13091  chooseDynamicBranch. 
     13092*/ 
    1268913093        if (!branchingMethod_ || !branchingMethod_->chooseMethod()) { 
    1269013094#ifdef COIN_HAS_CLP 
    … …  
    1272213126                    anyAction = newNode->chooseBranch(this, oldNode, numberPassesLeft) ; // dynamic did nothing 
    1272313127            } 
     13128/* 
     13129  We're on the new (Osi) side of the branching hierarchy. 
     13130*/ 
    1272413131        } else { 
    1272513132            OsiBranchingInformation usefulInfo = usefulInformation(); 
    … …  
    1281613223        } 
    1281713224    } 
     13225/* 
     13226  End main loop to choose a branching variable. 
     13227*/ 
    1281813228    if (anyAction >= 0) { 
    1281913229        if (resolved) { 
    … …  
    1309813508   1 - delete 
    1309913509      2 - just delete - don't even use 
     13510  Parameter of 2 means what it says --- the routine will do nothing except 
     13511  delete the existing heuristics. A feasibility pump is always deleted, 
     13512  independent of the parameter value, as it's only useful at the root. 
     13513 
     13514  The routine is called from branchAndBound to process the root node. But it 
     13515  will also be called when we've recursed into branchAndBound via smallBaB. 
    1310013516*/ 
    1310113517void 
    … …  
    1310713523    int i; 
    1310813524    if (deleteHeuristicsAfterwards != 2) { 
     13525/* 
     13526  If mode == 1, we delete and recreate here, then delete at the bottom. The 
     13527  create/delete part makes sense, but why delete the existing array? Seems like 
     13528  it should be preserved and restored. 
     13529*/ 
    1310913530        if (deleteHeuristicsAfterwards) { 
    1311013531            delete [] usedInSolution_; 
    … …  
    1311713538        if (eventHandler) 
    1311813539            eventHandler->setModel(this); 
     13540/* 
     13541  currentPassNumber_ is described as `cut pass number'. Again, seems a bit 
     13542  cavalier to just change it. 
     13543 
     13544  Whether this has any effect is determined by individual heuristics. Typically 
     13545  there will be a check at the front of the solution() routine that determines 
     13546  whether it will run or simply return. Root heuristics are characterised by 
     13547  node count of 0. In addition, currentPassNumber_ can be checked to to limit 
     13548  execution in terms of passes through cut generation / heuristic execution in 
     13549  solveWithCuts. 
     13550*/ 
    1311913551 
    1312013552        currentPassNumber_ = 1; // so root heuristics will run 
     13553/* 
     13554  A loop to run the heuristics. incrementUsed will mark entries in 
     13555  usedInSolution corresponding to variables that are nonzero in the solution. 
     13556  CBC_ROUNDING just identifies a message template, not the heuristic. 
     13557*/ 
    1312113558        // Modify based on size etc 
    1312213559        adjustHeuristics(); 
    … …  
    1326413701        /* 
    1326513702          Did any of the heuristics turn up a new solution? Record it before we free 
    13266           the vector. 
     13703  the vector. tree_ will not necessarily be a CbcTreeLocal; the main model gets 
     13704  a CbcTree by default. CbcTreeLocal actually implements a k-neighbourhood 
     13705  search heuristic. This initialises it with a solution and creates the 
     13706  k-neighbourhood cut. 
    1326713707        */ 
    1326813708        if (found >= 0) { 
    … …  
    1327813718        } 
    1327913719    } 
     13720/* 
     13721  Cleanup. The feasibility pump heuristic is a root heuristic to look for an 
     13722  initial feasible solution. It's had its chance; remove it. 
     13723 
     13724  For modes 1 and 2, all the heuristics are deleted. 
     13725*/ 
    1328013726    if (!deleteHeuristicsAfterwards) { 
    1328113727        for (i = 0; i < numberHeuristics_; i++) { 
Note: See TracChangeset for help on using the changeset viewer.