Closed mlubin closed 3 years ago
I agree they should be in a separate package.
SolveAndForget.jl
HighLevelMathOptInterface.jl
MathOptStandardForm.jl or MatrixMathOpt.jl
Compared to JuMP or Convex, it's actually not so high-level, right?
If the functions remain with the old names linprog
and mixintprog
we could name it MatrixMathProg.jl
If we use MatrixMathOpt.jl we can rename the functions to linopt
and mixintopt
@chriscoey would argue for trashing the linprog
-style names and calling the functions solve_LP
, solve_MIP
or something along those lines. No real reason to imitate the uninformative Matlab names here.
Miles knows me too well. Yes, those names make me cringe.
What about something like
struct MatrixLP{T} <: AbstractStandaloneInstance
c::AbstractVector{T}
A::AbstractMatrix{T}
lb::AbstractVector{T}
ub::AbstractVector{T}
l::AbstractVector{T}
u::AbstractVector{T}
end
# Implements all MOI.get it can but no MOI.set!
The user can then do
MOI.copy!(solver, MatrixLP(c, A, lb, ub, l, u))
The name could be MatrixOptInterface.jl (MXOI) to mimic SemidefiniteOptInterface (SDOI), LinQuadOptInterface (LQOI) and StochOptInterface (SOI).
@blegat, I like that idea. Couldn't MatrixLP
just create an MOIU.Instance and load the data in, instead of defining a new instance type?
MatrixLP
could have a special convention for the variable and constraint indices (aligning with the A
matrix), so I see why we might want a separate implementation of AbstractStandaloneInstance
.
Yes, either that or MatrixLP also returns a vector of variable indices and a vector of constraint indices
MatrixLP also returns a vector of variable indices and a vector of constraint indices
That seems entirely unnecessary. When you create an array to store n
things, the array doesn't return the list of indices 1, ..., n
.
I meant, either MatrixLP is a separate implementation or it returns an MOIU instance with a vector of variables indices and a vector of constraint indices.
Ah. Well, a separate implementation would also be a useful code example that people will be able to understand without all the complexities of the MOIU instance.
Yes, the behaviour of the other solution can be recovered by doing
MOIU.@instance LPInstance ...
instance = LPInstance()
MOI.copy!(instance, MatrixLP(...))
It feels like we have the right abstractions now, I didn't expect that to be so easy :)
This is a good up for grabs issue. I support @blegat's LPInstance
idea over a linprog
copy. This can stay in the MOI package. We changed our philosophy about splitting off packages since this issue was last discussed.
I was thinking, maybe it could live in LinQuad, and it might be good to use the linquad mocksolver to generate the matrix instances (which is the other way). Something else I was thinking is to have ConicOptInterface, since a very similar code is used in SCS, ECOS, ProxSDP and maybe more.
Something else I was thinking is to have ConicOptInterface, since a very similar code is used in SCS, ECOS, ProxSDP and maybe more.
What can be shared by these interfaces is building a matrix similar to the MPB conic interface using the allocate-load interface.
I agree that we could have something like an AbstractMatrixConicOptimizer <: AbstractOptimizer
to share that.
I started playing around with this in https://github.com/joaquimg/MatrixOptInterface.jl Just a sketch for now, but comments would be nice. (zero performance optimization so far)
Closing because we have https://github.com/jump-dev/MatrixOptInterface.jl although it still needs some work.
We also have documentation to explain how to transition to JuMP: https://jump.dev/MathOptInterface.jl/dev/tutorials/mathprogbase/#Transitioning-the-high-level-functions
These should be renamed without the
prog
and perhaps moved to a separate package. I don't see a good reason why these three particular functions should be in MOI itself.Relevant: http://www.juliaopt.org/MathOptInterface.jl/latest/apimanual.html#A-more-complex-example:-solveintegerlinear-1