[Coin-osi-devel] More params, glpk 4.9, mip gap

[Kendall Bailey]

As I said, I'm trying to expose both to AMPL users.  The guts of
branchAndBound() are more than a couple lines, so I'd rather not
reimplement it in the AMPL driver.  Instead I modify the OsiGlpk
implementation to have a if/else branch in it's branchAndBound()
method.  Then my user community can test their AMPL models with both
lpx_intopt, lpx_integer as well as OsiCbc and OsiSym and then report
back which is working better for each model.  All's good for me, but
now if I release my AMPL driver to the world, it needs to build
against a stock OsiGlpk.  So I've added some ifdef stuff to let me
build against my custom OsiGlpk and still allow others to build on top
of the stock version.

Bottom line, as long as there's two distinct solvers in Glpk, I'd like
to make both callable from AMPL just in case there's a model that is
better solved by one or the other.

Thanks,
Kendall

On 4/10/06, Brady Hunsaker <hunsaker at engr.pitt.edu> wrote:
> Kendall,
>
> Thanks for your interest and contribution.  In the release notes in GLPK
> 4.9, the author stated that in some cases lpx_integer does better than
> lpx_intopt, but my understanding is that lpx_intopt is expected to be
> better more often--at least on hard instances.  So it probably makes
> sense to switch to it in OsiGlpk.  I just haven't made the time to make
> the change and test it yet.
>
> Does this affect your AMPL interface at all?  It seems that if you are
> using OSI routines, then it shouldn't matter what's happening behind the
> scenes.
>
> Brady
>