search

JuliaOpt / MathProgBase.jl

DEPRECATED: Solver-independent functions (i.e. linprog and mixintprog) and low-level interface for Mathematical Programming
Other
80 stars 38 forks source link

HighLevelInterface.MixintprogSolution untyped #210

Open matbesancon opened 6 years ago

matbesancon commented 6 years ago

Is there a reason why MixintprogSolution is untyped? I was expecting status to always be a symbol (and leveraging this on top of MPBase).

help?> MathProgBase.HighLevelInterface.MixintprogSolution
  No documentation found.

  Summary:

  mutable struct MathProgBase.HighLevelInterface.MixintprogSolution <: Any

  Fields:

  status :: Any
  objval :: Any
  sol    :: Any
  attrs  :: Any
odow commented 6 years ago

No reason other than it was written five years ago https://github.com/JuliaOpt/MathProgBase.jl/commit/6a8a669b4dbe495e37b4ae9ae234e70b2dd9ad00.

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.

matbesancon commented 6 years ago

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

odow commented 6 years ago

Miles seemed to imply that this was coming in an uncertain future.

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 https://github.com/JuliaOpt/MathOptInterface.jl/issues/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.

I read the commit you linked to, it does not seem to indicate why the fields are untyped

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...

matbesancon commented 6 years ago

Thanks for the information. So you would confirm that it would be better to plug a column generation framework on MathOptInterface rather than MPBase or JuMP?

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

odow commented 6 years ago

So you would confirm that it would be better to plug a column generation framework on MathOptInterface rather than MPBase or JuMP?

:100:

We are thinking about a way to make it flexible enough but with the basic use case covered

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/.

matbesancon commented 6 years ago

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

odow commented 6 years ago

we were thinking users may need new status types to define new Master and SubProblems

Have a read of http://www.juliaopt.org/MathOptInterface.jl/latest/apireference.html#Termination-Status-1 http://www.juliaopt.org/MathOptInterface.jl/latest/apireference.html#Result-Status-1 Can you think of a situation that isn't covered by these statuses?

mlubin commented 6 years ago

It's a common meme at Google that the way that works is deprecated and the recommended way is still under construction :)