-
-
Notifications
You must be signed in to change notification settings - Fork 400
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic numeric type in JuMP #2025
Comments
One way to go for this is to parametrize the JuMP model with the coefficient type. |
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) |
|
@JiazhengZhu and I are working on wrapping SDPA-GMP for high precision SDP solving, which would benefit from being able to use 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. |
Would it be possible to introduce this feature as a non-breaking change, e.g. by defining a 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 |
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 jump-dev/Convex.jl#262 (comment)), 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
The text was updated successfully, but these errors were encountered: