Changeset 1356 for branches


Ignore:
Timestamp:
Dec 4, 2009 2:58:44 PM (9 years ago)
Author:
EdwinStraver
Message:

Added some comments from Lou

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

Legend:

Unmodified
Added
Removed
  • branches/sandbox/Cbc/src/CbcClique.cpp

    r1344 r1356  
    121121    delete [] type_;
    122122}
     123/*
     124  Unfortunately, that comment is untrue. And there are other issues. This
     125  routine is clearly an unfinished work.
     126*/
    123127double
    124128CbcClique::infeasibility(const OsiBranchingInformation * /*info*/,
     
    136140        model_->getDblParam(CbcModel::CbcIntegerTolerance);
    137141    double * sort = new double[numberMembers_];
    138 
     142/*
     143  Calculate integer infeasibility and fill an array. Pick off the infeasibility
     144  of the slack and the max infeasibility while we're at it. You can see here
     145  the conversion of `non-SOS' (strong value of 0, negative coefficient) to
     146  `SOS' (strong value of 1, positive coefficient). Also count the number of
     147  variables that have integral values but are not fixed.
     148*/
    139149    double slackValue = 0.0;
    140150    for (j = 0; j < numberMembers_; j++) {
     
    158168        }
    159169    }
    160     preferredWay = 1;
     170/*
     171  preferredWay will not change. The calculation of otherWay is an expensive
     172  noop --- value is ultimately unused. Same for the sort of sort. It looks like
     173  there was some notion of branching by splitting the set using even and odd
     174  indices (as opposed to first and second half).
     175*/ 
     176        preferredWay = 1;
    161177    double otherWay = 0.0;
    162178    if (numberUnsatis) {
     
    168184        }
    169185        // Need to think more
     186/*
     187  Here we have the actual infeasibility calculation. Most previous work is
     188  discarded, and we calculate a value using various counts, adjusted by the
     189  max value and slack value. This is not scaled to [0, .5].
     190*/
     191
    170192        double value = 0.2 * numberUnsatis + 0.01 * (numberMembers_ - numberFree);
    171193        if (fabs(largestValue - 0.5) < 0.1) {
  • branches/sandbox/Cbc/src/CbcSOS.cpp

    r1350 r1356  
    8080        // sort so weights increasing
    8181        CoinSort_2(weights_, weights_ + numberMembers_, members_);
     82/*
     83  Force all weights to be distinct; note that the separation enforced here
     84  (1.0e-10) is not sufficien to pass the test in infeasibility().
     85*/
     86
    8287        double last = -COIN_DBL_MAX;
    8388        int i;
     
    161166    delete [] weights_;
    162167}
     168/*
     169  Routine to calculate standard infeasibility of an SOS set and return a
     170  preferred branching direction. This routine looks to have undergone
     171  incomplete revision. There is vestigial code. preferredWay is unconditionally
     172  set to 1. There used to be a comment `large is 0.5' but John removed it
     173  at some point. Have to check to see if it no longer applies or if John
     174  thought it provided too much information.
     175*/
    163176double
    164177CbcSOS::infeasibility(const OsiBranchingInformation * info,
     
    182195    for (j = 0; j < numberMembers_; j++) {
    183196        int iColumn = members_[j];
     197/*
     198  The value used here (1.0e-7) is larger than the value enforced in the
     199  constructor.
     200*/
     201
    184202        if (lastWeight >= weights_[j] - 1.0e-7)
    185203            throw CoinError("Weights too close together in SOS", "infeasibility", "CbcSOS");
    186204        double value = CoinMax(0.0, solution[iColumn]);
    187205        sum += value;
     206/*
     207  If we're not making assumptions about integrality, why check integerTolerance
     208  here? Convenient tolerance? Why not just check against the upper bound?
     209
     210  The calculation of weight looks to be a relic --- in the end, the value isn't
     211  used to calculate either the return value or preferredWay.
     212*/
    188213        if (value > integerTolerance && upper[iColumn]) {
    189214            // Possibly due to scaling a fixed variable might slip through
Note: See TracChangeset for help on using the changeset viewer.