HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
62% Positive
Analyzed from 1629 words in the discussion.
Trending Topics
#solvers#problems#solver#problem#scheduling#solution#more#timefold#etc#mip

Discussion (38 Comments)Read Original on HackerNews
This doesn't solve or provide guidance for the subtle problems in these otherwise opensource solvers... The first example requires the client to manually disambiguate equivalent variables to get a stable solution... Sure that's a pretty common problem everyone working with optimizers should be familiar with but they're also one of the hardest things to track down in a complex derived model.
If it handles explainabily, what-if scenarios and insights to fulfill business needs.
And that's where supporting many solvers becomes the blocker.
A lowest common denominator design.
Those solvers are a black box. They don't expose what they're running, why they made certain decisions or how they can scale to large datasets or complex business requirements.
We've picked our poison: one solver, which we've built in the open, in the last 20 years, versatile enough to handle any scheduling problem. That delivers.
Many of them, including Timefold, lack a realistic, financially grounded model of the world. They do not adequately account for traffic, driver preferences, or other factors that require a continuous feedback loop between what actually happened in practice and what the optimizer expected to happen.
A vehicle-routing problem without real-world feedback is little more than a gimmick. Even assuming the world could be modelled perfectly, what happens when an unpredictable event disrupts the plan? Is the supposedly “globally optimal” solution robust enough to adapt, or will it create a backlog that forces the business to hire additional workers because the system failed to build in sufficient redundancy?
Using MILP makes the system even less flexible.
Neither our clusters in the US or EU can afford to go down for a minute, or business operations in logistics, retail and healthcare are impacted.
> They do not adequately account for traffic, driver preferences, or other factors that require a continuous feedback
- Traffic: supported
- Driver preferences: the APIs support
-- Area affinity (soft) and geo fencing (hard)
-- Fairness and load balancing of work (soft)
-- Overtime (soft and hard)
-- Seniors not doing boring junior tasks (soft)
- Continuous feedback: the APIs support
-- Real-time rescheduling (warm starts) as actual execution data comes in.
-- Recommend assignment: scheduling in survival mode
-- Pinning: user stays in control through overriding assignments
-- Explainability: why a certain decision was made
-- Insights: what are the bottlenecks in my schedule - what type of employees should I hire or upskill.
Often, the difference on "harder" problems is 10x or more.
I have problems that gurobi solves in 30 seconds that take 15 minutes or more for ~every non-commercial solver (or-tools, HIGHS, ipopt, etc).
But right now, this wouldn't even be interesting to me to use even if they actually were fronting commercial solvers, because they can't actually run it any faster and having this ".solve" API does nothing - pyomo already does that for me in practice.
So you use NEOS, but another service offering the same thing as NEOS would not be useful?
That's our Solver as a Service for scheduling problems (vehicle routing problem, shift scheduling, job scheduling, etc). It runs scheduling problems implemented with our open source solver: solver.timefold.ai
But this post is such a service for formula problems instead (think master capacity planning, portfolio optimization, etc), due to the choice of MILP solvers underneath. Similar to NextMv, Neos, etc.
I created a json like schema/struct/whatever to describe the problem. Maybe adopt something like this and more people will be able to see how they could use your tool:
https://github.com/JWally/jsLPSolver/blob/master/API.md
I need to re go through the docs, but you get the gist.
Here is the Berlin Airlift problem for example:
const model = { optimize: "capacity", opType: "max", constraints: { plane: { max: 44 }, person: { max: 512 }, cost: { max: 300000 }, }, variables: { brit: { capacity: 20000, plane: 1, person: 8, cost: 5000 }, yank: { capacity: 30000, plane: 1, person: 16, cost: 9000 }, }, };
Misc thoughts:
- I'm not familiar with the LABS problem, but the LABS benchmark page is interesting & compares against Gurobi. I'd be curious to see how an existing commercial non-mip approximate solver such as Hexaly (formerly LocalSolver) compares here.
- the other two benchmarks aren't very convincing as they don't compare against other methods or show running times
- the front page mentions peer reviewed methodology - consider linking to the publications
- good idea to have case studies of applications. I was a bit confused to see this listed under 'References' but on comparison the Gurobi & Hexaly marketing websites also do this (references -> case studies & references -> customer stories, respectively)
- re the client API, you may want to make the server URL have a default, so your trial users / customers don't have to specify it. It may be easier for you to roll out changes to your server URL in future if you can do it by changing the default server URL in a new version of your client library rather than requiring your customers to update their source code.
All the best!
Hexaly claims to go far beyond MIP. Amazon uses it for packing VMs into servers. This video by one of their research scientists was widely circulated at the time [1].
I work on combinatorial optimization too but a specific problem so we write the heuristics from scratch. Seems exact solvers are doing a lot more these days?
[1] https://www.youtube.com/watch?v=GIh6d3rb0_4
If there were evidence that it offered better performance, I might consider running larger workloads on it.
https://plato.asu.edu/guide.html
Their website has just 3 cherry picked instances and claim complete dominance.
But they are not representive of the real world, at all.
The Mittelman VRPLib benchmarks have only 1-2 constraints. Skills? No need. Working hours? Unlimited. Maps integretion? Cars can fly and the earth is a flat Euclidean space.
Any VRP algorithm optimized for the vrplib datasets is overfitted and not the best one in reality.
Take HGS for instance. Brilliant for CVRPTW. Crumbles to dust in field service routing for telco operations etc.
OR-tools is almost exclusively linear programming which according to its strict assumptions converges more or less trivially, assuming a correctly composed program.
Which means if you're paying for it "as a service" you all but deserve to lose that money.
> Different algorithms are better for different problems
So... why does your rhetorical style have such oppositional tone if you're just going to reaffirm the no free lunch theorem?
Some our customers want to go even higher, and we're working on that.