# Decision Optimization

View Only

## Why does the Cplex relaxes the value of decision variables ?

• #### 1.  Why does the Cplex relaxes the value of decision variables ?

Posted 9 days ago
Edited by milena kafka 9 days ago
Hello everyone,

I am modelling a production planning model . It is a MIP model. When I solve the problem on Cplex , I obtain the following values 9.66338120633736e-13

for a variable defined like this:

dvar float s[k][t] in 0..1000000; // inventory value of product k in period t
dvar float x[k][t] in 0..1000000; // production quantity of product k in period t
// D[k][t] the demand of product k in period t

The constraints I believe might cause this problem are those :

forall( b in k)
{

x[b][1]-s[b][1]>=D[b][1];
}

forall(a in t:a>=2, b in k)
{

x[b][a]+s[b][a-1]-s[b][a]>=D[b][a];
}

Why do I get such values ? Thank you so much in advance

------------------------------
milena kafka
------------------------------

• #### 2.  RE: Why does the Cplex relaxes the value of decision variables ?

Posted 9 days ago
Hello, why are you using ```dvar float``` and not ```dvar int``` ?

------------------------------
Vincent Beraudier
------------------------------

• #### 3.  RE: Why does the Cplex relaxes the value of decision variables ?

Posted 9 days ago
This is something of a two part question (which has been asked on other forums). The first part is why the variable value is 9e-13 as opposed to zero. CPLEX (like almost every other solver) uses double-precision (DP) numbers internally, and arithmetic with double-precision numbers is not perfectly accurate. It encounters truncation errors (you cannot represent 1/3 exactly as a binary or decimal number with a finite number of digits) and rounding errors (3 * 1/3 will be close to 1 but perhaps not exactly 1). There are (I think) some "exact" solvers for models where all parameters are integer or rational, but my sense is that they are not practical for general use. So we just learn to live with a bit of imprecision in the answers. That leads to the next point: CPLEX has tolerances for what is considered to satisfy a constraint, including an integrality constraint. So 9e-13 is "close enough" to 0 to be considered an integer.

The other part of the question is why CPLEX does not automatically round away "decimal dust". I've seen some users argue that, particularly when a variable is declared to be integer (and, as noted by Vincent, yours are not), CPLEX should return an integer value if the DP value is within tolerance of being an integer. I'm not privy to IBM's design decisions, but my guess is that some people would like to see the full DP value (for instance, to get a sense of how likely it is that the solution is suffering from some sort of numerical instability?), and therefore it is better to return the DP value and let the user decide if they want to round it than to make that decision for the user.

------------------------------
Paul Rubin
Professor Emeritus
Michigan State University
------------------------------