-
Notifications
You must be signed in to change notification settings - Fork 94
Last big renaming #217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Last big renaming #217
Conversation
|
||
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. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mention candelete
?
docs/src/apimanual.md
Outdated
|
||
|
||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/cone/cones
Shouldn't |
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 |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
AbstractInstance
->ModelLike
AbstractStandaloneInstance
-> goneAbstractSolverInstance
->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