Fix problems introduced by remove_constraint functionality in MIP

[johnperry-math]

• if the check_redundant option in MIP is true, then remove_constraint() should remove the constraint from self._constraints

• apparently, GLPK wants you to re-initialize the basis after removing constraints, by calling glp_std_basis()

Apply:

• attachment: trac_12884.patch

Depends on #12823

Component: linear programming

Keywords: glpk, sd40.5

Author: John Perry

Reviewer: Nathann Cohen

Merged: sage-5.1.beta5

Issue created by migration from https://trac.sagemath.org/ticket/12884

[johnperry-math]

Dependencies: #12823

[johnperry-math]

comment:1

Okay, a patch is ready. I don't see any way of removing the constraints efficiently, shy of trying to changing the constraints to a list. I'm not sure we lose that much in terms of efficiency in searching for a new constraint, but removing the ith constraint is quick and easy. Maybe you have a better way of removing the constraints?

[nathanncohen]

comment:2

Hellooooooooo !!!

Okay, a patch is ready. I don't see any way of removing the constraints efficiently, shy of trying to changing the constraints to a list. I'm not sure we lose that much in terms of efficiency in searching for a new constraint, but removing the ith constraint is quick and easy. Maybe you have a better way of removing the constraints?

Well, what about taking the ith constraint, then normalize it (as you do before adding it to the set), then pop the normalized constraint out of the set ? We could have a _normalize_constraint method in the main class, which would be called before adding or removing a constraint, couldn't we ?

And could you please add a doctest ? Otherwise I am pretty sure we could forget again this duplication mechanism next time we work on constraints :-)

Nathann

[johnperry-math]

comment:3

Well, what about taking the ith constraint, then normalize it (as you do before adding it to the set), then pop the normalized constraint out of the set ? We could have a _normalize_constraint method in the main class, which would be called before adding or removing a constraint, couldn't we ?

I thought about that, but would floating-point comparisons be a problem?

And could you please add a doctest ? Otherwise I am pretty sure we could forget again this duplication mechanism next time we work on constraints :-)

We already have a doctest for the duplication mechanism. But, sure, I can add a doctest for this.

[johnperry-math]

comment:4

BTW, I will either work on this at home (where I have beta13 on two different machines!) or wait until 5.0 comes out. I don't want to download & build yet another beta at the office.

[nathanncohen]

comment:5

Helloooooooo !!!

I thought about that, but would floating-point comparisons be a problem?

Which floating point comparisons do you have in mind ?
I thought that if normalization works to test for duplicate constraints it would also work for removing them :-)

Nathann