> Gesendet: Dienstag, 20. Oktober 2015 um 06:44 Uhr
> Von: "Andrew Makhorin" <[email protected]>
> An: "Chris Matrakidis" <[email protected]>
> Cc: [email protected]
> 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

_______________________________________________
Help-glpk mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-glpk

Reply via email to