search

scipopt / scip

SCIP - Solving Constraint Integer Programs
Other
403 stars 64 forks source link

SCIP calculates the correct result but presents another #50

Closed pmlpm1986 closed 1 year ago

pmlpm1986 commented 1 year ago

I have been using SCIP through pyomo and through the command line and have recently come across a funny result: the solution appears to be calculated correctly, since pyomo stores the variables with the correct result, but the solution is not shown in the printout. I have tested this also in the command line and the result is the same.

The optimal solution is 2.9242718553e-04 (determined through the variables stored in pyomo and confirmed manually and via CPLEX) but SCIP prints that it is +0.00000000000000e+00 instead.

I am using debian bookworm and SCIP 8.0.3 but I had to handle some dependencies in unusual ways to install it.

I am attaching the problem so that this may be confirmed. scip_problem.zip

svigerske commented 1 year ago

SCIP by default treats absolute values below 1e-9 as zero in many places. For this instance, it means that 4.6666667039999999e-10 objective coefficients do not make it into the problem that SCIP solves.

If I set numerics/epsilon = 1e-12, I get +2.92427185532635e-04 as optimal value. But I wouldn't recommend changing numerics/epsilon in general. This isn't tested.

pmlpm1986 commented 1 year ago

Thank you. Following your suggestion, I modified that parameter and was able to obtain the expected result. However, I wonder if this option should be kept as it is: shouldn't users be the ones to decide whether or not such low values can be regarded as zero? I suspect this has an impact on performance/matrix sparsity but couldn't it also break a problem?

svigerske commented 1 year ago

The value of numerics/epsilon is used at many different places, mainly to deal with rounding errors in floating point arithmetic.

It would be nice if the readers would notify that very small coefficients are dropped.