The JuMP paper [1] compares JuMP with all the major commercial and open source options in this area, including Pyomo. Pyomo is orders of magnitude slower than JuMP and doesn't scale as well so the comparison gets worse as problems get larger. (Pyomo had the worst performance of all the systems compared.) JuMP is the only open source option that has performance like commercial systems. Throw in JuMP's improved expressiveness and usability over Pyomo and JuMP's incredibly broad solver support [2] and there's really no contest. These days, your best option in Python is probably to call JuMP via pyjulia.
Not sure how much performance matters here. You're just farming it off to CPLEX or Gurobi anyway. If performance really matters, you'll do this part in C++ anyway.
Unless you're solving toy problems, it matters quite a bit. In mathematical optimization, constructing the problem tends to be just as expensive as solving the problem is – sometimes more so. The existence of expensive commercial systems like AMPL and GAMS that only exist to express optimization problems demonstrates that this is a non-trivial issue that people are willing to pay money for. Using C++ APIs to solvers is extremely painful, inflexible, error-prone, and completely locks you into a specific solver.
> Unless you're solving toy problems, it matters quite a bit. In mathematical optimization, constructing the problem tends to be just as expensive as solving the problem is – sometimes more so.
With all due respect, this is just false. I can construct a million dimensional linear program for a large network problem in a few seconds in python. Solving it with cplex can take minutes.
I have a Ph.D. in computational mathematics and do this for a living. I write lots of C, and still almost exclusively use Python or Lua for problem formulation because the performance just doesn't matter.
I'm certain there are some cases where it's true. One I've encountered is doing real-time solution of MILP for adaptive path planning. Here the problems are of moderate size and you want to reconstruct them from geometry data every 10ms or so. Here Python will indeed bite you in the problem formulation stage.
Solver licenses are extremely expensive (~100k in production), so switching solvers isn't very common. Going to C++ helps a bit with I/O before it gets to the solver if you really need it, but a lot of people do just fine with things like AIMMS which is a proprietary high level modeling language similar in performance to Python. Maybe Julia + JUMP is nice if you want to remove I/O performance barriers, but don't want C++ pain & more flexibility, but I don't see JUMP being talked about much in the industry currently. If you don't mind me asking, what is your experience in this area and what domain are you working in?
Stefan is one of the co-creators of the Julia language, not really an operations research person. He must have misread the results in the JuMP paper where Pyomo outperforms CVX and Yalmip on several problem classes.
You're right, I was looking at the lqcp results and misread the other results. Still, the main takeaway is that of the open source options for expressing OR problems, JuMP is the only one in the same class as the commercial tools. If you've got a problem where problem construction isn't hard, cool; often that's not the case.
Can you share an example of calling JuMP directly via pyjulia? I was under the impression that Julia macros are not currently callable from Python via pyjulia.
