-
Notifications
You must be signed in to change notification settings - Fork 38
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
HighLevelInterface.MixintprogSolution untyped #210
Comments
No reason other than it was written five years ago 6a8a669. Is there a reason why you are using MathProgBase over JuMP? If you are not aware, a new abstraction layer is in development at https://github.com/JuliaOpt/MathOptInterface.jl that overcomes many of the issues with MathProgBase . We are transitioning JuMP and all of the low-level solvers to it. In the near term, solvers will continue to support MathProgBase, but eventually this support will be removed. |
Yes I read about MathOptInterface, but Miles seemed to imply that this was coming in an uncertain future. We are using MathProgBase instead of JuMP because we didn't want the modeling overhead: we try to build a generic column generation framework. I read the commit you linked to, it does not seem to indicate why the fields are untyped |
The MOI train is gaining steam. JuMP is now working and a number of solvers have been, or are close to being, ported. Column generation is one notable exception that we haven't experimented with much. The current expectation is that you would add a variable, and then call a MultirowChange. (See also jump-dev/MathOptInterface.jl#360.) If you have some thoughts on a nice, generic column generation interface, now is a great time to get on-board with suggestions. The API is still going through some changes, but in the near future it will likely settle down.
It was written five years ago in one of the first commits when the majority of the interface wasn't written and hasn't been touched since :) So I would say there is no reason... |
Thanks for the information. So you would confirm that it would be better to plug a column generation framework on We are thinking about a way to make it flexible enough but with the basic use case covered. The working repo is Linda, glad to have comments :) We're still adjusting the core interface, but will have to go through obvious adjustments for MathOptInt |
💯
MOI should make this a lot easier than MPB. It has much better support for solution statuses so you won't have to resort to hacks like this, and has a much more solid way of querying the primal and dual solutions, and getting information about the availability of any such solutions. It is also more generic than MPB and can support a wider variety of problems. p.s., If you are not aware, we are holding a JuMP developers workshop next month in Bordeaux. You are most welcome to attend http://www.juliaopt.org/meetings/bordeaux2018/. |
thanks a lot for the info. Unfortunately, I won't be able to attend, I'll come back to Europe two days after the end of the workshop but it would really have been great. Regarding the statuses, what we did is clearly way too hacky as you noticed. Symbols might be too error-prone for statuses, but we were thinking users may need new status types to define new Master and SubProblems, so I'm not sure enum is the way to go |
Have a read of |
It's a common meme at Google that the way that works is deprecated and the recommended way is still under construction :) |
Is there a reason why MixintprogSolution is untyped? I was expecting status to always be a symbol (and leveraging this on top of MPBase).
The text was updated successfully, but these errors were encountered: