-
Notifications
You must be signed in to change notification settings - Fork 2
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
ENH: optimize: milp: add function for mixed integer linear programming #31
Conversation
I ran this problem 100 times locally in a loop and didn't get a segfault. How often/what OS/platform are you seeing it on? |
scipy/optimize/_milp.py
Outdated
c, integrality, lb, ub, indptr, indices, data, b_l, b_u, options = args_iv | ||
|
||
res = _highs_wrapper(c, indptr, indices, data, b_l, b_u, | ||
lb, ub, integrality, options) |
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.
When I run locally, it appears that when disp
is not explicitly set to False
, HiGHS has logging to console set on by default, so we may need to add that option here (or in _highs_wrapper
)
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 had code that set all the options to default values, but then I deleted it. There seemed to be some options input validation in _highs_wrapper
, so I figured all that default-setting and such was happening there. If not, LMK where you think all of that should go. Probably should be in one place rather than split between the two.
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 added a default 'log_to_console': False
. Does disp
map perfectly to log_to_console
now? When we were wrapping HiGHS originally, there were a ton of different verbosity options. It looks like that may have changed?
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.
Does
disp
map perfectly tolog_to_console
now?
For our purposes I think the answer is yes.
It looks like that may have changed?
Correct, message_level
went away altogether and there is now a separate dev logging channel in addition to standard information in log_to_console
. I have been advised to ignore the dev logging and stick to just log_to_console
.
scipy/optimize/_milp.py
Outdated
objective function while satisfying the constraints. | ||
fun : float | ||
The optimal value of the objective function ``c @ x``. | ||
simplex_nit : int |
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 think all simplex_nit
/ipm_nit
/crossover_nit
will always be 0 (or -1 -- I think there might still be upstream thinking to do here) and aren't significant for MIP solutions. We can instead report mip_node_count
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 that from experimentation or did you find some documentation?
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 thought I had asked, but I can't seem to find the thread if I did. In any case, yes -- empirically this what I find happens. The counts are set to -1
at the start of a problem and are never touched by the MIP solver, so stay at -1
@mdhaber Added a couple comments, don't need to necessarily address all in this PR. Let me know when you're ready to merge and afterward we can on a PR against the main scipy repo and send a note out to the mailing list |
I opened this up against your branch but didn't intend to merge it. I think if you open gh-28 on the main repo we can merge that by ourselves because it's pretty minimal (just a new argument). Then we can open this one on the main repo and send a note to mailing list, etc.. Sound good? |
Yep, sounds good. I'll close gh-28 with latest doc changes (I also removed rounding as discussed with Julian) and I'll open a PR against the main repo shortly |
@mckib2 could you let me know about the things above? Once I get the documentation and your thoughts on which of the options we should include in the documentation, I'll submit the PR to SciPy and send a post to the mailing list. |
Did I respond to all the things you needed info about? |
Is this resolved? Could you also consider merging scipygh-15297 if you agree that Andy can add what he wants later? That way I can open mdhaber#67 on SciPy and hopefully we can get that merged, because I would also appreciate your thoughts on what options and results we should document: Options Results |
yes
If we pull the latest HiGHS in I think we'll get a dual gap tolerance we can add in addition to those you listed. Starting out with a small set of options is not necessarily a bad thing -- we'll get to add in over time only the ones that users need instead of throwing irrelevant ones at everyone
Good question -- I think it might be better to convert them to
Might be a good question for Julian -- my inclination is to say if there's a feasible solution available in the result object, then it's at least a partial success.
Sounds good |
FYI, this seems related to status reporting: ERGO-Code/HiGHS#665 |
Seems to me we should at least get the
|
Opened on main repo. |
Reference issue
gh-28
What does this implement/fix?
Adds
milp
function for mixed integer linear programmingAdditional information
TODO:
Bounds
,LinearConstraint
and making some arguments optionalLinearConstraint
s_highs_wrapper
complete? (I think there is at least some)Debug intermittent segfault inHaven't been able to reproduce it.test_milp_6
!Be consistent aboutl
/lb
,u
/ub
Other thoughts:
try...except
and an exception is raised, they can't access the information inside the object. We'll just always return anOptimizeResult
but only guarantee the availability of certain attributes.LinearConstraint
s andBound
s in addition toLinearConstraint
/Bound
objects. That way the user doesn't need to import anything butmilp
to usemilp
.constraints
to be a sequence of constraints or a single constraint.