jump-dev / JuMP.jl

Modeling language for Mathematical Optimization (linear, mixed-integer, conic, semidefinite, nonlinear)
http://jump.dev/JuMP.jl/
Other
2.24k stars 395 forks source link

Generic numeric type in JuMP #2025

Closed matbesancon closed 1 year ago

matbesancon commented 5 years ago

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

blegat commented 5 years ago

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

matbesancon commented 5 years ago

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)

blegat commented 5 years ago

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

ericphanson commented 5 years ago

@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

chriscoey commented 4 years ago

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.

rschwarz commented 3 years ago

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?

odow commented 3 years ago

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

chriscoey commented 3 years ago

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?

odow commented 3 years ago

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