7
$\begingroup$

I'm trying to solve an RCPSPDc model (maximizing the net present value instead of a makespan). The objective function is: $\sum\limits_{j \in \text{Tasks}} e^{-\theta\cdot s_{j}}\cdot p_{j}$, where $s_{j}$ is a decision variable that for each job $j$ we save the time that it begins (an integer), $p_{j}$ is the profit of the job $j$ and $\theta_{j}$ is a discount factor.

# Define objective
    model.Maximize(sum(np.exp(-delta*s[j])*pro[j] for j in range(n)))

So, when I run my model I get this error:

Traceback (most recent call last):
  File "example_python.py", line 199, in <module>
    rcpsp_solver()
  File "example_python.py", line 191, in rcpsp_solver
    model.Maximize(sum(np.exp(-delta*s[j])*pro[j] for j in range(n)))
  File "example_python.py", line 191, in <genexpr>
    model.Maximize(sum(np.exp(-delta*s[j])*pro[j] for j in range(n)))
  File "/home/diego/.local/lib/python2.7/site-packages/ortools/sat/python/cp_model.py", line 229, in __rmul__
    cp_model_helper.AssertIsInt64(arg)
  File "/home/diego/.local/lib/python2.7/site-packages/ortools/sat/python/cp_model_helper.py", line 30, in AssertIsInt64
    raise TypeError('Not an integer: %s' % x)
TypeError: Not an integer: -0.09

and 0.09 is my discount rate. So I've been switching from other solvers to this one because the same problem (Gecode, Chuffed, etc), hoping that ORtools could work. Is there a way to compute the real value (float) and solve? Actually i'm thinking that most of the Constraint programming solvers have the same issue (in addition, all mazimize makespan that has an integer objective in their examples). I'm using the python API.

$\endgroup$
6
$\begingroup$

In many of its solvers, OR-Tools only accept integers (see Laurent Perron's comment below).

Something like that:

model.Maximize(  int(round(  sum(np.exp(-delta*s[j])*pro[j] for j in range(n))  ))  )

will probably work (I haven't tried), but you might lose some precision. The usual solution is to multiply each value by a power of 10 and divide the result by the same amount.

E.g. if you want a precision of $10^{-3}$:

model.Maximize(  int(round(  sum(np.exp(-delta*s[j])*pro[j] for j in range(n))  *1000))  )

and divide the final result by 1000.

$\endgroup$
  • 1
    $\begingroup$ Can you explain the performance reasons? No floating point? Seriously, this isn't 1947, and even 1947 wasn't 1947. Here is another user mentioning the lack of floating point support or.stackexchange.com/questions/1252/… . $\endgroup$ – Mark L. Stone Jan 13 at 17:54
  • $\begingroup$ You should ask @Laurent Perron $\endgroup$ – mrBen Jan 13 at 20:21
  • 4
    $\begingroup$ It is not a performance reason, it is a precision issue. The sat solver is very sensitive to exact reasoning and repeatability. Floating point issues make developing the solver extremely complex. because we use 64 bit integers, you can always scale up your floats as explained above. You will not loose anything, especially since all MIP solver reason with a precision of 1e-4 to 1e-6. $\endgroup$ – Laurent Perron Jan 14 at 9:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.