Currently, in intlinear.jl it receives a number.

I agree that the current strategy of JuMP is useful but I don't like the idea of cache being only in JuMP... I understand and accept the argument of having MOI a pure API but It would be nice to have the MOIU instance shared by JuMP and the solver wrapper. Example: if a solver wrapper wants to answer the query about MOI.ConstraintSet it will need to store it's own copy or build the set on the fly which would be a waste since the set exists and is stored in JuMP.

The problem with sharing is that I don't know if it is possible with julia to deny the solvers from modifying the instance once it is shared.

One possible solution: given a valid MOIU instance there are queries that do not need a solver to be answered. so wrappers do not implement those methods and we move them to MOIU. Everything using MOIU instance goes to MOIU to keep it separated from what solvers should implement. Then I see methods in MOIU like

MOIU.addconstraint!(m::MOI.AbstractSolverInstance, func::F, set::S, <:MOIU.AbstractInstance{T}, updateform::Bool)
#MOIU update its instance and if updateform == false
#MOIU keeps track of what is not yet passed through vectors for each combination F,S as discussed
#here https://github.com/JuliaOpt/MathOptInterface.jl/issues/63#issuecomment-317526848 

MOIU.update_solver_instance() 
#calls MOI.addconstraints! and deletes the vectors but keeps the instance.

MOIU.getattribute(m::MOIU.AbstractInstance{T}, ::MOI.ConstraintSet}, ref)
#replacing what was before in MOI and implemented by the solvers 
#MOI.getattribute(m::MOI.SolverInstance{T}, ::MOI.ConstraintSet}, ref)

As @blegat mentioned, this will not work in the following case:
if the solver wrapper wants to have a mode on the fly where every info required for a single constraint is added and deleted right afterwards (being only kept inside the solver).

Such solver wrappers will be denied to have an answer to the following query since now it s the responsability of MOIU instance.

MOI.getattribute(m::MOI.SolverInstance{T}, ::MOI.ConstraintSet}, ref)

To solve this issue, solvers need to have access to the instance (bad thing). and all those methods will not be replaced but only get a default implementation that uses MOIU instance (when available):

So Instead of this

MOIU.getattribute(m::MOIU.AbstractInstance{T}, ::MOI.ConstraintSet, ref)
# replacing what was before in MOI and implemented by the solvers
# MOI.getattribute(m::MOI.SolverInstance{T}, ::MOI.ConstraintSet, ref)

We can have this

MOIU.getattribute(m::MOIU.AbstractInstance{T}, ::MOI.ConstraintSet, ref)
# helps providing default implementation to
# MOI.getattribute(m::MOI.SolverInstance{T}, ::MOI.ConstraintSet}, ref)
function MOI.getattribute(m::MOI.AbstractSolverInstance{T}, s::MOI.ConstraintSet, ref)
    if has_instance(m)
       MOIU.getattribute(instance(m), s, ref)
    else
      throw MethodError()
    end
end

With JuMP being now only one among other possible users of MOI / MOIU doing instead of this :

functions1 = Vector{FunctionSetA}()
sets1 = Vector{ConstraintSetA}()
# fill the vectors
functions2 = Vector{FunctionSetA}()
sets2 = Vector{ConstraintSetB}()
# fill the vectors
# ...continue for each F,S type combination
MOI.addconstraints!(m,functions1, sets1)
MOI.addconstraints!(m,functions2, sets2)
#...continue for each F,S type combination

the follwing:

MOIU.addconstraint!(m, f, s, false) # assuming instance(m) returns an MOIU instance
#...continue adding the other constraints
MOIU.update_solver_instance(m)

Currently there is only one basis status per variable and constraint, but if there are multiple results, then they could have different bases

Define what should happen when you ask a solver to do something that it can't do. Most of this is covered by cansetattribute, cangetattribute, and supportsproblem, but not everything (like adding a certain constraint after solving: #8). We have the InvalidInstance termination status code, although you would normally test that only after calling optimize!.

We should probably define a standard exception that solvers should throw which can be intercepted by JuMP to infer that a solver won't allow a certain action. For other exceptions JuMP might decide to let them pass through to the user.

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

https://github.com/JuliaOpt/MathOptInterface.jl/blob/master/test/function_utilities.jl

is there anything else we want to redefine Base.isapprox for? may want to rename the file.

any preference where it goes?

see #122 (comment)

Many solvers allow us to change the constraint from equality to inequality. The first idea was not to support it f245a6a , one had to delete a constraint and add a new one, however some solver might be able to modify the sign and not be able to delete. Moreover modifying looks simpler.

The idea is to have something along the lines:

c_new = modifyconstraint(m::SolverInstance, ::MOI.ConstraintSet, 
    c::MOI.ConstraintReference{F, MOI.LessThan{T}}, 
    newset::MOI.EquaTo{T})::MOI.ConstraintReference{F, MOI.EqualTo{T}}

The discussion at #67 needs to result in changes to the manual.

Came across another use of MOI in a related context...

Bjarni V. Halldórsson , Erlendur S. Thorsteinsson , and Bjarni Kristjánsson (2000). A Modeling Interface to Non-Linear Programming Solvers - An instance: xMPS, the extended MPS format

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.9202

only 3 overlap, and they don't really make sense (per discussion with @mlubin). so separate these attributes.

also from discussion with @mlubin: define an interface for asking a solver whether a group of "types" of constraints is supported together. and also a way to ask the solver, given an existing model that has already been solved, what types of constraints can be added to it. EDIT moved to #8

there is confusion on my part on what a model is and what a solver is. I think perhaps the terminology could be revisited to make it clearer.

Here's a potentially naive question (considering I know nothing about conic):

Is it possible to save any problem (based on the current standard form with linear-quadratic functions, and the current sets) in the CBF format?

Because I was reading through the specification (incl. the new one http://cblib.zib.de/doc/format2.pdf) and it wasn't obvious to me how to have quadratic objectives/quadratic terms in the constraints.

It seems like if this is to be the standard form that unifies linear/conic etc, it would be nice to have one simple, easy to parse file-format that everybody agrees upon (unlike LP and MPS where nobody agrees on a canonical format and each reader/writer has weird limitations).

... haven't been ported to MOI yet. Are they Solver attributes? SolverInstance attributes? Both? Something else?

We're missing this interface, and it needs some thought to fit in with the current design.

I'm going to use this issue as a collection place for a range of questions I have implementing the CPLEX solver wrapper:

On the purpose of low-level interface

• should we expose the full (potentially ad-hoc, complicated) API, or a simplified one to satisfy MOI requirements. Don't remove existing functionality

On variable bounds

• is addconstraint!(m, v::VectorOfVariables, set::LessThan{Float64}) a valid constraint? oO
• should addconstraint!(m, v::VectorOfVariables, set::Vector{Union{LessThan{Float64}, GreaterThan{Float64}, EqualsTo{Float64}, Interval{Float64}}}) be a valid constraint so users can set bounds all at once? No. Overload the broadcast operator #63 (comment) #63 (comment)

#60 (comment)

I am still processing the details, but after talking to @mlubin I think a name change from ConstraintDual to ConicDual may be important to allow the correct generic dual convention in the future.

The current dual conventions are based on Conic duality, but to me a more generic dual convention includes:

1. dual for a constraint: simpler constraint (usually linear inequality) that approximates/contains the constraint.
2. optimal dual for a constraint: a dual constraint that can replace the original constraint and lead to the same optimal value (and maybe solution)
3. optimal set of constraint duals: set of optimal duals for the constraints that give a simple proof of optimality: e.g. objective is cx and duals are linear inequalities the cone generated by their lhs contains c
4. dual problem: structured optimization problem that finds an optimal set of constraint duals.

Point 1. also works for functions and sets, and probably the function and set duals can be combined into a dual for the associated constraint (e.g. if the function is affine and the set is a cone, we know how to get the constraint dual). Points 2. and 3. are the same up to the relative scaling between the duals required by Point 3. You also may be able to get the duals for 3. even if 4. does not exist. Probably a lot more to discuss about this (e.g. infeasibility and unboundedness) and so too early to resolve.

In the mean time I propose changing ConstraintDual to ConicDual so we can reserve FunctionDual, SetDual and ConstraintDual for the future. ConicDual would be a special case of SetDual whose feasibility/optimality is w/r to 4. In particular, this would allow us to later have a ConeDual in between SetDual and ConicDual whose feasibility/optimality could be w/r to 1.-3. (e.g. in a conic problem the ConeDuals in an optimal set from 3. would be any non-zero scalings of the optimal ConicDuals)

Is a detailed documentation enough or should we have something like the following?

abstract type AbstractSolverInstanceAttribute{T} end
...

and

function getattribute(m, attr::AnyAttribute{T}, args...)::T

We can have shortcuts like NumberOfVariables <: AbstractSolverInstanceAttribute{Int}

Since we're about to write a bunch of MOI wrappers, now would be a good time to reconsider the current structure of the solver wrappers. I propose that we move all of the MOI wrappers into separate packages, like GurobiMOI MathOptInterfaceGurobi, CPLEXMOI MathOptInterfaceCPLEX, CbcMOI MathOptInterfaceCbc, etc. The reasons are:

• We would like solver companies and developers to become more engaged with the Julia interfaces, and it will be easier to do so if we don't require them to maintain MOI wrappers as well.
• There is potential for contention when non-JuliaOpt developers want to include something in a solver wrapper (e.g., jump-dev/CPLEX.jl#125). With MOI wrappers in a separate package, the logical separation of what should go where will be more clear.
• It will be easier to write the new wrappers starting from fresh empty packages.
• We'll finally have consistency with GLPK.

It's a bit uglier to say using MathOptInterfaceGurobi versus using Gurobi. JuMP can get around this by providing a @usingsolver macro that translates @usingsolver Gurobi, Mosek into using MathOptInterfaceGurobi, MathOptInterfaceMosek.

CC's for those not watching this repo: @ulfworsoe @tkelman @odow

There are references to VariableResult which is now called VariablePrimal.

List of tests to be ported from MPB

linproginterface.jl

• 1 "Testing LP interface with $solver"
  • a "Basic interface"
  • b "addvar! interface"
  • c "setconstrLB! and setconstrUB!"
    now: "Modify constants in Nonnegative and Nonpositive"
    and: "Modify GreaterThan and LessThan sets as linear constraints"
  • d "Issue #40 from Gurobi.jl"
  • e "Change coeffs, del constr, del var"
• 2 "Testing LP interface extra with $solver"
  • a "setconstrLB! and setcontrUB!"
  • b "setvarLB! and setvarUB!"

linprog.jl

• 1 "Testing linprog and subfunctions with $solver"
  • a "LP1"
  • b "LP2"
  • c "LP3 infeasible"
  • d "LP4 unbounded"
  • e "LP4 unbounded with unique ray"

mixintprog.jl

• 1 "Testing mixintprog with $solver"
  now: "Knapsack Model"

quadprog.jl

• 1 "Testing quadprog with $solver"
  • a "QP1"
  • b "QP2"
• 2 "Testing QP duals with $solver"
  • a "QP1"
  • b "QP2"
• 3 "Testing SOCP interface with $solver"

conicinterface.jl

• 1 "Testing linear problems through conic interface with $solver"
  • a "LIN1"
  • b "LIN1A"
  • c "LIN2"
  • d "LIN2A"
  • e "LIN3 infeasible"
  • f "LIN4 infeasible"
• 2 "Testing SOC problems through conic interface with $solver"
  • a "SOC1"
  • b "SOC1A"
  • c "SOC2"
  • d "SOC2A"
  • e "SOC3 infeasible"
  • f "SOC4"
• 3 "Testing SOCRotated problems through conic interface with $solver"
  • a "SOCRotated1"
  • b "SOCRotated1A"
  • c "SOCRotated2 infeasible"
• 4 "Testing SOCINT problems through conic interface with $solver"
• 5 "Testing EXP problems through conic interface with $solver"
  • a "EXP1"
  • b "EXP1A"
  • c "EXP2"
  • d "EXP3"
• 6 "Testing SDP problems through conic interface with $solver"
  • a "SDP1"
  • a "SDP1" with PositiveSemidefinteConeScaled
  • b "SDP2"

Should we parameterize the solver and interface types with number types? For instance replace CSDPSolver by CSDPSolver{Float64} and CSDPSolverInstance by CSDPSolverInstance{Float64}.

I think this is necessary, for instance, to make SemidefiniteOptInterface work with high precision solvers.

@joaquimg proposed a performance hint to tell the MOI wrapper to load the problem into the solver. I expect that we may decide that we want other performance hints as we start implementing things, so opening this for general discussion.

It would be nice if we had a data type to store all the data for an instance in MOI format independent of a solver API. This will make it more natural to talk about performing transformations, and we could also revive loadproblem! which could be more efficient for throwing everything to a SolverInstance at once.

Should the data structure just be a dictionary with vectors of variablewise, affine, and quadratic constraints (by type)? Do we care about type stability?

The attribute name Sense seems inconsistently short for MOI. I keep thinking it should be ObjectiveSense. Opinions?

There are a few inconsistencies in the naming of various fields within sets

• dim instead of dimension: most of the time, long names are preferred (i.e. lower). However, dim is used in place of `dimension.
• a is not descriptive in the PowerCone: should it be exponent or something similar?
• l and u in Semicontinuous instead of lower and upper

Are we happy with these or do we want to change?

Why do we need Reals, Zeros, Nonnegatives, Nonpositives, GreaterThan, LessThan, EqualTo, and Interval?

struct Interval{T}
    lower::T
    upper::T
end
struct Intervals{T}
    lower::Vector{T}
    upper:Vector{T}
end
# or just riffing here...
struct VectorOfIntervals{T}
    intervals::Vector{Interval{T}}
end

# variable bounds
addconstraint!(m, ::SingleVariable, ::Interval)
addconstraint!(m, ::SingleVariable, ::Intervals) # error. Not valid

addconstraints!(m, ::VectorOfVariables, ::Interval) # every variable has the same bound
addconstraints!(m, ::VectorOfVariables, ::Intervals) # every variable has different bound

# constraints
addconstraints!(m, ::ScalarAffineFunction, ::Interval) 
addconstraints!(m, ::ScalarAffineFunction, ::Intervals) # error not valid

addconstraints!(m, ::VectorAffineFunction, ::Interval) # every constraint has same set
addconstraints!(m, ::VectorAffineFunction, ::Intervals) # every constraint has different set 

addconstraints!(m, ::ScalarQuadraticFunction, ::Interval) 
addconstraints!(m, ::ScalarQuadraticFunction, ::Intervals) # error not valid

addconstraints!(m, ::VectorQuadraticFunction, ::Interval) # every constraint has same set
addconstraints!(m, ::VectorQuadraticFunction, ::Intervals) # every constraint has different set 

You can have Nonpositives(dim) = Intervals(fill(-Inf, dim), fill(0.0, dim)) if you really want.

We have the following table in the manual:

Linear constraints

In the first four lines we use a^Tx in the first column and we say ScalarAffineFunction, should we say/use ScalarLinearFunction? This could avoid multiple representations of the same constraint. Since a^Tx - b = 0 is equivalent to a^Tx = b

ObjectiveSense is an attribute but it is also set in setobjective!.
It looks like ObjectiveSense belongs to the objective and thus could be modified by modifyobjective! instead of setattribute.

Where it belongs? Both places?

Related to JuliaOpt/SemidefiniteOptInterface.jl#1

Example:

[t, x, y] in SOC
x >= 0

but more functions/types are still being added to MOI/MOA

Right now we have a few different ways of deciding whether to run a particular test or subtest:
Example 1 Example 2.

I wanted to get rid of the duals keyword and replace it with the assumption that the solver wants us to test duals if the SupportsDuals attribute returns true, but that doesn't quite work since some solvers (ahem) do duals for linear and quadratic but not cones.

We should think up a nicer way to handle this.

Should we have a minimally standardized way to return more info about the status?

Some output info of Xpress and CPLEX do not match any existing status (and probably should not match at all) but we could have a default way to return a string/symbol/error/warning with that extra info.

The parameters are currently missing in lots of places:
http://www.juliaopt.org/MathOptInterface.jl/latest/apireference.html#MathOptInterface.GreaterThan
http://www.juliaopt.org/MathOptInterface.jl/latest/apireference.html#MathOptInterface.EqualTo
http://www.juliaopt.org/MathOptInterface.jl/latest/apireference.html#MathOptInterface.supportsproblem

#101 (comment)
It seems very fragile to depend on an interrelated package for testing MOI.

List of LP and conic solver wrappers to be implemented.
We can mark whoever is currently working on it and which ones are basically done.

• CDD (@blegat)
• Clp (@IssamT)
• Cbc
• GLPK (@joaquimg)
• CSDP (@blegat)
• ECOS (@blegat)
• SCS (@blegat)
• SDPA (@blegat)
• CPLEX (@odow)
• Gurobi (@joaquimg)
• FICO Xpress (@joaquimg)
• Mosek (@ulfworsoe)
• SCIP (@joaquimg)

from discussion with @mlubin, and following the fix to #6.

define an interface for asking a solver

• whether a group of "types" of constraints is supported together (ie a valid instance can be constructed with all of them)
• whether, given an existing instance that has already been solved, what types of constraints can be added to it

A bound constraint can be given either as a constraint or as a bound. With the current MOI interface are we able to distinguish those?

With (#70) CPLEX and Xpress working for LP we could start preparing benchmark (against MPB).

Should they be in tests or we need a bench folder?

Suggestions?

Requires a documentation update.

see issues : #40 and JuliaOpt/MathProgBase.jl#186

Discuss in the manual that it's reasonable for solvers to reject multiple variable-wise lower bounds on the same variable. See, e.g., #53.

In order to avoid some level of redundancy and extra work for the solver wrappers, I'm thinking that it would be a good idea to disallow (by convention) constraints of the form: ScalarAffineFunction in Nonnegative(1), Nonpositve(1), or Zeros(1). These are already covered by the one-dimensional sets GreaterThan, LessThan, and EqualTo.

Some functions like converting Matrices to MOI VectorAffineFunction format might be very useful for users, for instance this sketch:

function triplets(A::SparseMatrixCSC, cols::Vector{MOI.VariableReference}, rows::Vector{I})
    @assert A.m == length(rows)
    @assert A.n == length(cols)
    colval = colval(A.colptr, length(A.rowval))
    return rows[A.rowval], cols[colval], A.nzvals    
end
function colval(colptr::Vector{I}, n::Integer)
    colval = zeros(I, n)
    c = 1
    for i in 1:length(colptr)-1
        for j in colptr[i]:(colptr[i+1]-1)
            colval[c] = I(i)
            c+=1
        end
    end
    return colval
end

Would it be good to have a MOIExtras.jl?
Maybe solver APIs have similar functions that could also go into MOIExtras.jl ...

The name "variablewise function" is a holdover from variablewise constraint, which made a bit more sense.
To replace ScalarVariablewiseFunction and VectorVariablewiseFunction, what about ScalarComponentProjection and VectorComponentProjection?

Let the bikeshedding begin. @blegat @joehuchette @chriscoey @odow @joaquimg @IssamT

Thanks to @edljk for pointing this out.

What if...

References were pointers instead of UInt´s?

With UInts we can have simple vector as mappings IF the solver does not support deletions. However, if the solver supports deletions we need some mapping. This mapping could be a vector, which would grow a lot with lots of deletions; could be a linked list which is fast to delete but not fast to access; could be a Dict which is easy to delete but not so fast to access.

Given that we usually do a lot more additions than deletions, may we should not be much worried of the time it takes to delete, but with the time it takes to add.

My proposal goes as follows, instead of giving the user a unique UInt everytime a variable/constraint is added we could give a pointer to an Int that directly matches the solver´s index, the SolverInstance would also hold a list of those pointers. In case of adding a constraint there would be no need for a lookup to get the solver´s corresponding index. In case of a deletion we can set that pointer to a zero value and fix all the other pointers since the SolverInstance has a list of them, then the user´s reference are fixed.

Most important for LP blocks, e.g., groups of bounds and groups of linear constraints.

Currently we haven't defined what happens when the Sense attribute is never set. Should we define it to be minimization by default or make it required to provide a sense? I'm leaning towards the latter.

Related to JuliaOpt/SemidefiniteOptInterface.jl#1