Todo List

Member CLUFactor::eliminatePivot (int prow, int pos, Real eps)

If this test failes, lv has no value. I suppose that in this case none of the loops below that uses lv is executed. But this is unproven.

Member CLUFactor::forestUpdate (int col, Real *work, int num, int *nonz)

Use an extra member variable as a buffer for working with the dense row instead of misusing p_work. I think that should be as efficient and much cleaner.

Use an extra member variable as a buffer for the heap instead of misusing nonz and num. The method enQueueMin() seems to sort the nonzeros or something, for which it only needs some empty vector of size num.

Use an extra member variable as a buffer for the heap instead of misusing nonz and num. The method enQueueMin() seems to sort the nonzeros or something, for which it only needs some empty vector of size num.

Class DataKey

data members should be private.

Member DataSet< DATA >::number (const DATA *item) const

Please check whether this is correctly implemented!

Class DSVector

Both DSVector and SVector have a member variable that points to allocated memory. This does not seem to make too much sense. Why doesn't DSVector use the element of its base class?

Member DUPLICATE_ROWS

check: with this simplification step, the unsimplified basis seems to be slightly suboptimal for some instances

Member IdxSet::remove (int n)

Shouldn't this be an assert instead of an if (see add())

File slufactor.cpp

SLUfactor seems to be partly an wrapper for CLUFactor (was C). This should be properly integrated and demangled.

Does is make sense, to call x.clear() when next x.altValues() is called.

Member SLUFactor::solveLeft (Vector &x, const Vector &b)

Why is x.clear() here used and not with solveRight() ?

Member soplex::changeLhsStatus (SPxBasis::Desc::Status &stat, Real newLhs, Real rhs, const SPxBasis &basis, int i)

Change Lhs/Rhs Status the same way as changeBounds

Member SPxBasis::changedCol (int)

is this correctly implemented?

Member SPxBasis::changedElement (int, int)

is this correctly implemented?

Member SPxBasis::changedRow (int)

Implement changedRow(), changedCol(), changedElement() in a more clever way. For instance, the basis won't be singular (but maybe infeasible) if the change doesn't affect the basis rows/columns.

is this correctly implemented?

is this correctly implemented?

Member SPxBasis::invalidate ()

is this correctly implemented?

Class SPxDevexPR

There seem to be problems with this pricer especially on the greenbe[ab] problems with the entering algorithm (row representation?).

Member SPxDevexPR::entered4X (SPxId id, int n, int start1, int incr1, int start2, int incr2)

suspicious: the pricer should be informed, that variable id has entered the basis at position n, but the id is not used here (this is true for all pricers)

Member SPxDevexPR::setRep (SPxSolver::Representation)

suspicious: Shouldn't the relation between dim, coDim, Vecs, and CoVecs be influenced by the representation ?

File spxfileio.h

maybe rename this file (it is unrelated to spxfileio.cpp)

Class SPxHarrisRT

HarrisRT leads to cycling in dcmulti.sub.lp

Member SPxHarrisRT::degenerateEps () const

suspicious: *max is not set, but it is used (with the default setting *max=1) in selectLeave and selectEnter The question might be if max shouldn't be updated with themax?

Member SPxHarrisRT::maxDelta (Real *, Real *val, int num, const int *idx, const Real *upd, const Real *vec, const Real *low, const Real *up, Real epsilon) const

patch suggests using *max instead of themax

Member SPxHarrisRT::minDelta (Real *, Real *val, int num, const int *idx, const Real *upd, const Real *vec, const Real *low, const Real *up, Real epsilon) const

suspicious: *max is not set, but it is used (with the default setting *max=1) in selectLeave and selectEnter

patch suggests using *max instead of themax

patch suggests using *max instead of themax

Member SPxHybridPR::setType (SPxSolver::Type tp)

I changed from devex to steepest edge pricing here because of numerical difficulties, this should be investigated.

Member SPxLP::read (std::istream &in, NameSet *rowNames=0, NameSet *colNames=0, DIdxSet *intVars=0)

Make sure the Id's in the NameSets are the same as in the LP.

Member SPxSolver::basisStatusToVarStatus (SPxBasis::Desc::Status stat) const

put the following basis methods near the variable status methods!

Member SPxSolver::changeObj (const Vector &newObj)

Factorization remains valid, we do not need a reDim() pricing vectors should be recomputed.

Member SPxSolver::changeObj (int i, Real newVal)

Factorization remains valid, we do not need a reDim() pricing vectors should be recomputed.

Member SPxSolver::enter (SPxId &id)

if shift() is not zero, we must not conclude primal unboundedness

Member SPxSolver::fpsolve ()

!= REGULAR is not enough. Also OPTIMAL/DUAL/PRIMAL should be tested and acted accordingly.

technically it would be ok to finish already when (priced && maxinfeas + shift() <= entertol()) is satisfied; maybe at least in the case when SoPlex keeps jumping back between ENTER and LEAVE always shifting (looping), we may relax this condition here; note also that unShift may increase shift() slightly due to roundoff errors

technically it would be ok to finish already when (priced && maxinfeas + shift() <= entertol()) is satisfied; maybe at least in the case when SoPlex keeps jumping back between ENTER and LEAVE always shifting (looping), we may relax this condition here; note also that unShift may increase shift() slightly due to roundoff errors

technically it would be ok to finish already when (priced && maxinfeas + shift() <= entertol()) is satisfied; maybe at least in the case when SoPlex keeps jumping back between ENTER and LEAVE always shifting (looping), we may relax this condition here; note also that unShift may increase shift() slightly due to roundoff errors

technically it would be ok to finish already when (priced && maxinfeas + shift() <= entertol()) is satisfied; maybe at least in the case when SoPlex keeps jumping back between ENTER and LEAVE always shifting (looping), we may relax this condition here; note also that unShift may increase shift() slightly due to roundoff errors

Member SPxSolver::leave (int i)

if shift() is not zero we must not conclude unboundedness

Member SPxSolver::precisionReached (Real &newpricertol) const

check separately for ENTER and LEAVE algorithm

Member SPxSolver::setTerminationValue (Real value=infinity)

A first version for the termination value is implemented. Currently we check if no bound violations (shifting) is present. It might be even possible to use this termination value in case of bound violations (shifting) but in this case it is quite difficult to determine if we already reached the limit.

Member SPxSolver::solve ()

make objLimit consistent in SPxSolver

use only one DVector as buffer

make debug messages

use only one DVector as buffer

make debug messages

Member SPxSolver::Status

In spxchange, change the status to if (m_status > 0) m_status = REGULAR;

Member SPxSolver::testVecs ()

Error message "this shalt not be": shalt this be an assert (also below)?

Member SPxSolver::vector (const SPxId &p_id) const

The implementation does not exactly look like it will do what is promised in the describtion.

Member SPxSteepPR::selectLeave ()

this was an assert! is an assertion correct?

Member SPxWeightPR::computeRP (int start, int end)

TK04NOV98 here is a bug. solver()->rowVector(i).length() could be zero, so solver()->rowVector(i).length2() is also zero and we get an arithmetic exception.

Member SPxWeightST::setupWeights (SPxSolver &base)

The comments are wrong. The first is for dual simplex and the secound for primal one. Is anything else wrong? Also the values are nearly the same for both cases. Should this be ? Changed the values for r_fixed to 0 because of maros-r7. It is not clear why this makes a difference because all constraints in that instance are of equality type. Why is rowRight sometimes not set?

File ssvector.cpp

There is a lot pointer arithmetic done here. It is not clear if this is an advantage at all. See all the function int() casts.

Several operations like maxAbs could setup the vector while computing the result.

Member SSVector::multAdd (Real x, const SVector &vec)

SSVector::multAdd() should be rewritten without pointer arithmetic.

Member SSVector::SSVector (const Vector &vec, Real eps=Param::epsilon())

Is there an IdxSet::operator=( vec ) missing here?

Class SVector

SVector should get a new implementation. The trick to shift the storage by one element and then store the actual and maximum size of the vector in m_elem[-1] is ugly. Also there maybe a lot of memory lost due to padding the Element structure. A better idea seems to be class SVector { int size; int used; int* idx; Real* val; }; which for several reasons could be faster or slower. If SVector is changed, also DSVector and SVSet have to be modified.

Class SVSet::DLPSV

Check whether SVSet::DLPSV can be implemented as IdElement<SVector>

Class UnitVector

Several SVector modification methods are still accessible for UnitVector. They might be used to change the vector.

UnitVector memory management must be changed when SVector is redesigned.

Member Vector::get_ptr ()

check whether this non-const c-style acces should indeed be public

Member Vector::multAdd (Real x, const SVector &vec)

Can we move this function to a better place?

Member Vector_exact::get_ptr ()

check whether this non-const c-style acces should indeed be public