linprog, quadprog, and mixintprog

[mlubin]

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

[joaquimg]

I agree they should be in a separate package.

[mlubin]

SolveAndForget.jl

[joaquimg]

HighLevelMathOptInterface.jl

[rschwarz]

MathOptStandardForm.jl or MatrixMathOpt.jl

Compared to JuMP or Convex, it's actually not so high-level, right?

[joaquimg]

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

[mlubin]

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

[chriscoey]

Miles knows me too well. Yes, those names make me cringe.

[blegat]

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

[mlubin]

@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?

[mlubin]

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.

[blegat]

Yes, either that or MatrixLP also returns a vector of variable indices and a vector of constraint indices

[mlubin]

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.

[blegat]

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.

[mlubin]

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.

[blegat]

Yes, the behaviour of the other solution can be recovered by doing

MOIU.@instance LPInstance ...
instance = LPInstance()
MOI.copy!(instance, MatrixLP(...))

[mlubin]

It feels like we have the right abstractions now, I didn't expect that to be so easy :)

[mlubin]

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.

[joaquimg]

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.

[blegat]

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.

[joaquimg]

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)

[odow]

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