get_solver should allow passing a function (a solver factory) as the solver argument

[mkoeppe]

For example, to use GLPK's exact simplex algorithm:

from sage.numerical.backends.generic_backend import get_solver
def glpk_exact_solver():
    b = get_solver(solver="GLPK")
    b.solver_parameter("simplex_or_intopt", "exact_simplex_only")
    return b

delsarte_bound_additive_hamming_space(19,15,7,solver=glpk_exact_solver)

[mkoeppe]

New commits:

​b4146a7

get_solver: Allow a callable as the solver argument

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​d9ce11e

MixedIntegerLinearProgram.__copy__: Don't create a throw-away GLPK instance

[dimpase]

this also needs a rebase (sorry for sitting on this too long...)

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​623a2e2	get_solver: Allow a callable as the solver argument
​09377ac	MixedIntegerLinearProgram.__copy__: Don't create a throw-away GLPK instance

[mkoeppe]

Rebased on 7.2.beta4

[dimpase]

without the example in the ticket description it's hard to get the idea of this change. Can you add this example into the code?

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​d1d84c6	get_solver: Add doctest
​cc2d999	Mention solver=callable in docstrings and error messages

[dimpase]

the doctest in the commit d1d84c6 appears to demonstrate a bug in the ILP solver of GLPK. The correct answer should be 3, not 2. Indeed, look at the entry n=19, k=2 in ​http://www.codetables.de/BKLC/Tables.php?q=7&n0=1&n1=100&k0=1&k1=100; it is 16, not 15.

(one also gets 3 when using PPL's ILP solver)

[mkoeppe]

GLPK has an exact simplex, not an exact MIP solver. See #20446

[dimpase]

anyhow, this answer by GLPK is wrong, ILP or LP! (the bound obtained by solving LP cannot be smaller than the one obtained from ILP)

sage: delsarte_bound_additive_hamming_space(19,15,7,isinteger=True) # ppl used
3
sage: delsarte_bound_additive_hamming_space(19,15,7) # ppl used
3

[dimpase]

sage: a,p,v=delsarte_bound_additive_hamming_space(19,15,7,solver=glpk_exact_solver,return_data=True)
...
sage:  [ZZ(j) for i,j in p.get_values(a).iteritems()]
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 48, 0, 0, 0, 0]

I need to do ZZ as otherwise it outputs floats. This is a maximization LP, and the following vector (computed by PPL) should be feasible, too:

[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 307, 0, 0, 1, 34]

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​37e87a5

Replace delsarte test by one that does not expose a bug in GLPK exact

[mkoeppe]

To move this ticket forward, I have replaced the test by something else

[mkoeppe]

The wrong result is now the subject of ticket #20447.

[dimpase]

OK!