Title Make implementation of LP interface more efficient
Priority wish Status chatting
Superseder Nosy List florian, malte
Assigned To Keywords
Optional summary

Created on 2014-12-29.13:12:12 by florian, last changed by florian.

msg3988 (view) Author: florian Date: 2014-12-29.13:12:12
When working on issue443 we deferred some optimization of the interface.

1) LPConstraints and LPVariables can be created by factory methods of the
LPSolver class and store their data directly in the data structures that are
eventually used to load the LP.

2) There should be no distinction between temporary and permanent constraints
outside the interface.

3) All changes (added/removed constraints, change bounds, etc.) can be buffered
and can be loaded into the LPSolver just before solving the LP. Then it would
make no difference if constraints are added one at a time or all in one batch.

Potential problems/pitfalls with this change:

a) OSI expects the data for the initial LP in a different format than the data
for added constraints. The former (loadProblem) expects a CoinPackedMatrix or a
number of int/double arrays, while the latter (addRows) expects an array of

b) When deleting all constraints and adding new ones, loadProblem() is faster
then addRows(). We might want to detect this case and use loadProblem() if possible.

c) The data format that OSI expects is optimized for modifications. Storing data
directly into this format might lead to a lot of reallocations.
Date User Action Args
2014-12-29 13:12:12floriancreate