Todo List

Member checkSolutionRational (SoPlexBase< R > &soplex)

implement external check; currently we use the internal methods for convenience

Member checkSolutionReal (SoPlexBase< R > &soplex)

implement external check; currently we use the internal methods for convenience

Member CLUFactorRational::eliminatePivot (int prow, int pos)

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 CLUFactorRational::forestUpdate (int col, Rational *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!

Member DEFAULT_RANDOM_SEED

try to move to cpp file by forward declaration

Class DSVectorBase< R >

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

Member IdxSet::remove (int n)

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

Member main (int argc, char *argv[])

the EGlib version info should be printed after the SoPlexBase version info

File slufactor_rational.cpp

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

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

Member SLUFactorRational::solveLeft (VectorRational &x, const VectorRational &b)

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

Namespace soplex

implement automatic rep switch, based on row/col dim

introduce status codes for SoPlex, especially for rational solving

implement main IR loop for primal and dual feasible case with fail otherwise (Ambros)

implement statistical info (time, factor time, iters, ...) since last call to solveReal() or solveRational() (Ambros?)

implement performInfeasibilityIR (Ambros?)

extend IR loop to infeasible case (Dan?)

extend IR loop to unbounded case (Dan?)

integrate rational reconstruction into IR loop

integrate rational SPxSolver and distinguish between original and transformed rational LP

rational scalers

rational simplifier

record and return "best" solutions found during IR (Ambros)

interface rational reconstruction code for rational vectors

Member soplex::reconstructSol (SolRational &solution)

make this a method of class SoPlex

Class SPxDevexPR< R >

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

File spxfileio.h

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

Class SPxHarrisRT< R >

HarrisRT leads to cycling in dcmulti.sub.lp

Member SPxLPBase< R >::addCols (const S *objValue, const S *lowerValues, const S *colValues, const int *colIndices, const int *colStarts, const int *colLengths, const int numCols, const int numValues, const S *upperValues)

implement the addition of new rows as in doAddCols()

Member SPxLPBase< R >::addRows (const S *lhsValues, const S *rowValues, const int *rowIndices, const int *rowStarts, const int *rowLengths, const int numRows, const int numValues, const S *rhsValues)

implement the addition of new columns as in doAddRows()

Member SPxLPBase< R >::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 SPxSolverBase< R >::basisStatusToVarStatus (typename SPxBasisBase< R >::Desc::Status stat) const

put the following basis methods near the variable status methods!

Member SPxSolverBase< R >::Status

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

Member SPxSolverBase< R >::vector (const SPxId &p_id) const

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

Member SSVectorBase< R >::multAdd (S xx, const SVectorBase< T > &vec)

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

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

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

Class SVectorBase< R >

SVectorBase should get a new implementation. There maybe a lot of memory lost due to padding the Nonzero structure. A better idea seems to be class SVectorBase { int size; int used; int* idx; R* val; }; which for several reasons could be faster or slower. If SVectorBase is changed, also DSVectorBase and SVSet have to be modified.

Class SVSetBase< R >::DLPSV

Check whether SVSetBase::DLPSV can be implemented as IdElement<SVectorBase>

Member SVSetBase< R >::ensureMem (int n, bool shortenLast=true)

use an independent parameter "memwastefactor" here

Class UnitVectorBase< R >

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

UnitVectorBase memory management must be changed when SVectorBase is redesigned.

Member VectorBase< R >::get_ptr ()

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

Member VectorBase< R >::operator= (const SSVectorBase< S > &vec)

do we need this also in non-template version, because SSVectorBase can be automatically cast to VectorBase?