Ask HN: Do you use an optimization solver? Which one? Do you like it?
61–70 of 158 posts
Re: Ask HN: Do you use an optimization solver? Which one? Do you like it?
#62I loved the JuMP package in Julia for being able to write models once, then swap in different solvers. Most open-source solvers don't handle parallelization well, and they lack the latest research on techniques like branch-cutting and heuristics that can speed things up significantly. In my experience, Gurobi is still leader for linear and MiP solving. But, it's really expensive and the licensing terms seem anachroni…
I love JuMP too. I am very amateur when it comes to optimization, but I found it to be a very efficient way to describe a matching algorithm for a post card exchange I ran (think of it as a Secret Santa, but generalized to each person sending multiple gifts, and discouraging mutual exchanges.) Here's the code: https://twitter.com/paulgb/status/1462483698427781120 To OP's question, besides JuMP, the other use case I'v…
> link to twitter
visible_confusion.png.jpg.exe
Re: Ask HN: Do you use an optimization solver? Which one? Do you like it?
#63At Zoba we use CLP, CBC, NLOpt, and OR-tools. Used to use Gurobi. * CLP/CBC: open source makes deployment and devops easy, which is great. Linear models are nice in that you "know what you're getting." Performance is at times a pain point. * Gurobi: super fast, but the licensing was just impossible. Partly that was due to high cost, but ultimately we could have borne the cost; the inability to do something like have…
Gurobi, AFAIK, is considered the leading edge of the field, and other tools, especially open-source ones, do not perform as well.
I cannot speak specifically for your firm and use cases, but in my experience, if the use cases are structured and specific enough, rolling out a in-house optimizer is not such a bad idea.
Re: Ask HN: Do you use an optimization solver? Which one? Do you like it?
#64At Zoba we use CLP, CBC, NLOpt, and OR-tools. Used to use Gurobi. * CLP/CBC: open source makes deployment and devops easy, which is great. Linear models are nice in that you "know what you're getting." Performance is at times a pain point. * Gurobi: super fast, but the licensing was just impossible. Partly that was due to high cost, but ultimately we could have borne the cost; the inability to do something like have…
NextMV was practically the opposite (at the time, I'm sure it has improved now, especially since they used to be far more insistent on decision diagrams): rather bad/terrible performance, but excellent in terms of licensing and deploying the code, and they had great support too. The modern deployment made sense given they were a new/modern company. One silver lining to the terrible performance, and why I used to stick up for them at the time was that you could get somewhat acceptable results fast: if you stopped after one second, CBC might be absolutely nowhere, but NextMV's solver would at least give you something. This meant you could do things that made use of extremely fast results, like trying a configuration and checking the (approximate) solution, then trying a bunch more, all very quickly.
In the end I mostly settled on OR-Tools.
Re: Ask HN: Do you use an optimization solver? Which one? Do you like it?
#65Re: Ask HN: Do you use an optimization solver? Which one? Do you like it?
#66Re: Ask HN: Do you use an optimization solver? Which one? Do you like it?
#67I would love to use one or more but the process to convert business logic to solver is painful so I ended up having to write a simulated annealing algo in Rust instead. I tried solver.com, Google OR-Tools, and a few other utilities. It was much easier to build a score-calculator for min/max based on user-tweaked parameters, then, jiggle the data, re-calculate score, and keep doing it until there was significant impro…
It really feels like a tools or language problem. Heck, we used to have to manually work out derivatives for continuous optimization problems, but nowadays programming languages with performant built-in autodiff often make this trivial. Removing the manual derivation hassle let loose a flood of cool ideas and applications, even though there was no technical hurdle preventing them in the first place.
Alternate problem specifications is a well-explored area (what is Prolog if not a way of describing problems for a constraint satisfier?), but I wonder how many other neat things are dammed up behind usability problems.
Re: Ask HN: Do you use an optimization solver? Which one? Do you like it?
#68General solvers:
- LocalSolver: good docs, reasonable pricing, docs make it sound fast
- ORTools: Open source, we we're leaning towards this since we're not doing anything incredibly fancy and it'd be nice to embed the solver in our server.
- Gurobi: major player in the space, will charge you an arm and a few legs.
Vehicle routing specific solvers were covered in absolutely outstanding detail by "Open Source Routing Engines And Algorithms – An Overview" [1].
We were leaning towards ORTools since we didn't want to get charged by number of jobs or compute. LocalSolver also seemed promising.
Also, is there a cost-efficient way to get distance matrices for ~50 stops? Google maps and Mapbox are wicked expensive. Is PostGIS reasonable?
[1]: https://gis-ops.com/open-source-routing-engines-and-algorith...
Re: Ask HN: Do you use an optimization solver? Which one? Do you like it?
#69Re: Ask HN: Do you use an optimization solver? Which one? Do you like it?
#70After several years of exploring, my current gotos are: * Minion for IP for scheduling + edge crossing minimization. * cvxpy (wrapping ECOS, OSQP, and SCS by default) for convex optimization for making nice geometry. * Z3 and STP for SAT/SMT for program analysis. All are FLOSS, which is my main criterion in many situations. Beyond that, I like minion for its focus on only providing efficiently implementable primitive…