Wednesday, May 22, 2024

Mosek 10.2 and floating licenses

MOSEK 10.2 ships with the licensing software (FlexLM) upgraded to version 11.19.6. This has two implications.

  • On Linux, the new floating license server drops the long-lasting dependency on the LSB (Linux Standard Base) package. In particular, it can be installed on Linux distributions without LSB, primarily RHEL9 and Debian.
  • All floating license users who want to upgrade the clients to Mosek 10.2 must also upgrade the token server to one from Mosek 10.2, as the new clients will not talk to older token servers. As always, an upgrade of the token server does not affect older Mosek clients which will continue to work. See the licensing manual for more info.

Have a look at the installation manual for the token server and the release notes for MOSEK 10.2.

MOSEK 10.2 and Pythonic Fusion API

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


Tuesday, March 26, 2024

Easter 2024

 Due to Easter support and sales will be closed from Thursday, March 28th, until Monday, April 1st, both days inclusive.


The MOSEK team wishes everyone a peaceful Easter.

Thursday, March 14, 2024

Pi day and the geometric mean cone

Happy Pi Day! If Euler wasn't so keen on complex numbers then instead of $e^{i\pi}+1=0$ he would certainly have declared $$\pi^3+1=2^5$$ as the most beautiful equation. (Both sides indeed equal $32.0$). We can easily give a formal proof of this identity with MOSEK. Note that we need to simultaneously prove two inequalities $$\sqrt[3]{31}\geq \pi\quad \mathrm{and}\quad \sqrt[5]{\pi^3+1}\geq 2.$$ In MOSEK we have the geometric mean cone of dimension $n+1$: $$\mathcal{GM}^{n+1}=\{(x_1,\ldots,x_n,t)~:~x\geq 0, (x_1\cdot\ldots\cdot x_n)^{1/n}\geq |t|\},$$ so all we need to check is the feasibility of the conic problem $$(31,1,1,\pi)\in\mathcal{GM}^4,\quad (\pi^3+1,1,1,1,1,2)\in\mathcal{GM}^6.$$ This is straightforward with, for instance, Python Fusion:

M.constraint(Expr.constTerm([31, 1, 1, pi]), 

             Domain.inPGeoMeanCone())

M.constraint(Expr.constTerm([pi**3+1, 1, 1, 1, 1, 2]), 

             Domain.inPGeoMeanCone())

and voila! here is our proof:

Interior-point solution summary
  Problem status  : PRIMAL_AND_DUAL_FEASIBLE
  Solution status : OPTIMAL
  Primal.  obj: 0.0000000000e+00    nrm: 1e+00    Viol.  var: 0e+00    acc: 1e-04  
  Dual.    obj: 0.0000000000e+00    nrm: 0e+00    Viol.  var: 0e+00    acc: 0e+00

Bonus question for the advanced user: which Mosek parameters do you have to modify to get this answer? Can you get away with only modifying one parameter by not too much? You can try to run it and find out yourself here.

Wednesday, March 6, 2024

Ferrari, factorizing, and portfolios in conic form

1. Suppose we want to solve the equation $$\begin{equation*}(x^2-3x+2)(x-3)(x-4)=0.\end{equation*}$$ The straightforward approach is to multiply everything out: $$\begin{equation*}x^4-10x^3+35x^2-50x+24=0\end{equation*}$$ and use the algorithm for solving a general 4-th degree equation discovered by Lodovico Ferrari, an Italian mathematician, around 1540. The procedure is pretty involved, requires solving auxiliary 3-rd degree equations and other operations. Luckily it can be summarized in explicit formulae for the quartic roots, which we don't quote here due to restricted space. Having gone through this ordeal we get, for example, that one of the four roots is $$\begin{equation*}x_1=\frac{-1}{6} \sqrt{6} \sqrt{\frac{\left(\frac{1}{2}\right)^{\frac{2}{3}} \left(\left(\frac{1}{2}\right)^{\frac{2}{3}} \left(36\sqrt{-3}+70\right)^{\frac{2}{3}}+5\left(\frac{1}{2}\right)^{\frac{1}{3}} \left(36\sqrt{-3}+70\right)^{\frac{1}{3}}+13\right)}{\left(36\sqrt{-3}+70\right)^{\frac{1}{3}}}}-\frac{1}{2} \sqrt{\frac{-1}{3} \left(\frac{1}{2}\right)^{\frac{1}{3}} \left(36\sqrt{-3}+70\right)^{\frac{1}{3}}-\frac{\frac{26}{3} \left(\frac{1}{2}\right)^{\frac{2}{3}}}{\left(36\sqrt{-3}+70\right)^{\frac{1}{3}}}+\frac{10}{3}}+\frac{5}{2}\end{equation*}$$ which numerically evaluates to $x_1\approx 1.00 - 1.38\cdot 10^{-17}i$ and with some good faith we conclude $x_1=1$. We obtain the other three roots similarly.

Of course you wouldn't do it that way. You would exploit the fact that your equation already comes almost completely factored, the small quadratic part $x^2-3x+2$ is easy to factor as $(x-1)(x-2)$ with standard school math, so we have $$\begin{equation*}(x-1)(x-2)(x-3)(x-4)=0\end{equation*}$$ and we get all the solutions for free, exactly. The only reason we used the previous method is because we thought we first have to reduce the problem to some standard form and then use it as a black-box. The black-box, however, is unnecessarily complicated for what we need here, introduces noise, and ignores the additional structure we started with so a lot of wasted work is done to go back and forth.

You can read more about the twisted story of Ferrari and his mathematical duels over polynomial equations online, for instance in this article.


2. Suppose we want to optimize a portfolio with a factor covariance model of the form $\mathrm{diag}(D)+V^TFV$, with assets $x\in \mathbb{R}^n,\ (n\approx 3000)$, where $D\in \mathbb{R}^{n}$  is specific risk, $F\in \mathbb{R}^{k\times k},\ (k\approx 40)$ is factor covariance and $V\in \mathbb{R}^{k\times n}$ is the matrix of factor exposures. The straightforward approach is to multiply everything out, in pseudocode:

Q = diag(D) + V.T @ F @ V

and use the algorithm for optimizing a general quadratic problem:

risk = sqrt(quad_form(x, Q))

The procedure is pretty involved, requires checking that the matrix $Q\in \mathbb{R}^{n\times n}$ is positive-semidefinite, which at this size is prone to accumulation of numerical errors and can be time consuming (even though we know very well $Q$ is PSD by construction). Simultaneously the modeling tool and/or conic solver will need to compute some decomposition $Q=U^TU$. Having gone through this ordeal, the solver will finally have the risk in conic form

risk = norm(U@x)

albeit working with a dense matrix $U$ with $n\times n\approx 10^7$ nonzeros will not be optimal for efficiency and numerical reasons. We finally obtain the solution.

Of course you wouldn't do it that way. You would exploit the fact that your risk model already comes almost completely factored, the small factor covariance matrix $F\in \mathbb{R}^{k\times k}$ is easy to factor using standard Cholesky decomposition as $F=H^TH$, $H\in\mathbb{R}^{k\times k}$, and we get a conic decomposition of risk for free: $$\begin{equation*}x^T(\mathrm{diag}(D)+V^TFV)x=x^T(\mathrm{diag}(D)+V^TH^THV)x=\sum_i D_ix_i^2 + \|HVx\|_2^2,\end{equation*}$$ or in pseudocode:

risk = norm([diag(D^0.5); H @ V] @ x)

The matrix $HV\in \mathbb{R}^{k\times n}$ has $kn\approx  10^5$ nonzeros (a factor of $n/k\approx 100$ fewer than before) and everything else is very sparse so we get the solution very quickly and with high accuracy. The only reason we used the previous method is because we thought we first have to formulate a general quadratic problem and then solve it as a black-box. The black-box, however, is unnecessarily complicated for what we need here, introduces noise, and ignores the additional structure we started with so a lot of wasted work is done to go back and forth.

You can read more about the efficient conic implementation of the factor model in our Portfolio Optimization Cookbook, the documentation, a CVXPY tutorial and other resources.

Monday, February 26, 2024

New Portfolio Optimization Cookbook chapter and notebook

We are happy to share that our Portfolio Optimization Cookbook has been updated with a new chapter about regression. As always the new chapter is accompanied by a notebook with an illustrative code example implemented in MOSEK Fusion for Python.

Enjoy! 

Monday, February 19, 2024

New third party interfaces to MOSEK

Recently we added PyPSA and linopy as third party interfaces to MOSEK.

PyPSA stands for Python for Power System Analysis. It is pronounced "pipes-ah. It is a toolbox for simulating and optimizing modern power systems. 

PyPSA utilizes linopy to connect to solvers, such as MOSEK. But linopy can also be used on its own. It is designed to be a link between data analysis frameworks, such as pandas and xarray, and optimization solvers, like MOSEK.  

A full list of available third party interfaces to MOSEK can be seen here. If you feel like the list is not complete, whether it is an existing interface that is missing or an interface that you wished existed, let us know! This is easiest done by contacting support@mosek.com.