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.
>>>  
>>

Reply via email to