-
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 ScalarQuadraticCoefficientChange #2296
Conversation
47e002c
to
6a28d75
Compare
MOI.modify(recursive_model(b), bridge(b, ci_or_obj), change) | ||
catch | ||
MOI.throw_modify_not_allowed(ci_or_obj, change) | ||
end |
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.
@blegat do you have any ideas for this? We can't add a generic fallback for the ::Bridge
case of the second argument because then we don't know whether we're changing a constraint or an objective.
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.
Not sure what you mean. I would add a fallback in Bridges/bridge.jl
. If you want to differentiate, you have Bridges.Objective.AbstractBridge
and Bridges.Constraint.AbstractBridge
.
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.
But how do we know which ConstraintIndex
it refers to?
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.
Ah yes, I guess this is an annoying part of this error. This is also why you had to do a try
-catch
in #2300.
I think we should allow throwing this error without knowing what is the constraint index is.
At the end of the day, after the index maps, this might not be the index of the user anyway.
Or we could allow specifying a bridge instead of an index but then we still need the try catch in #2300
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.
Yeah a generic ModifyNotAllowed
would be simpler. But that could be a separate PR after this is merged?
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 but then open an issue or leave a comment here to keep not of that
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.
Opened an issue: #2306. I'll work on it after this PR is merged
Closes #1208