Originally posted by: JorisK

Dear,

Currently I'm building a complex column generation model using Java and cplex. Unfortunately, often my application crashes with weird bugs I cannot explain. After many hours of testing and debugging, I've got the feeling that the issues are related to rounding errors. In Java, I have to use doubles to represent my values due to some arithmetics involved. Java's double has at least 12 decimals precision.
I have added an LP as an attachment to this topic. The solution is very easy: z0=1, all other variables equal 0. From the objective it is clear that its value must be 30.2382993503219. When I read this LP in the interactive solver, I get the following dual values:
CPLEX> display solution dual -
Constraint Name Dual Price
StudConstr8 10.895337
StudConstr12 15.864056
StudConstr19 0.300000
StudConstr37 3.179396
All other dual prices in the range 1-167 are 0.

When I sum all the dual values I obtain: 30.238789. From duality theory we know that the optimal dual value of an LP equals the optimal value of the primal. However, in this particular example, the dual objective is 0.00049 higher then the primal objective, which I think is quite a lot! I don't need a 50 decimal precision, but the precision needs to be large enough to distinguish between rounding errors and calculation errors. If I would have for example a solution like 0.1000000000004, anyone would agree that the 4 at the end is likely due to a rounding issue, but 0.1004 isn't exactly a rounding error anymore?

1. Why is the precision of cplex (version 12.4) so bad?
2. Can I somehow improve its precision? I noticed that there are several parameters I can tune but I haven't found the right one?
3. What are the consequences of increasing the precision? Slower solving?
4. Imagine that I had many more variables and fractional scalars. In such a case, the rounding error can become arbitrarily high right? How can I measure the expected rounding error such that I can distinguish rounding errors from mathematical errors?
5. I could round each scalar, but rounding intermediate values obtained from calculations is a very bad (and dangerous) habit.

Currently, whenever I have to check in my code whether a variable 'var' equals for example 1.0, I do it like this: if(|1.0-var|<= epsilon) ...., where epsilon is a very small value e.g. 0.0000000001
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: JorisK

Ok, I found part of my answer. The LP attached is apparently incorrect. All occurrences of 0 <= z? <= 1 in the bounds section should be replaced by 0 <= z? <= 2147483647. In addition, in the constraint section, one should add all constraints: z?<=1. Now one obtains an optimal dual solution which equals the optimal primal solution.

Nevertheless, I still have a few questions:

1. What is the precision of cplex? Judging from the parameter manual, most parameters related to 'tolerance' and 'precision' are set to 1e-06 by default, so I assume this is the default precision?
2. Which parameters should I adjust to increase precision?
3. Assuming that precision is set to 1e-06. Is it safe to round all obtained values such as the objective value, dual values, variable values etc to 6 decimals, or is this a bad/unsafe procedure?
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Your solution probably works but is not ideal.
First, if you want to have infinite bounds, you should use infinity (specify "+inf", or just say "z >= 0" in the bounds section). Big finite numbers can cause numerical issues.

Second, your solution means to represent the LP in standard form with non-negative variables (as opposed to "revised" form with finite upper bounds). Then, it is true that y*b = c*x, with y being a dual solution optimal and x a primal optimal solution. But if you have finite non-zero bounds, then you also need to consider the reduced costs. The reduced costs are essentially the dual multipliers of the bound constraints. So, the correct equation would be y*b + r*{l,u} = c*x. Here, r*{l,u} means that you have to multiply the reduced cost value of a variable with its lower or upper bound, depending on the sign of the reduced cost value. If your problem is a minimization problem, then a positive reduced cost r_j > 0 indicates that you should use the lower bound, i.e., r_j * l_j in the product. For r_j < 0 you need to use r_j * u_j.

Regarding your questions:
1. Yes, the default feasibility and optimality (i.e., dual feasibility) tolerances are 1e-6.
2. In the interactive, you would adjust those parameters using "set simplex tolerances feasibility xxx" and "set simplex tolerances optimality xxx".
3. What you are suggesting is not matching the definition of the tolerances. The feasibility tolerance says that CPLEX may (or may not) declare constraints to be satisfied, even if they are violated by this amount. The optimality tolerance says that CPLEX may (or may not) declare a solution optimal, even if there are negative (for variables at the lower bound) or positive (for variables at the upper bound) reduced costs that deviate from zero by at most this amount.

Tobias
#CPLEXOptimizers
#DecisionOptimization