Scippy

SoPlex

Sequential object-oriented simPlex

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 ClassSet< T >::number (const T *item) const
Please check whether this is correctly implemented!
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())
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

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?