LoadError: InexactError: Int64 caused by decimals

Specific Domains Optimization (Mathematical)
1

Hi,

In order to print my output values for the integer variable γ, I wrote

matrix_gamma = zeros(Int, length(K), length(T))
for (i,k) in enumerate(K)
    for (j,t) in enumerate(T)
        matrix_gamma[i,j] = value(γ[k,t])
    end
end

However I obtained

ERROR: LoadError: InexactError: Int64(7.000000000000023)

There is a way to avoid this error (without changing the type Int into Float64) ?

Thank you in advance,
Martina

2

Hi Martina,
apparently value(γ[k,t]) does not always return an Int. You perhaps want to round off the value? If so you can just do round(Int, value(γ[k,t])), which round the value to the nearest Int.

Also you can use broadcasting to replace your loops and shorten the code:
matrix_gamma = round.(Int, value.(γ[K,T]))

Note this makes a copy of γ which you can avoid with using a @view if you care about the allocation. The following should be fully equivalent to your code:
matrix_gamma = round.(Int, value.(@view γ[K,T]))

Cheers,
Adrian

2 Likes
3

@abraemer Thank you for your answer and great suggestions to improve my code.

It is strange that value(γ[k,t]) does not always return an Int because in my optimization model I declared gamma as an integer variable

@variable(Model, γ[k in K, t in T]>= 0,Int)

Do you know a way to avoid this error approximation?

Best,
Martina

4

I haven’t worked with JuMP (where I think @variable stems from) but I assume that internally there is some tolerance to the integer constraint. Probably due to numerical reasons. I found this stackoverflow post which seems related and mentions that solvers have some “Integer feasibility tolerance” so perhaps you need to look at the documentation of the solver you use and its treatment of integer constraints.

That being said, if you require exact Ints then rounding is probably what you want to do.

2 Likes
5

You can use round(Int, value(y[k, t])) to round to the nearest integer as type Int.

1 Like