Skip to content

Conversation

mlubin
Copy link
Member

@mlubin mlubin commented Feb 11, 2018

AbstractInstance -> ModelLike
AbstractStandaloneInstance -> gone
AbstractSolverInstance -> AbstractOptimizer
AbstractInstanceAttribute -> AbstractModelAttribute
AbstractSolverParameter -> AbstractOptimizerAttribute

Updated the discussion in the manual, let me know if it reads well. If there's consensus on this renaming, I'll queue up PRs on the downstream packages and merge all at once.

Closes #203


A variable can be deleted from an instance with [`delete!(::AbstractInstance, ::VariableIndex)`](@ref MathOptInterface.delete!(::MathOptInterface.AbstractInstance, ::MathOptInterface.Index)), if this functionality is supported.
A variable can be deleted from a model with [`delete!(::ModelLike, ::VariableIndex)`](@ref MathOptInterface.delete!(::MathOptInterface.ModelLike, ::MathOptInterface.Index)), if this functionality is supported.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mention candelete?



Conic duality is the starting point for MOI's duality conventions. When all functions are affine (or coordinate projections), and all constraint sets are closed convex cone, the instance may be called a conic optimization problem.
Conic duality is the starting point for MOI's duality conventions. When all functions are affine (or coordinate projections), and all constraint sets are closed convex cone, the model may be called a conic optimization problem.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/cone/cones

@blegat
Copy link
Member

blegat commented Feb 11, 2018

Shouldn't AbstractOptimizerParameter be AbstractOptimizerAttribute ? See #201 (comment)

An **Instance** ([`AbstractInstance`](@ref MathOptInterface.AbstractInstance)) is a representation of a concrete instance of an optimization problem, i.e., with all data specified. Instances are either **standalone instances** or **solver instances**:
The most significant part of MOI is the definition of the **model API** that is
used to specify an instance of an optimization problem (e.g., by adding
variables and constraints). Objects that implement the model API should inherit
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Objects that implement the model API" -> "Objects that implement parts of the model API" ? Or we consider that if an object does not implement something and say can... -> false then it is a complete implementation ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should definitely add a discussion in the documentation of the different ways to implement the model API, but for the purposes of this sentence, I consider copy-only a valid implementation of the model API.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think that if can... return false, it should be considered a valid implementation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants