Note that you can still use GLPK.exact with JuMP, you just need to add
change the m=Model() line to this:
using GLPKMathProgInterface
m = Model(solver=GLPKSolverLP(method=:Exact))
while all the rest stays the same.
As an aside, it's really kind of annoying that GLPK.exact uses (basically)
Rational{BigInt} internally, but the interface does not allow to access
this. Seems a waste.
On Tuesday, April 22, 2014 8:28:01 PM UTC+2, Stéphane Laurent wrote:
>
> Miles, I have successfully installed JuMP and GLPKMathProgInterface on
> Windows 32-bit.
>
> Your code works very well, this is really awesome !! However the result is
> not as precise as the one given by *GLPK.exact*.
>
> using JuMP
>
> mu = [1/7, 2/7, 4/7]
> nu = [1/4, 1/4, 1/2]
> n = length(mu)
>
> m = Model()
> @defVar(m, p[1:n,1:n] >= 0)
> @setObjective(m, Min, sum{p[i,j], i in 1:n, j in 1:n; i != j})
>
> for k in 1:n
> @addConstraint(m, sum(p[k,:]) == mu[k])
> @addConstraint(m, sum(p[:,k]) == nu[k])
> end
> solve(m)
>
>
> julia> println("Optimal objective value is:", getObjectiveValue(m))
> Optimal objective value is:0.10714285714285715
>
> julia> 3/28
> 0.10714285714285714
>
>
>
>
>
>
> Le jeudi 10 avril 2014 01:28:41 UTC+2, Miles Lubin a écrit :
>>
>> When we have a simplex solver (either in Julia or external) that supports
>> rational inputs, we could consider making this work with JuMP, but for now
>> JuMP stores all data as floating-point as well.
>>
>> Stephane, nice work. LP definitely needs more exposure in the probability
>> community. Please please write your LPs algebraically, there's really no
>> excuse not to do this in Julia when your original model is in this form.
>>
>> Compare this:
>>
>> using JuMP
>> m = Model()
>> @defVar(m, p[1:n,1:n] >= 0)
>> @setObjective(m, Max, sum{p[i,j], i in 1:n; i != j})
>>
>> for k in 1:n
>> @addConstraint(m, sum(p[k,:]) == μ[k])
>> @addConstraint(m, sum(p[:,k]) == ν[k])
>> end
>> solve(m)
>> println("Optimal objective value is:", getObjectiveValue(m))
>>
>>
>> with the matrix gymnastics that you had to do to use the low-level GLPK
>> interface. Writing down a linear programming problem shouldn't be that
>> hard! (Note: I haven't tested that JuMP code).
>>
>> Miles
>>
>>
>>
>> On Wednesday, April 9, 2014 11:18:26 PM UTC+1, Carlo Baldassi wrote:
>>>
>>>
>>>
>>> About GLPK.exact it is not possible to get the rational number 3/28
>>>> instead of a decimal approximation ?
>>>>
>>>
>>> No, unfortunately. Also, for that to happen/make sense, you'd also need
>>> to be able to pass all the *inputs* as exact rational values, i.e. as
>>> "1//7" instead of "1/7". This would be possible if we had a native generic
>>> Julia linear programming solver, but it's not possible with GLPK, which can
>>> only use exact arithmetic internally.
>>>
>>