Numerical floating-point precision problem
Answered
Hello there! I have been experiencing the following problem with the Gurobi solver in Python. I am basically setting up my model such that the objective of the optimization problem is to minimize the sum of nonnegative real variables. I set up the model using optlang, and I set the objective with the following line of code:
model.objective = optlang.Objective(expression=sympy.Add(*(sympy.symbols(variables_names))), direction='min')
I also enforce the nonnegativity-constraints using the following Python code:
var = optlang.Variable(var_name, lb=0, type='continuous', problem=model)
model.add(var)
I also add a lot of other constraints.
Eventually, when I run `model.optimize()`, which uses the Gurobi license, I get a solution in which one of the variables has the primal value of 8.881784197001252e-15, which is almost a 0. In theory according to my own use case, if that variable was a 0, the solution would still be valid. I am not sure why Gurobi is finding this as a solution and not the same solution but with that variable set to 0 (since we minimize the sum of the variables in the objective). I have tried setting the tolerances to small values:
tol = 1e-4
# optlang.interface.GUROBI_PARAM_FEASIBILITYTOL = tol
self.optModel.configuration._set_feasibility(tol)
self.optModel.configuration._set_optimality(tol)
self.optModel.configuration._set_integrality(tol)
but it still did not work. How could I resolve this issue? Is that possible even? Thank you so much in advance.
0
-
Hi Elie,
The default FeasibilityTol value is 1e-5. You can tighten this up to 1e-9. Similarly for OptimalityTol
Unless you have binary/integer variables, IntegralityTol will not make a difference.
If making these smaller doesn't help I think 1e-15 values can be safely rounded down to 0.Cheers,
David0
Please sign in to leave a comment.
Comments
1 comment