HN user
I guess it depends on what your application is here. Hexaly primarily focuses on Routing, Packing and Scheduling problems, which have strong Combinatorial components. My experience with those type of problems is that Hexaly is in its own league above the MIP solvers, especially at scale. For applications like portfolio optimization or network design MIP solvers still fare a lot better.
The main reason why companies might prefer Hexaly is their emphasis on quickly finding high Quality feasible primal solutions.
Amazon has been quite vocal about using Hexaly.
I cant speak for engineers, but as a mathematician I wholeheartedly disagree with everything you claim in your comment. Almost none of the mathematicians that I know care about the optimization aspect of mathematics: the pursuit of optemizing constants in theorems and providing minor technical improvements is mostly seen as pointless unless there are significant new mathematical insights that fuel the improvement. I think most mathematicians rather build their identity around providing actual understanding of problems using mathematics and improving society's understanding of mathematical problems.
Of course AI threatens this too, but the threat is of a much lesser degree. One could even argue that AI is helpful here with getting mathematicians to the 'frontier of knowledge' as AI is usually good in combining ideas from different fields.
I would like to learn more about Web development and related knowledge (networking, security). Currently my programming knowledge is primarily system languages+python. I'm thinking of building a few websites / apps from scratch, and perhaps hosting my own server. Recommendations for frameworks or do's/don'ts are very welcome.
Second thing is networking skills at my (future) job. One thing I regret from my PhD is not seeking collaborators out more actively and building my network. Although I'm moving to industry, I've realised that having a strong professional network is vital for job security and can make the job much easier and more fun.
This is actually a pretty poor example because we can solve huge TSP instances to optimality in practice (see the concorde solver). There exist many more tricky Combinatorial problems such as packing or covering problems that are typically much harder to solve to optimality.
CPlex has shown no progression in the benchmarks in the past years, so it is safe to assume that the number of developers they have employed is either 0 or maybe 1.
I am an academic in the field. A good starting point would be Tobias Achterberg's PhD thesis:
"Constraint Integer Programming"
It details the implementation of SCIP, which is one of the leading open source solvers, and explains some of the most important tricks.
That said, there is a lot of literature out there; if you're interested in a particular aspect like e.g. presolving or cutting planes, then feel free to ask me further questions. It is worth noting that the implementation specifics are hidden by the top commercial solvers, so these are difficult to find anywhere
Yes, there are other interior point methods besides the ellipsoid method, and virtually all of them perform better for linear programming. Sometimes, the solvers will use these at the root node for very large models, as they can beat out the simplex algorithm. However, I am unsure if any of them has been proven to run in polynomial time, and if so, if the proof is significantly different from the proof for the ellipsoid method. The point I was mainly trying to make is that there can be a significant gap between practice and theory for ILP. Even 40 years after LP was proven to be polytime solvable, simplex remains the most widely used method, and it is very hard for other methods to catch up.
As other commenters here have mentioned, in discrete optimization there can be a very large gap between efficienct in theory and efficient in practice, and it is very likely that this is the case here too. Linear programming for example is known to be solvable in polynomial time, but the algorithm which does so (the ellipsoid method) is not used in practice because it is prohibitively slow. Instead, people use the (exponential time worst-case) simplex method.
Modern ILP solvers have a huge number of heuristics and engineering in them, and it is really difficult to beat them in practice after they have optimized their branch-and-cut codes for 30 years. As the top comment mentions, the software improvements alone are estimated to have improved the solving time of practical ILP instances by a factor of 870'000 since 1990.