-
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
adding ObjectiveLimit attribute #2257
Conversation
src/attributes.jl
Outdated
""" | ||
struct ObjectiveLimit <: AbstractOptimizerAttribute end | ||
|
||
attribute_value_type(::ObjectiveLimit) = Union{Nothing,Float64} |
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.
An implicit assumption is that this applies only to scalar-valued objective functions, and that the objective is Float64
. What if the optimizer is BigFloat
, or Rational{BigFloat}
? And what about vector-valued objectives?
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.
vetor-valued objectives is another story I wouldn't touch at first. I would be okay upgrading this to:
Union{Nothing,Real}
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 we should just remove this for now. It's only implemented for a subset of attributes, and the fallback is Any
.
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.
Sure yes
good to go? |
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.
I'm okay with this, but it probably needs @blegat to take a look.
Bump @blegat |
Bump again @blegat |
ping @joaquimg too in case |
This is applied to the dual objective in dual simplex, since it's a bound on the optimal primal objective value. So, it's not the option that should be set in the MIP context HiGHS also has an My only hesitation relates to the possibility of losing consistency with Gurobi. Its |
not that I have seen no, I have seen it mostly applicable on MIP (on Gurobi and CPLEX) |
the attribute defined here is independent of the type of problem solved. For an LP, using Would that be okay to have the same parameter used for MIPs? |
Interesting thought. The default simplex strategy is to allow HiGHS to choose - and it always uses dual, since it's generally better and the implementation is better than the primal simplex implementation. I guess that it should throw an error if |
Looking at Gurobi status codes for something else yesterday, I followed the links for |
This MR introduces an attribute to set an objective limit, after which the solver can stop.
This can be useful e.g. for separation routines, when one requires at least a certain objective value to be reached.
Setting this objective bound as a constraint in a feasibility formulation is often ill-advised and can lead to poor solver behaviour, most MIP solvers provide a dedicated parameter instead:
limits/objectivestop
is coming in the next major releaseCPLEX seems to have this but it seems to be for LPs only?
Monotonically improving iterative solvers could also implement the attribute