[acostarelli]

Design choices:

• Only lazy constraints may be pruned. But I can see a case for any constraint.
• Two parameters: number of solves before a constraint is deemed stale; number of constraints that must be stale before pruning.
• User may manually choose to prune stale constraints.

[odow]

I think this needs to go after every solve of _iterate. We want to keep all constraints that were needed in any of the iterations, not just the ones that are binding in the optimal solution.

[acostarelli]

I believe you but can you explain to me why? I remember we talked about constraints that were violated being deemed necessary even if they aren't binding in the optimal solution, but this is a slightly different case. Is it the flip side, where if we had added the constraints in a different order, the constraints binding now would probably be violated?

[odow]

It's another trade-off between the number of constraints we keep and the number of iterations we require.

Consider a case with two solutions A and B. In solve 1, iteration 1, we find solution A. Then add a constaint that cuts it off. In iteration 2, we find solution B. The constraint we added isn't binding, so we remove it. In solve 2 iteration 1, we find solution A again, so we need to re-add the constraint.

[acostarelli]

For simplicity I moved the update into the loop. But I can see an argument for keeping the stale-count at 0 for any constraint that was binding in one optimize! call, so constraints that were binding mid-iteration and then aren't the next iteration don't get an increase.

[odow]

We're better to cache the vector of indices that need to be pruned, and then call one MOI.delete(model.inner, list_to_be_deleted), otherwise we might call MOI.delete a lot of times

[odow]

Interesting question whether this should go at the entry to _optimize!, here, or in both places. I don't know the answer.

[odow]

I'm going to merge and have a play with it. I won't tag a new release for a while.