[Symphony] Change epsilon?

[Terry]

Thanks. This worked:

void open_lp_solver(LPdata *lp_data)
{
   lp_data->si = new OsiXSolverInterface();

   /* Turn off the OSL messages (There are LOTS of them) */
   lp_data->si->setHintParam(OsiDoReducePrint);
   lp_data->si->messageHandler()->setLogLevel(0);
   lp_data->si->setupForRepeatedUse();
   //lp_data->si->setupForRepeatedUse(2,0);
   //lp_data->si->getModelPtr()->setFactorizationFrequency(200);
#ifdef __OSI_GLPK__
   lp_data->lpetol = 1e-07; /* glpk doesn't return the value of this param */ 
#else
   lp_data->lpetol = 1e-12;
   lp_data->si->setDblParam(OsiPrimalTolerance, lp_data->lpetol); 
   ////lp_data->si->getDblParam(OsiPrimalTolerance, lp_data->lpetol);
#endif
}

Terry


On Jun 30, 2011, at 3:37 PM, Ted Ralphs wrote:

> The tolerance is not exactly hard-coded---but it is inherited from the
> underlying LP solver, so unfortunately that means there is no easy,
> direct way at the moment to change it from within SYMPHONY. However,
> it *should* work to go into the open_lp_solver() subroutine in
> lp_solver.c and just add a line there that changes the feasibility
> tolerance for the underlying LP solver before SYMPHONY sets its own
> tolerance. Something like
> 
> lp_data->si->setDblParam(OsiPrimalTolerance, lp_data->lpetol);
> 
> should work. Make sure you are looking at the part of lp_solver.c for
> the interface to Osi. If this is acceptable, we can try to add a
> parameter to SYMPHONY to do this automatically.
> 
> Cheers,
> 
> Ted
> 
> On Fri, Jun 24, 2011 at 1:03 PM, Michael Hennebry
> <hennebry at web.cs.ndsu.nodak.edu> wrote:
>> On Fri, 24 Jun 2011, Terry wrote:
>> 
>>> In one solution, SYMPHONY finds an integer variable is 2.00000989. How can I take the precision out a few more decimal places?
>>> 
>>> What controls how close to an integer a variable must be? Is that epsilon? Can I change epsilon? It looks to be hard-coded. I tried changing granularity, but that's not it.
>> 
>> You can.  I don't remember how.
>> It might be a good idea sometimes.
>> Not this time.
>> Floating point computation is not exact.
>> Demanding six decimal places is already pushing it.
>> A better choice might be to use a callback to
>> see whether rounding produces a feasible solution.
>> If not, declare infeasiblilty and add a cut.
>> 
>> Suppose
>> x1 + x2 + x3 + x4 <= 3
>> 0 <= x <= 1
>> If all x's are outside [.5, .8],
>> then rounding x will not violate
>> x1 + x2 + x3 + x4 <= 3
>> 
>> In the case of all binary variables, the range [1/(n+1), 1-1/(n+1)]
>> can be useful.
>> It guarantees that if rounding fails to produce a feasible solution,
>> a cut is readily found.
>> 
>> --
>> Michael   hennebry at web.cs.ndsu.NoDak.edu
>> "Pessimist: The glass is half empty.
>> Optimist:   The glass is half full.
>> Engineer:   The glass is twice as big as it needs to be."
>> 
>> _______________________________________________
>> Symphony mailing list
>> Symphony at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/symphony
>> 
> 
> 
> 
> -- 
> Dr. Ted Ralphs
> Associate Professor, Lehigh University
> (610) 628-1280
> ted 'at' lehigh 'dot' edu
> coral.ie.lehigh.edu/~ted