• Official comment
Gurobi Staff

This is covered in the knowledge base article Why does Gurobi sometimes return values for integer variables that are not integers?

Thanks for the replies:

so the outpout

 9.7e-12

is 0 or 1 assuming the default value of IntFeasTol is 1e-5?

Thanks

Robert

9.70E-12 means 9.7 * 10^-12 which is 0.0000000000097. So you should better assume 0 instead of 1 :-)

Just round the values you receive.

• Gurobi Staff

Rounding can be dangerous: it could make your model infeasible. It was an intentional decision not to provide a rounding feature.

I fully agree that this is dangerous and Gurobi should not do the rounding, but in the end, one needs a decision. True or false, 1 or 0 (not 9.7e-12 * true). Your article also says: "Our recommendation is that once the optimization run is complete, that you do any necessary rounding in post-processing."

In this case, I would say, it is "necessary rounding" and should be done by the end-user.

Dear Thomas,

Thank you so much for your reply. I feel that the Binary Variable Processing in Gurobi is not working.

For example as below: My model gets the output of selection of falicity A is  9.70E-12.

9.70E-12 means 9.7 * 10^-12 which is 0.0000000000097. So you should better assume 0 instead of 1

That means the facility A will not be selected?

I wonder is there any way to get the output of binary variable=0 or 1?

Thank you very much

Robert

Hi Robert,

did you read the article that Greg mentioned?

Gurobi solves a mathematical program. In this mathematical program, 9.70E-12 is a solution that is considered integer feasible. A mathematical program does not know "true" or "false", but values that are considered integer (e.g. 0 and 1) and values that are not. I don't know whether the algorithmic background is of interest for you or not.

In practice, it is often perfectly ok to round thes values that are considered integer to the nearest integer (and maybe check that the solution is really ok/feasible for you). Please do not cast but round, because also 0.999999999999 might be integer feasible, but is smaller than 1 and would become 0 in a cast operation.

Best regards,
Thomas

Dear Thomas,

I think my code in Gurobi cause problems but not sure why?

I have codes as below: DeltaA, DeltaB are binary variables. MM is big number

A <= MM DeltaA

B < = MM * DeltaB

If MM= 999999999999, then I got DeltaA= 9.70E-12 and DeltaB = 1.70E-10 means (Both are not integers)

But if I let MM=99999, then I got DeltaA= 1 and DeltaB= 0 (Both are binary integers!)

I don't know why large MM number cause problems?

Thanks

Robert

Dear Thomas,

I think my code in Gurobi cause problems but not sure why?

I have codes as below: DeltaA, DeltaB are binary variables. MM is big number

A <= MM * DeltaA

B < = MM * DeltaB

If MM= 999999999999, then I got DeltaA= 9.70E-12 and DeltaB = 1.70E-10 means (Both are not integers)

But if I let MM=99999, then I got DeltaA= 1 and DeltaB= 0 (Both are binary integers!)

I don't know why large MM number cause problems?

Thanks

Robert

Dear Robert,

both 9.70E-12 and 1.70E-10 are to be considered integer (zero)! Please accept this or re-read the article Greg mentioned.

Besides of this, you should not use huge numbers like 999999999999 because then your coefficients have too many orders of magnitude inbetween and you might experience other numerical issues. I don't remember the exact numbers, but I think coefficients should not differ more than 6 orders of magnitude or something like this.

Best regards,
Thomas