I don't mind either way. I slightly prefer to also keep "if there is time" things in the tracker in general, because this way, I don't have to keep a separate list. On the other hand, I already keep a email folder with issue emails I want to potentially do something about, so it wouldn't be a big change for me. I also see the argument that this is unlikely to get done on matter on what list it is.

As to how concrete the plans are: I didn't have this in mind for a while now but when working on the new interface, i thought about it again and added some TODOs in the code. For example, we now have a local class inside the CPLEX interface that represents a sparse matrix in the form that CPLEX likes. So far, we copy data into this representation (and then CPLEX copies it out of it again). I added a TODO there that we could change our structure to directly use a sparse matrix representation like this to avoid the extra copy.

> I would like to eventually do this but have no concrete plans to work on this
> now. So if you prefer me to keep track of the idea outside the tracker, we
> could close the issue and reopen it or open a new one once we get around to
> working on it.

With issues that had no activity for a long time (in this case, 8.5 years), I have a slight preference of "if in doubt, close" because past activity is often a good predictor of future activity. If there wasn't time to work on this in the past, often there is no time to work on it in the future. I'll mark it as resolved for now for this reason.

But please reopen if having it as an open issue in the tracker works better for you.

I cannot really read from your message if you have a clear preference between keeping it open or not. Personally, these days I try to keep most ideas of the form "If we can find time, it would be nice to..." outside of the tracker until there are more concrete plans to work on them. But only you know what works best for you in this regard or how concrete the plan to work on this is.

Regarding problems (b) and (c), I'm not how relevant they still are. There are definitely choices of reloading vs. modifying an LP in CPLEX/SoPlex as well, but we would have to measure the specific trade-offs again.

I would like to eventually do this but have no concrete plans to work on this now. So if you prefer me to keep track of the idea outside the tracker, we could close the issue and reopen it or open a new one once we get around to working on it.

Now that we no longer use the OSI interface, we could design the interface to more directly match the input that CPLEX (and other solvers) expect. For example, we store information row-based (one constraint stores a list of its non-zero entries, and we store a list of constraints), while CPLEX prefers a column-based sparse matrix: one vector with all non-zeroes column-by-column, one vector with row-indices of each entry, and one vector that says at which indices new columns start.

SoPlex has data structures for dynamically sized sparse matrices of this form, if we need an inspiration for our use case.

Currently, we convert our input to this form which is sufficiently fast but could be improved if we keep data in a useful format internally. This could be done together with or independent of the points 1-3 in msg3988 (all of them are still up to date).

Problem (a) is not longer an issue now that we skip OSI, but the corresponding problem for CPLEX is: if we redesign the data structures, we have to keep in mind what CPLEX expects in its interface. In this case these are the vectors of doubles and indices I described above.

Hi Florian, we're currently triaging issues. Should this one remain open as something we want to work on? If yes, can you update the status/TODOs to the current situation, now that we no longer use OSI?

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
CoinPackedVectorBase*.

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.