Next week the 25th International Symposium on Mathematical Programming will take place in Montreal. MOSEK is a proud sponsor of this conference. We will also have a presence at the conference.
If you have inquiries about MOSEK that you want to address in person, your best bet is to look out for our CEO Erling D. Andersen at the conference.
If your happy with having your inquiry answered through email you can always reach out to support@mosek.com.
This week starting on Wednesday June 26 EUROPT 2024 will be held at Lund university, hosted by the Department of Automatic Control.
Moseks industrial phd student Utkarsh, along with his academic supervisor Martin S. Andersen, will be hosting a track on developments on the interior point method.
So if you are attending the conference and want to know more about Mosek, and maybe get your hands on a hard copy of our Modelling Cookbook, keep on eye out for Utkarsh!
If you're not attending the conference you can always find our cookbook online and reach us at support@mosek.com or sales@mosek.com if you have any inquires.
Let's say we have a well scaled optimization problem with a very good and robust primal-dual optimal solution, which solves without any numerical difficulties. It could be a linear problem in standard form $$\begin{equation}\begin{array}{ll}\textrm{minimize}&c^Tx\\ \textrm{subject to}& Ax\leq b,\end{array}\end{equation}$$ where the primal solution $x$ and dual solution $y$ are of reasonable magnitude and satisfy $Ax\leq b$, $y\geq 0$, $A^Ty+c=0$, $b^Ty=c^Tx$ with the best achievable precision. In other words, everything is as nice as it could be.
Obviously (right?) nothing should change if we extend the problem with huge bounds on $x$, so large that they are completely redundant for the given problem: $$\begin{equation}\begin{array}{ll}\textrm{minimize}&c^Tx\\ \textrm{subject to}& Ax\leq b,\\ & x\leq M.\end{array}\end{equation}$$
To see what might go wrong let us first understand what the solver might think about problems whose feasible set lies very far out. The simplest example might be $$\begin{equation}\begin{array}{ll}\textrm{minimize}&x\\ \textrm{subject to}& x=10^{12}.\end{array}\end{equation}$$ with the optimal solution $x=10^{12}$. But is that problem feasible from a practical perspective? If we work in the realm of practical applications with solutions of reasonable magnitude, then one might argue that this simple problem is for all intents and purposes infeasible, since the first feasible point lives further than we care to look. This can be made precise using Farkas lemma: the infeasibility certificate for this problem would be a value $y$ such that $y\leq 0$ and $10^{12}y=1$. A very good practical example of such a $y$ is $y=10^{-12}$ - it violates the conditions by only $10^{-12}$, failing to satisfy $y\leq 0$ by this narrow margin. This was just a toy example, but it easy to imagine that for a nontrivial optimization problem the solver might converge either to a solution or to such an infeasibility certificate, both of great quality! That makes problems with large solutions potentially hard to numerically distinguish from infeasible.
The same logic can now be applied to the problem (2) with redundant large bounds. The infeasibility certificate for it will be a pair of vectors $y,\tilde{y}$ such that $$A^Ty+\tilde{y}=0,\quad b^Ty+M\cdot \mathbb{1}^T\tilde{y}=-1,\quad y\geq 0,\quad \tilde{y}\geq 0.$$ If we let $y$ be the dual solution to the original problem (1) then by choosing a very small negative $\tilde{y}$ (in the order of $M^{-1}$) we can easily satisfy the second condition in (4), while the first and fourth one will only be violated by a tiny amount (of order $\tilde{y}$). As counterintuitive as it might be the math works out and we get certificate of primal infeasibility perfectly acceptable in finite precision arithmetic, with only tiny violations.
The rule of thumb one can remember connecting examples (2) and (3) is the following: the bound $x\leq M$ can be written in equality form as $x+\tilde{x}=M,\ \tilde{x}\geq 0$, so even with reasonable values of $x$ we get that the value of $\tilde{x}$ in any solution must be huge, putting us in position of example (3).
Similar considerations apply to distinguishing primal and dual infeasibility from feasibility in the case of large coefficients in the objective and other scaling problems; this applies for instance to big-M models in integer optimization, large penalties etc.
Will this come up in practice? Yes. Perhaps not for simple linear problems and with the extensive presolve MOSEK has, but it is not hard to set up a relatively straightforward conic problem, solve it, add huge bounds, turn presolve off and see MOSEK return a high quality infeasibility certificate. We leave these experiments to the reader.
MOSEK 10.2 ships with the licensing software (FlexLM) upgraded to version 11.19.6. This has two implications.
Have a look at the installation manual for the token server and the release notes for MOSEK 10.2.
MOSEK 10.2 introduces a feature that we hope will be interesting for all users of our Python Fusion API, which we call Pythonic Fusion.
Pythonic Fusion is an overlay on top of the current Fusion API (or, as some would call it, syntactic sugar) which implements standard Python operators for Fusion objects (variables, parameters, expressions). There are operators for manipulating linear expressions:
+, -, *, @, [:], .T
relational operators for introducing constraints:
==, <=, >=
and operators for introducing AND- and OR-clauses in disjunctive constraints:
&, |
The operators are used in the most natural way familiar from NumPy, CVXPY, Pandas or any other data processing tool in Python, so we restrict to giving a simple example. The following Python Fusion constraint
M.constraint(Expr.mul(G, Expr.sub(x.transpose(), y.slice(0, n))), Domain.lessThan(c))
will be written in Pythonic Fusion as
M.constraint(G @ (x.T - y[:n]) <= c)
A more comprehensive introduction to the new syntax can be found in the manual. Examples using Pythonic Fusion are scattered throughout the manual, in particular in the portfolio optimization case study, and with time we will adapt our other Python Fusion resources to the new syntax. You are welcome to share your suggestions, comments or bug reports with us.
Important. In MOSEK 10.2 Pythonic Fusion is a separate add-on, available only after importing:
import mosek.fusion.pythonic
Due to Easter support and sales will be closed from Thursday, March 28th, until Monday, April 1st, both days inclusive.