help-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] reincarnation of tspsol


From: Heinrich Schuchardt
Subject: Re: [Help-glpk] reincarnation of tspsol
Date: Tue, 20 Oct 2015 11:28:01 +0200

> Gesendet: Dienstag, 20. Oktober 2015 um 06:44 Uhr
> Von: "Andrew Makhorin" <address@hidden>
> An: "Chris Matrakidis" <address@hidden>
> Cc: address@hidden
> Betreff: Re: [Help-glpk] reincarnation of tspsol
>
> 
> >         > To avoid this, the rounding heuristic should be disabled.
> >         > Unfortunately, there is no control parameter for this in
> >         glp_iocp, so
> >         > I'm attaching an awful hack to disable it from the tspsol
> >         callback.
> >         > This is only in case anyone gets an "Assertion failed: kk <=
> >         n" error
> >         > and wants to check if this is the reason, I would advise
> >         against using
> >         > it for any other reason.
> >         >
> >         
> >         Probably the fact of specifying the callback routine can be
> >         used as a
> >         flag to disable primal heuristics, because the callback
> >         routine itself
> >         is able to apply heuristics performing necessary feasibility
> >         checks.
> > 
> > 
> > I don't like the idea of disabling primal heuristics when a callback
> > routine is used: This is the only case where I can see a problem,
> > while I can think of many scenarios where the heuristics are desirable
> > together with a callback.
> > 
> > 
> > 
> > My preference is to have a flag in glp_iocp to enable the rounding
> > heuristic (like fp_heur and ps_heur) that would be enabled by
> > glp_init_iocp() but the user can then disable. Alternatively (or
> > perhaps additionally), there could be a global flag to disable all
> > heuristics.
> > 
> 
> Okay. I will add a flag to glp_iocp (say, row_gen) that explicitly
> allows row generation. By default it is clear (no row generation is
> allowed), and being set it disables all primal heuristics.
> 

Why would you forbid all primal heuristics, e.g. the feasibility pump, to be 
used in conjunction with row generation?
The result of the feasibility pump could be valid in which case the callback 
would not add any lazy constraint.

Best regards

Heinrich Schuchardt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]