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