-
Notifications
You must be signed in to change notification settings - Fork 87
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
Add MOI.attribute_value_type #1283
Conversation
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.
Is this a general problem that a number of optimizers run into? Or is it mostly just a problem with the CachingOptimizer, because of it's extra layer or redirection?
This is mainly But more widely, standardizing the return types of |
Alternatively, we could avoid having a non-concrete type for the optimizer as suggested in jump-dev/JuMP.jl#2520. |
If these types are properly defined in MOI, then we can add unit tests that solvers return the correct types. This prevents surprises when using the solver from JuMP. In terms of bikeshedding, I'd suggest |
Independently of the alternative, this could indeed be useful, attribute_value_type(::ModelLike, attr::AnyAttribute) = attribute_value_type(attr)
attribute_value_type(::ModelLike, attr::Union{MOI.VariablePrimal, MOI.VariablePrimalStart, ...}) = MOI.get(model, CoefficientType()) If there is only one method of |
I'm a +1 to standardizing the "attribute value types" of MOI attributes, and having MOIT unit tests for this expected behavior. |
d639eea
to
dc25770
Compare
src/Test/UnitTests/attributes.jl
Outdated
function $(f)(model::MOI.ModelLike, config::TestConfig) | ||
MOI.empty!(model) | ||
MOI.optimize!(model) | ||
attribute = MOI.$(attr)() |
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.
Maybe skip the test is supports
is false
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.
For now I've made these tests opt-in individually (They aren't in the unittest
testset). We probably want to wait a few releases for solvers to adapt before enforcing it and breaking every solver.
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.
What are the changes needed in the solver ? I assume they already have objects of the correct type returned, don't they ?
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.
They will return the correct object, but they may not infer correctly.
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.
Now that we're breaking things, I added the tests by default. It would be good for solvers to fix them.
@blegat how is this. I changed to |
@blegat bump. |
src/Test/UnitTests/attributes.jl
Outdated
MOI.get(model, attribute) | ||
catch err | ||
if err isa ArgumentError | ||
return # Solver does not support accessing the attribute. |
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.
@test !MOI.supports(...)
?
Originally proposed all the way back in #31.
Problem
Lots of
MOI.get
fail to infer. For example, getting the termination statusof a caching optimizer is
Any
instead ofTerminationStatusCode
.Whereas with this PR we have
Unfortunately, attributes like
MOI.VariablePrimal
fail to infer, because we don't know if they areFloat64
or not.Alternatives
If we won't want to add
MOI.return_type
, I can move it into CachingOptimizer.