[Coin-discuss] OsiCuts bug

[Matthew Galati]

Hi Folks,

1 bug, 1 design question to report on OsiCuts/OsiCut:


1.)
OsiCuts::iterator OsiCuts::iterator::operator++() {
    if ( (rowCutIndex_+1)>=cutsPtr_->sizeRowCuts() ) {
        ...
        if ( cuts_.sizeRowCuts() > 0 && colCutIndex_<cuts_.sizeRowCuts() )

Seems it should be checking the colCutIndex against the number of col 
cuts, not row cuts

        if ( cuts_.sizeRowCuts() > 0 && colCutIndex_<cuts_.sizeColCuts() )


2.)
Although OsiCut::operator== is virtual, the derivation in OsiRowCut is 
not actually overloaded...

inline virtual bool operator==(const OsiCut& rhs) const;
bool OsiCut::operator==(const OsiCut& rhs) const
{
  return effectiveness()==rhs.effectiveness();
}

bool OsiRowCut::operator==(const OsiRowCut& rhs) const

Since the arguments are different... to overload it, the operator should 
be defined as

bool OsiRowCut::operator==(const OsiCut& rhs) const

This is perhaps intentional as, the OsiRowCut::operator== needs to 
access members of the derived class that don't exist in the base 
class... this actually brings up the question of whether or not 
OsiCut::operator== should be virtual in this case. This example came up 
in a situation where we are looping over OsiCuts with the 
OsiCuts::iterator... once getting the OsiCut, we want to apply the 
derived version of the operator==, but the current design will use the 
base classes operator== (despite it being virtual). To get around this, 
we have to dynamic_cast the return of the iterator to an OsiRowCut 
before using operator==. I am not sure if this can work - but can the 
iterators be virtual so that we are not forced to cast?

Matt


-- 
Matthew Galati
ISE Lehigh University
IBM Service Parts Solutions
610.758.4042 (Office)
610.882.0779 (Home)
magh at lehigh.edu, magal11 at us.ibm.com
http://sagan.ie.lehigh.edu/mgalati/