Conversation
Codecov Report
@@ Coverage Diff @@
## master #101 +/- ##
==========================================
+ Coverage 75.44% 80.99% +5.54%
==========================================
Files 4 4
Lines 1409 1836 +427
==========================================
+ Hits 1063 1487 +424
- Misses 346 349 +3
Continue to review full report at Codecov.
|
| MOIT.contlineartest(OPTIMIZER, MOIT.TestConfig(basis = true), [ | ||
| # This requires an infeasiblity certificate for a variable bound. | ||
| "linear12", | ||
| # VariablePrimalStart not supported. |
There was a problem hiding this comment.
Is this a TODO or does GLPK not support providing feasible starting points at all?
There was a problem hiding this comment.
From what I can tell, you have to provide a complete valid basis, so this is a VariablePrimalStart not supported.
| type::TypeEnum | ||
| name::String | ||
| # Storage for constraint names associated with variables because GLPK | ||
| # can only store names for variables and proper constraints. |
There was a problem hiding this comment.
Now that single-variable constraints are tied to the index of the corresponding variable, I'm wondering if we need to support names for these constraints. You can always lookup the constraint by the variable index or name directly, and no solvers natively support names for bounds.
There was a problem hiding this comment.
I would be happy to support this. But it means that you can't give a constraint the same name as a variable if you want to look it up.
There was a problem hiding this comment.
But it means that you can't give a constraint the same name as a variable if you want to look it up.
I'm proposing to make setting ConstraintName on SingleVariable constraint into an error. This wouldn't change lookups otherwise.
To look up the bound on a variable, you first look up the variable. The index of the variable gives you the index of the bound constraint.
|
|
||
| MOI.supports(::Optimizer, ::MOI.Name) = true | ||
| MOI.supports(::Optimizer, ::MOI.Silent) = true | ||
| MOI.supports(::Optimizer, ::MOI.ConstraintSet, c) = true |
There was a problem hiding this comment.
I am surprised there is no ambiguity error because you don't give the type of c
There was a problem hiding this comment.
It should be ambiguous with https://github.com/JuliaOpt/MathOptInterface.jl/blob/ef83d2381b2e26a3e6466b8bc34b6687c7c20c61/src/attributes.jl#L122-L131
probably this isn't tested
Following in the footsteps of jump-dev/Gurobi.jl#216
Benchmarks compared to LQOI (part of this improvement comes from disabling GLPK.jl's pre-emptive checks).
Closes #102
Closes #99
Closes #95
Closes #93
Closes #92