JuMP.jl icon indicating copy to clipboard operation
JuMP.jl copied to clipboard

Generic numeric type in JuMP

Open matbesancon opened this issue 5 years ago • 9 comments

MOI parameterizes function and set types with the number type used to store the data, example:

julia> using JuMP
julia> MOI.LessThan(big"3.5")
MathOptInterface.LessThan{BigFloat}(3.5)

For the moment, JuMP uses and assumes Float64:

julia> @variable(m, x[1:3])
julia> @constraint(m, sum(x) <= 1//7)
x[1] + x[2] + x[3] ≤ 0.14285714285714285

Julia-native solvers should support more numeric types (see https://github.com/JuliaOpt/Convex.jl/issues/262#issuecomment-515522868), using them through JuMP would in the current state block this genericity.

From the user perspective, generic number types could allow chosen precision, Unitful.jl and others

matbesancon avatar Aug 14 '19 14:08 matbesancon

One way to go for this is to parametrize the JuMP model with the coefficient type. Model() would give a JuMP.Model{Float64} and Model{T}() would give a JuMP.Model{T}(). JuMP.VariableRef will also be parametrized by T as one of its field is the JuMP.Model. This means that in operators, we know which type to use for, e.g. +(::VariableRef, ::VariableRef).

blegat avatar Aug 14 '19 16:08 blegat

I think this will be fairly easier to implement and test once we have solvers working on multiple number types, from the conversations of last week Hypatia (Float64 / Complex) and SCIP (Float64, Rational)

matbesancon avatar Aug 14 '19 16:08 matbesancon

CDDLib.Optimizer{Rational{BigInt}} and Polyhedra.VRepOptimizer{Rational{BigInt}} should work with Rational{BigInt}.

blegat avatar Aug 15 '19 11:08 blegat

@jiazhengzhu and I are working on wrapping SDPA-GMP for high precision SDP solving, which would benefit from being able to use BigFloats. We’re currently using an branch of Convex with MOI support hacked on and parametrizing Convex’s Problem type with the numeric type, as was suggested above to do for JuMP. It would be great to be able to use JuMP to formulate problems as well.

edit: I would no longer call the MOI support in that Convex.jl branch as hacked-on, since we no longer re-use the MPB standard form and instead formulate the problem more directly for MOI

ericphanson avatar Aug 17 '19 10:08 ericphanson

Hypatia and Tulip allow generic reals. I just tried to use the JuMP.Model{T}() syntax expecting it to work but I forgot that it doesn't. My vote is for that syntax as it is quite natural.

chriscoey avatar Oct 08 '20 15:10 chriscoey

Would it be possible to introduce this feature as a non-breaking change, e.g. by defining a ModelGeneric{T} and then const Model = ModelGeneric{T}?

EDIT: Someting like this is already proposed above, but it's not clear to me whether it would be non-breaking.

Otherwise, I guess it would be post-poned to JuMP 2.x according to the roadmap, right?

rschwarz avatar Apr 22 '21 19:04 rschwarz

Since the backend isn't concrete, we could do this non-breaking with Model(coefficient_type = T) or similar.

odow avatar Apr 22 '21 20:04 odow

this has been requested at https://discourse.julialang.org/t/hypatia-jump/70717. given that MOI allows any T<:Real, it seems like a natural thing to be able to do in JuMP. is it too late to make this a 1.0 milestone?

chriscoey avatar Nov 02 '21 00:11 chriscoey

Yes, this is far too late for JuMP 1.0. Depending on the details, it might even be a JuMP 2.0 type thing.

odow avatar Nov 02 '21 00:11 odow