Right, it works. Thank you.
If I don't call GLPKMathProgInterface, does JuMP use an internal solver ?
Le mardi 22 avril 2014 23:25:07 UTC+2, Carlo Baldassi a écrit :
>
> 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.
>>>>
>>>
