Another semi-hacky option here is using a conventional double-precision LP
solver to tell you the active set at the solution the solver considered
optimal (up to whatever its tolerance was set to). Then you can take that
active set and solve the arbitrary-precision version of the constraint
matrix subject to the known subset of the variables being equal to zero.
You should then be able to look at the dual variables at that active set in
arbitrary precision, to tell you whether that same active set is also
optimal in exact arithmetic.
On Wednesday, April 9, 2014 4:28:41 PM UTC-7, Miles Lubin wrote:
>
> 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.
>>
>
