Add UniversalFallback and @model in doc #762
Conversation
Codecov Report
@@ Coverage Diff @@
## master #762 +/- ##
=======================================
Coverage 94.33% 94.33%
=======================================
Files 57 57
Lines 6226 6226
=======================================
Hits 5873 5873
Misses 353 353
Continue to review full report at Codecov.
|
docs/src/apireference.md
Outdated
|
|
||
| ## Models | ||
|
|
||
| The interface is generic and does not have a fixed list of functions and sets. |
There was a problem hiding this comment.
Suggested text:
MOI is designed to be extensible, so there is no fixed list of possible functions and sets. This makes it challenging to define efficient storage representations for MOI models. For cases where the functions and sets of interest are known in advance (for example, solvers support a fixed list of functions and sets), we provide the Utilities.@model that macro defines a ModelLike given a list of functions and sets to support.
Utilities.UniversalFallback is a layer that sits on top of any ModelLike and provides non-specialized (slower) fallbacks for constraints and attributes that the underlying ModeLike does not support.
src/Utilities/model.jl
Outdated
|
|
||
| """ | ||
| macro model(modelname, scalarsets, typedscalarsets, vectorsets, typedvectorsets, scalarfunctions, typedscalarfunctions, vectorfunctions, typedvectorfunctions) | ||
| macro model(modelname, scalarsets, typedscalarsets, vectorsets, typedvectorsets, scalarfunctions, typedscalarfunctions, vectorfunctions, typedvectorfunctions) |
There was a problem hiding this comment.
Can we provide a default instantiation of this type that supports all functions and sets that are defined in MOI? I think this would cover a lot of the existing use cases, and would save people from having to call the macro.
There was a problem hiding this comment.
We already provide JuMP._MOIModel which I use most of the time
There was a problem hiding this comment.
That's not a public symbol, and it requires depending on JuMP.
There was a problem hiding this comment.
We could define a @model(Model, ...) which is the same as JuMP's @model. Then JuMP won't have to define _MOIModel, it can just use MOI.Model, which decrease the chance of breaking JuMP with MOI.
I would be ok with that.
There was a problem hiding this comment.
We could define a
@model(Model, ...)which is the same as JuMP's@model. Then JuMP won't have to define _MOIModel, it can just use MOI.Model, which decrease the chance of breaking JuMP with MOI.
I would be ok with that.
I support this. I would call it something like DefaultModel or BasicModel to make it clear that it's possible to have different implementations of ModeLike. The @model macro then becomes a footnote, because most use cases are covered by BasicModel.
3 participants
No description provided.