ENH: Possibility to pass scipy.optimize.Bounds object to scipy.optimize.linprog about scipy HOT 8 CLOSED

I started with Matlab, too, and contributing to linprog (writing the original interior point method, then revised simplex, then helping wrap HiGHS) is what got me started working on SciPy, so I get it!

It is true that having both greater/ or lesser/ - then constraints, is an advantage and may be preferable on the long term, even in my specific case.

It should be quite easy to wrap your existing constraints in LinearConstraint objects. Something like:

from scipy.optimize import LinearConstraint
ub = LinearConstraint(A_ub, -np.inf, b_ub)
eq = LinearConstraint(A_eq, b_eq, b_eq)

and it sounds like you are already familiar with Bounds.

Then it's just milp(c, bounds=bounds, constraints=(ub, eq), where c is the same as with linprog.

from scipy.

Thank you very much, its very nice having one of the original developers helping out!

And I guess the rest will sort itself out in future versions of scipy, good luck with that! :)

from scipy.

Have you considered using scipy.optimize.milp? Under the hood, it uses essentially the same code, but it supports the use of Bounds and LinearConstraints. Your problem doesn't actually need to be a MILP to use it.

from scipy.

Indeed, the two methods seem to be very similar, but then wouldn't it be logical to allow for the usage of Bounds as an argument for linprog?

In my use-case i prefer the problem statement given by linprog as the problem has both the explicit inequality and equality constraints.

This proposition doesn't add much in the end. A bit more flexibility for the Bounds arguments and a bit more clarity in the documentation.

from scipy.

I'm +1 on having a consistent interface - but don't currently have enough spare time to implement it.

from scipy.

If we allow bounds to accept instances of Bounds, why not also add the ability to specify constraints with instances of LinearConstraint?

If we should, how would those be accepted - with a new argument used in parallel with Aeq, Aub, etc? Do we allow both the new argument and Aeq, Aub, etc. to be used at the same time?

Whatever the answers, my concern is that this adds to an already complex interface that has been updated incrementally over the past decade or so.

Personally, I've thought of milp as a successor to the linprog interface to HiGHS. It was given a new name (rather than changing linprog) because there was also demand for having a function named milp, but at the same time, it also allowed us to clean up the interface without having to tiptoe around backward compatibility concerns.

From this perspective, no, I don't think it is required to keep the linprog interface in sync. Rather, I see it as a reason to add only to milp, and perhaps unify the two in a SciPy 2.0.

I know this isn't the only perspective - others see an advantage to having a separate function specifically for linear programming without integrity constraints. That's fine. I'm just trying to responding to why I would not personally invest time into updating linprog.

from scipy.

I am currently struggling to come up with a consistent interface for the SLSQP rewrite. There are lots of tiny helper functions here and there from the actual function input to SLSQP solver mostly regarding the bounds objects. I agree with @mdhaber that the interface is very tedious and every one of them fix some obscure issue from the last decades. So over the years, necessarily, it became a band-aid tower apparently (it is a similar story in all modules of varying degree).

If there is a unified way to get rid of old bounds in a backwards compatible way before SciPy 2.0, I'm +1 for it. I just don't have enough experience around the optimize codebase hence can't form an opinion about the effort needed.

Regarding the milp, I think problems with integral constraints are sufficiently different than regular problems (also tend to be pseudo-separate discipline) that might warrant a separate function. Though we have not heard much about this distinction here or elsewhere online so probably a minor point.

from scipy.

Thanks for the clarification, I wasn't aware of a future interface change for HiGHS.

I will try rewrite my problem for milp. It is true that having both greater/ or lesser/ - then constraints, is an advantage and may be preferable on the long term, even in my specific case.

And if linprog is only kept for backwards compatibility reasons than it seems not to be the best place where to spend time. + My preference may come from the large pool of Matlab users around me that use the function of the same name.

So I think this issue can be closed.

from scipy.