# Floating points in ORtools

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.

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.

• 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/… . Jan 13 '20 at 17:54
• You should ask @Laurent Perron Jan 13 '20 at 20:21
• 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. Jan 14 '20 at 9:19