# LoadError: InexactError: Int64 caused by decimals

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`) ?

Martina

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,

2 Likes

@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

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 `Int`s then rounding is probably what you want to do.

2 Likes

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

1 Like