-
-
Notifications
You must be signed in to change notification settings - Fork 394
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
Support Gurobi #2
Comments
Thanks. Let me know if need anything on my part. |
@carlobaldassi: Is it a good time to standardize |
Very cool @lindahua !! |
@carlobaldassi, @lindahua, @IainNZ, @timholy: What do you think of the following standard for solution = linprog(c, A, b, sense, lb, ub[, kwargs]) where A scalar is accepted for the A shortened version should be available as linprog(c, A, b, sense[, kwargs]) = linprog(c, A, b, sense, 0, Inf[, kwargs])
type LinprogSolution
status
objval
sol
redcost
lambda
end where By convention the dual multipliers should have the sign following the interpretation of marginal change in the objective when the corresponding active right-hand side is increased. This corresponds to the standard that reduced costs should be nonnegative when a variable is at a lower bound and nonpositive when a variable is at an upper bound. Different solvers might have different conventions for the It will be easy to extend this to @lindahua: Gurobi doesn't directly support double-sided constraints (afaik), but most other solvers do, and I think it's an important feature. To make things easy for now, the gurobi interface can throw an error in this case, but eventually it should be wrapped to work. |
My only concern about this interface is that
|
@mlubin Thanks for outlining an interface. For Gurobi, as of the latest version (v5.0+), it supports double sided constraint directly. In particular, they call it range constraint. The C functions for this are |
Some minor suggestion of the interface:
for example, we have this set of linear constraints:
It is possible to merge these into one constraint as
But let the user/caller do this may not be the optimal interface. What about a two level interface? one for the solver implementers, and the other for the caller/user. On the implementer side, an interface can be linprog(f, constraint[, params])
linprog(f, (constraint1, constraint2, ...)[, params]) Here, type UpperBoundConstraint // the internal definition is omitted
type LowerBoundConstraint
type RangeConstraint // or DoubleSided ?
type EqualityConstraint The implementer can all relevant functions to add these constraints to their models (e.g. Gurobi have different functions to add different types of constraints). One the caller side, an interface can be linprog(f, (a, '<', A, '<', b), (C, '<', c), (Aeq, '=', aeq), ...) You can also provide macros and other higher level interface to make this even simpler and more comfortable to write. Anyway, of the first priority is to standardize the implementer side's interface, such that package maintainer can do their job to make their packages conform to this interface.
I think only type LinprogSolution
objv
sol
status
attrs # a dictionary to contain other relevant attributes such as lambda and colbasis
end In this way, users can enquire whether certain attributes are available and get them when they do. Of course, we can standardize the name for commonly used attributes. Also, I think the type of |
Some of these types can be immutable. But we can defer this later. |
@timholy: That's a good point, but the What if we add a @lindahua: Interesting idea. Given the interface for solver implementers, we could make a unified |
Alternatively we can make the solver-implementer interface very precise and Julian and push off the user friendly magic to a |
Let's continue this discussion on the mailing list: https://groups.google.com/forum/#!topic/julia-users/23PzvW_2nvs |
We can now switch to Gurobi with |
Add optional dependency and support for @lindahua's interface for Gurobi.
The text was updated successfully, but these errors were encountered: