RFC: refactor the solver-facing API #7
Conversation
src/solver_interface.jl
Outdated
| # function lqs_setlogfile!(m::LinQuadOptimizer, path) end | ||
| # | ||
| # # TODO(@joaquimg): what is this? | ||
| # function lqs_getprobtype(m::LinQuadOptimizer) end |
|
Okay @joaquimg, this is in a nicer state. Any objections to the renaming? |
odow
changed the title
|
I will take a look today |
src/solver_interface.jl
Outdated
| """ | ||
| function lqs_getcoef(m::LinQuadOptimizer, row, col) end |
There was a problem hiding this comment.
I got rid of this because I couldn't find it used anywhere
src/solver_interface.jl
Outdated
| """ | ||
| function lqs_chgrngval!(m::LinQuadOptimizer, rows, vals) end# later | ||
| function change_range_value! end |
There was a problem hiding this comment.
I'm still open to an add_ranged_constraint! method instead of this.
| """ | ||
| lqs_getobj(m)::Vector{Float64} | ||
| get_linear_objective!(m, x::Vector{Float64}) |
src/solver_interface.jl
Outdated
|
|
||
| """ | ||
| lqs_getdj!(m, x::Vector{Float64}) | ||
| get_reducedcosts!(m, x::Vector{Float64}) |
There was a problem hiding this comment.
Maybe this shoud be get_variable_dual_solution!
src/solver_interface.jl
Outdated
|
|
||
| """ | ||
| lqs_dualfarkas!(m, x::Vector{Float64}) | ||
| get_farkasdual!(m, x::Vector{Float64}) |
There was a problem hiding this comment.
For consistency get_farkas_dual!
src/solver_interface.jl
Outdated
|
|
||
| """ | ||
| lqs_getray!(m, x::Vector{Float64}) | ||
| get_unboundedray!(m, x::Vector{Float64}) |
There was a problem hiding this comment.
For consistency get_unbounded_ray!
src/solver_interface.jl
Outdated
|
|
||
| """ | ||
| lqs_terminationstatus(m) | ||
| get_terminationstatus(m) |
src/solver_interface.jl
Outdated
|
|
||
| """ | ||
| lqs_primalstatus(m) | ||
| get_primalstatus(m) |
src/solver_interface.jl
Outdated
|
|
||
| """ | ||
| lqs_dualstatus(m) | ||
| get_dualstatus(m) |
|
I will check getcoef usage in xpress. I agree with add_ranged.
… On 7 May 2018, at 17:11, Oscar Dowson ***@***.***> wrote:
@odow commented on this pull request.
In src/solver_interface.jl:
> """
-function lqs_getcoef(m::LinQuadOptimizer, row, col) end
I got rid of this because I couldn't find it used anywhere
In src/solver_interface.jl:
> """
-function lqs_chgrngval!(m::LinQuadOptimizer, rows, vals) end# later
+function change_range_value! end
I'm still open to an add_ranged_constraint! method instead of this.
In src/solver_interface.jl:
> """
- lqs_getobj(m)::Vector{Float64}
+ get_linear_objective!(m, x::Vector{Float64})
I made this in-place.
In src/solver_interface.jl:
>
"""
- lqs_getdj!(m, x::Vector{Float64})
+ get_reducedcosts!(m, x::Vector{Float64})
Maybe this shoud be get_variable_dual_solution!
In src/solver_interface.jl:
>
"""
- lqs_dualfarkas!(m, x::Vector{Float64})
+ get_farkasdual!(m, x::Vector{Float64})
For consistency get_farkas_dual!
In src/solver_interface.jl:
>
"""
- lqs_getray!(m, x::Vector{Float64})
+ get_unboundedray!(m, x::Vector{Float64})
For consistency get_unbounded_ray!
In src/solver_interface.jl:
>
"""
- lqs_terminationstatus(m)
+ get_terminationstatus(m)
get_termination_status
In src/solver_interface.jl:
>
"""
- lqs_primalstatus(m)
+ get_primalstatus(m)
get_primal_status
In src/solver_interface.jl:
>
"""
- lqs_dualstatus(m)
+ get_dualstatus(m)
get_dual_status
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
It doesn't matter if it is used in Xpress. It only matters if it is used in LQOI. |
|
Yep, agree. But there is one function in LQOI that is extremely inefficient the one to query constraints and coefficients. This function might be a way to go that was forgotten in time and space. |
This is one argument for keepling LQOI and MOI separate. MOI won't be changing but we might be changing LQOI... |
|
Yes, there is performance tweaks to happen in LQOI, I think we should tag it separately (so its usable) and then we merge it into MOI (when stable) |
|
I am in favour of rhs, it is a bit different but I think its a well established jargon |
|
Okay, I've finished the renaming. Gurobi and GLPK both pass. I propose merging this, registering LQOI in METADATA, then merging and tagging releases of both Gurobi and GLPK. |
|
@odow do you mean tagging Gurobi and GLPK with the LQOI dependency? |
Yes. I'm hestitant to merge LQOI into MOI in the short term as it is hard to test, and may yet change. Maybe we keep as separate until JuMP 0.19 comes out, then it should be stable enough to merge into MOI. |
|
I agree with
|
|
Gurobi, Cplex, Xpress, and GLPK are pretty important parts of the JuMP ecosystem. It's not great that they're on shaky ground by depending on LQOI. But if it makes things easier for now, go ahead. Bootstrapping all the solver interfaces is hard, after all. |
|
I think doing this for now would bring testers for both MOI and JuMP, meanwhile we think on how to incorporate LQOI into MOI and test it. |
|
The alternative is to merge LQOI into MOI and just bump version bounds more often. Most of the improvements won't change the solver-facing API so they can just be patch releases... |
|
It will be a bit annoying if we have to keep bumping all the MOI upper bounds if there are LQOI breaking changes. If you expect to do this more than twice per MOI bump then it's probably better to leave it as a separate package for now. |
|
I think they might be breaking |
|
Let's punt on the decision for a bit. I'm going to merge this now, and then have a look at what needs to be implemented ASAP to avoid a lot of breaking changes in the future. |
This PR refactors the solver-facing API of LQOI.
I have chosen long, explict names in snake_case.
Remaining decisions
the name of
lqs_charget_rhsor `get_right_hand_side``whether to tag this as a separate package, or incorporate into MOI.
Pros of incorporating: it is easier to incorporate changes (i.e. the upcoming redefinition of
ScalarAffineFunctionetc.Cons of incorporating: testing.