-------- Forwarded Message -------- From: Giorgio Sartor <[email protected]> To: Chris Matrakidis <[email protected]> Cc: Andrew Makhorin <[email protected]>, Bug Glpk <[email protected]> Subject: Re: [Bug-glpk] Proximity search bug (and patch) Date: Mon, 29 Feb 2016 21:23:59 +0800
Thanks for correcting the bug guys! :-) Yes, the glp_simplex was called to avoid the overhead of glp_intopt. I'm happy to see people using the software! :-) Regards, Giorgio On 29 Feb 2016, at 9:12 PM, Chris Matrakidis <[email protected]> wrote: >> BTW, glp_intopt allows solving pure lp (i.e. having no integer >> variables), so glp_simplex needs not to be used at all. Would this >> simplify the logic? > > I think this was an effort to avoid the glp_intopt overhead when not > necessary. However, a few quick test with miplib problems with only > binary and continuous variables (where glp_simplex is used instead of > glp_intopt in do_refine) indicate that the slow-down when using > glp_intopt unconditionally is minor - less that 1% in most cases, > while in a few cases it seems faster. > > As an aside, I only get the first solution in feasibility pump > compared to what you showed earlier: > ... > Applying FPUMP heuristic... > Pass 1 > Solution found by heuristic: -46.3368032777 > Pass 1 > Pass 2 > Pass 3 > Pass 4 > Pass 5 > ... > > Do you have any other changes in your version? > > > Best Regards, > > Chris Matrakidis > > _______________________________________________ > Bug-glpk mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/bug-glpk _______________________________________________ Bug-glpk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-glpk
