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)

CC: @dimpase @videlec @vbraun @jdemeyer

Component: numerical

Author: Matthias Koeppe

Branch/Commit: 37e87a5

Reviewer: Dima Pasechnik

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

[mkoeppe]

Branch: u/mkoeppe/get_solver_factory

[mkoeppe]

Commit: b4146a7

[mkoeppe]

New commits:

b4146a7

get_solver: Allow a callable as the solver argument

[mkoeppe]

Author: Matthias Koeppe

[sagetrac-git]

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

d9ce11e

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

[sagetrac-git]

Changed commit from b4146a7 to d9ce11e

[dimpase]

comment:6

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

[sagetrac-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

[sagetrac-git]

Changed commit from d9ce11e to 09377ac

[mkoeppe]

comment:8

Rebased on 7.2.beta4

[dimpase]

comment:10

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?

[sagetrac-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

[sagetrac-git]

Changed commit from 09377ac to cc2d999

[dimpase]

comment:12

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]

comment:13

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

[dimpase]

comment:14

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]

comment:15

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 (of the sum of the coordinates) 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]

[sagetrac-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

[sagetrac-git]

Changed commit from cc2d999 to 37e87a5

[mkoeppe]

comment:17

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

[mkoeppe]

comment:18

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

[dimpase]

Reviewer: Dima Pasechnik

[dimpase]

comment:19

OK!

[vbraun]

Changed branch from u/mkoeppe/get_solver_factory to 37e87a5