Error Weights Objective

[ElFosco]

from cpmpy import *

model = Model()
test = intvar(0, 1000, name="test")
model.maximize(10*(test*0.5))
model.solve()

print(test.value())

In this case the error returned is

IntVar lowerbound must be integer <class 'float'> 0.0

However if I change slightly the code

from cpmpy import *

model = Model()
test = intvar(0, 1000, name="test")
model.maximize(10*(test//2))
model.solve()

print(test.value())

The code works.

[Dimosts]

During the bounds calculation in flatten_model.py, for weighted sums we have the following:

            lb, ub = bounds.min(axis=0).sum(), bounds.max(axis=0).sum() # for every column is axis=0...
            ivar = _IntVarImpl(lb, ub)

When the sum is calculated with this, it ends up being a real number instead of an int, when the weight is float. Thus, when in the next line a new intvar is created, the problem occurs due to the lower bound (and the same for upper bound) not being an integer..

This could be solved if when calculating the bounds for wsum, we take these weights into account and then convert the bounds to an int before the initialization of the new IntVar. Also, after that we should check if this creates any other problem.

I can be assigned the issue and check it, in case noone else is working in the same things. Is anyone working on this?

[Dimosts]

Ok it is related to Pull request #224, @Wout4 is working on it

[Wout4]

In that pr I make sure that bounds return ints, but there seems to be a further issue here where ortools does not like the use of floats in the objective function

[Wout4]

Model([test * 0.5>2]).solve() crashes with an ortools error for example

[tias]

So the bounds PR will cause the error not to be on our side, but on ortools. That is a step forward. A little bonus could be for us to catch in the ortools interface when somebody wants to post a linear expression with a float value, and print a less cryptic warning, e.g. a recommendation to scale the parameters by a large constant (ortools can handle large constants)

The second nice to have could be a normalisation that rewrites 4*(expr0.5) into 2expr, e.g. that it 'mul'(const, 'mul'(const, expr)) becomes the appropriate 'mul'(newconst, expr).
I think I added some code that does that for 2*wsum([1,1], [e1,e2]) and the like... somewhere... we could also do it at expression creation time for mul perhaps.