Skip to content
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

Merged
merged 6 commits into from
Sep 5, 2023

Conversation

matbesancon
Copy link
Contributor

@matbesancon matbesancon commented Aug 17, 2023

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:

CPLEX seems to have this but it seems to be for LPs only?
Monotonically improving iterative solvers could also implement the attribute

src/attributes.jl Outdated Show resolved Hide resolved
src/attributes.jl Outdated Show resolved Hide resolved
"""
struct ObjectiveLimit <: AbstractOptimizerAttribute end

attribute_value_type(::ObjectiveLimit) = Union{Nothing,Float64}
Copy link
Member

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?

Copy link
Contributor Author

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}

Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure yes

src/precompile.jl Outdated Show resolved Hide resolved
src/attributes.jl Outdated Show resolved Hide resolved
src/precompile.jl Outdated Show resolved Hide resolved
@matbesancon
Copy link
Contributor Author

good to go?

src/attributes.jl Outdated Show resolved Hide resolved
src/attributes.jl Outdated Show resolved Hide resolved
Copy link
Member

@odow odow left a 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.

@odow
Copy link
Member

odow commented Aug 24, 2023

Bump @blegat

@odow
Copy link
Member

odow commented Aug 27, 2023

Bump again @blegat

@matbesancon
Copy link
Contributor Author

ping @joaquimg too in case

src/attributes.jl Outdated Show resolved Hide resolved
@joaquimg joaquimg merged commit 7baa563 into jump-dev:master Sep 5, 2023
15 checks passed
@matbesancon matbesancon deleted the objective-limit branch September 5, 2023 12:54
@jajhall
Copy link

jajhall commented Sep 5, 2023

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 objective_target option that was defined so that the primal simplex solver could stop if the target was reached. However this hasn't yet been implemented, and interpreting objective_target in the MIP context makes sense - and is easy to implement.

My only hesitation relates to the possibility of losing consistency with Gurobi. Its BestObjStop is just for the MIP context. Do you know whether Gurobi has a separate "target" parameter for continuous problems? My immediate search suggests not.

@matbesancon
Copy link
Contributor Author

My only hesitation relates to the possibility of losing consistency with Gurobi. Its BestObjStop is just for the MIP context. Do you know whether Gurobi has a separate "target" parameter for continuous problems? My immediate search suggests not.

not that I have seen no, I have seen it mostly applicable on MIP (on Gurobi and CPLEX)

@matbesancon
Copy link
Contributor Author

the attribute defined here is independent of the type of problem solved. For an LP, using objective_target makes sense for LPs, I don't know whether this should force the use of the primal simplex or throw an error if not used together with the primal simplex?

Would that be okay to have the same parameter used for MIPs?

@jajhall
Copy link

jajhall commented Sep 6, 2023

For an LP, using objective_target makes sense for LPs, I don't know whether this should force the use of the primal simplex or throw an error if not used together with the primal simplex?

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 objective_target has been set and the user specifies dual simplex, as it feeds back useful information.

@jajhall
Copy link

jajhall commented Sep 6, 2023

Would that be okay to have the same parameter used for MIPs?

Looking at Gurobi status codes for something else yesterday, I followed the links for USER_OBJ_LIMIT, and both refer to MIP. So, it's safe to assume that LP target/bounds aren't available to users

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.

5 participants