[Bug-glpk] [Fwd: Re: Proximity search bug (and patch)]

[Andrew Makhorin]

-------- Forwarded Message --------
From: Giorgio Sartor <address@hidden>
To: Chris Matrakidis <address@hidden>
Cc: Andrew Makhorin <address@hidden>, Bug Glpk <address@hidden>
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 <address@hidden> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-glpk