Closed matbesancon closed 1 year 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)
.
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)
CDDLib.Optimizer{Rational{BigInt}}
and Polyhedra.VRepOptimizer{Rational{BigInt}}
should work with Rational{BigInt}
.
@jiazhengzhu and I are working on wrapping SDPA-GMP for high precision SDP solving, which would benefit from being able to use BigFloat
s. 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
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.
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?
Since the backend isn't concrete, we could do this non-breaking with Model(coefficient_type = T)
or similar.
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?
Yes, this is far too late for JuMP 1.0. Depending on the details, it might even be a JuMP 2.0 type thing.
MOI parameterizes function and set types with the number type used to store the data, example:
For the moment, JuMP uses and assumes
Float64
: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