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

[docs] clarify that JuMP can reformulate indicator constraints #3703

Merged
merged 1 commit into from
Mar 6, 2024

Conversation

odow
Copy link
Member

@odow odow commented Mar 6, 2024

Closes #3701

Is this better @schlichtanders?

Copy link

codecov bot commented Mar 6, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.35%. Comparing base (434940d) to head (d61127b).

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #3703   +/-   ##
=======================================
  Coverage   98.35%   98.35%           
=======================================
  Files          43       43           
  Lines        5707     5707           
=======================================
  Hits         5613     5613           
  Misses         94       94           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@schlichtanders
Copy link

Thank you so much, yes that is better.

The Big-M trick only works if the domain is limited (in this case by the Big-M), hence I find it a bit self-contradictory.
But I am fine with leaving it. Who knows who gets which benefits by seeing the Big-M formulation there

@odow
Copy link
Member Author

odow commented Mar 6, 2024

I guess the M is chosen by the user. Whereas JuMP cannot automatically perform the same reformulation only if we know the bounds to infer a suitable M.

In practice, all decision variables in reality have bounds (you cannot have infinite anything). It's just that the user may not directly specify them, or know an appropriate value.

@odow odow merged commit cb25a91 into master Mar 6, 2024
11 checks passed
@odow odow deleted the odow-patch-1 branch March 6, 2024 20:44
@remi-garcia
Copy link
Contributor

remi-garcia commented Apr 1, 2024

I just saw this with the new release. The ``Trick 2'' bothers me as it is not possible to use big M constraints if variables have not a finite domain. Doing so actually add bounds.

MWE for which this changes the result:

model = Model()
@variable(model, x[1:2])
@variable(model, z, Bin)
@constraint(model, z --> {sum(x) <= 1})
@objective(model, Max, sum(x))

Termination status: unbounded while

model = Model()
@variable(model, x[1:2])
@variable(model, z, Bin)
M = 100   # the specific value does not matter
@constraint(model, sum(x) <= 1 + M * (1 - z))
@objective(model, Max, sum(x))

Termination status: optimal, objective value: M+1

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.

Documentation Request: List whether a solver supports Indicator Constraints
3 participants