Showing posts with label optimization. Show all posts
Showing posts with label optimization. Show all posts

Wednesday, June 22, 2022

On the performance improvement of the semi-definite optimizer when switching from version 9 to 10

The most reason Mosek version 10.0.16(beta) includes a very significant improvement of the optimizer for semi-definite problems. The improvement is most notable for problems having many matrix variables. In order to illustrate the potential performance gain we use a problem supplied by Mosek user. Some statistics about the problem can be seen in the Mosek log output:


Optimizer  - solved problem         : the primal
Optimizer  - Constraints            : 8808
Optimizer  - Cones                  : 0
Optimizer  - Scalar variables       : 0                 conic                  : 0
Optimizer  - Semi-definite variables: 49                scalarized             : 76493
Factor     - setup time             : 8.26              dense det. time        : 0.00
Factor     - ML order time          : 0.50              GP order time          : 0.06
Factor     - nonzeros before factor : 3.38e+07          after factor           : 3.38e+07
Factor     - dense dim.             : 0                 flops                  : 2.45e+11
Factor     - GP saved nzs           : 4.97e+06          GP saved flops         : 4.60e+10
Hence, the problem has 8808 constraints and 49 matrix variables. In addition it should be mentioned that the contraint matrix is not that sparse.

Below the computational results is shown.

CPU 9.3.20 9.3.20 (MT) 10.0.16 10.0.16 (MT)
Intel Xeon Gold 6126 (12 core) 1165 1171 833 207
AMD EPYC 7402P (24 core) 1189 1049 777 108
The table shows the computational time in wall clock seconds for running version 9.3.20 and 10.0.16 single and multi-threaded respectively. Moreover, the timing result is shown for an Intel and an AMD CPU.

The main conclusions from the table are

  • version 10 is much faster than version 9 and the difference is more notable on the AMD CPU.
  • version 10 offers much better speed-up when using multiple threads. In fact there are virtually no speed-up when using multiple threads in version 9.
It should emphasized that the performance improvement for solving semi-definite problems when switching from version 9 to version 10 is dependent on the structure of the problem. However, as illustrated above a big performance boost can be realized for some problems.

PS. Despite the AMD CPU being the fastest in the table above then this post do not claim AMD CPUs are better than Intel CPUs or the other way around.

Tuesday, December 16, 2014

MOSEK 7.1 released!

We are happy to announce that MOSEK version 7.1 has been released!


After several weeks as beta version, MOSEK 7.1 has now be promoted as the new stable version we provide to MOSEK users. Some of the new features are 

  • Updated mixed-integer conic optimizer with improved performance.
  • Updated MPS reader with support for the CPLEX format
  • The default MPS format has been changed to the free MPS format.
  • Experimental support for reading the conic benchmark format. Semidefinite constraints and variables are not supported yet.
  • A new experimental feature for reformulating certain quadratically constrained into a conic problem.
  • In Fusion it is now possible to obtain optimizer statistics e.g. mixed integer gap etc.
  • Added some of the BLAS and LAPACK functionality e.g. gemm and potrf functions.

Grab your copy from our website


Licenses for MOSEK 7 are still valid. And remember you can easy obtain an academic or commercial trial license with few clicks!


Tuesday, October 7, 2014

Slides from our workshop on SDP preprocessing.

We would like to thank to our guest for the nice workshop held yesterday here at our site. Etienne, Frank and Joachim have given three nice and interesting talks on cutting edge technique for the preprocessing of semidefinite programs. 

Click on the links below to download the slides:

Title: Exploiting special structure in semidefinite programs
Speaker: Etienne De Klerk, Tilburg University (NL)


Title: Partial facial reduction: simplified, equivalent SDPs via approximations of the PSD cone
Speaker: Frank Permenter, MIT (US)

Speaker: Joachim Dahl, MOSEK ApS (DK)



We hope to see all of you soon, possibly at the INFORMS meeting in November!

Thursday, September 4, 2014

Seminar on "Preprocessing semidefinite optimization problems"

We are please to announce that on October the 6th 2014 a series of seminars titled "Preprocessing semidefinite optimization problems" will be held at MOSEK site in the Symbion research park

Three prominent experts of the field, namely E. De Klerk, F. Permenter and J. Dahl, will discuss recent advances and applications on semidefinite optimization problem preprocessing.

Participation is free and everybody is welcome, but for logistic reasons we would like you to register here. Refreshment will be served. Detailed titles and abstracts can be found at the end of the page.

Schedule of the day:

15:00 - 15:05 Introduction
15:05 - 15:50 E. De Klerk,
 Tilburg University (NL)
15:50 - 15:55 Break
15:55 - 16:40 F. Permenter, MIT (US)
16:40 - 16:45 Break
16:45 - 17:15 J. Dahl, MOSEK ApS (DK)
18:00 Optional networking at Nørrebro Bryghus.


We hope to see you!

Contact: info@mosek.com
How to get there: check information on the Symbion website

How to register: fill the form below or click here






-----------------------------------------------------------------------------------------



Title: Exploiting special structure in semidefinite programs
Speaker: Etienne De Klerk, Tilburg University (NL)

Abstract: Semidefinite Programming (SDP) may be seen as a generalization of Linear Programming (LP). In particular, one may extend interior point algorithms for LP to SDP, but it has proven much more difficult to exploit structure in the SDP data during computation. We survey three types of special structure in SDP data:
  • a common `chordal' sparsity pattern of all the data matrices. This structure arises in applications in graph theory, and may also be used to deal with more general sparsity patterns in a heuristic way.
  • low rank of all the data matrices. This structure is common in SDP relaxations of combinatorial optimization problems, and SDP approximations of polynomial optimization problems.
  • the situation where the data matrices are invariant under the action of a permutation group, or, more generally, where the data matrices belong to a low dimensional matrix algebra. Such problems arise in truss topology optimization, particle physics, coding theory, computational geometry, and graph theory.


Title: Partial facial reduction: simplified, equivalent SDPs via approximations of the PSD cone
Speaker: Frank Permenter, MIT (US)

Abstract: We develop a practical semidefinite programming (SDP) facial reduction procedure that utilizes computationally efficient approximations of the positive semidefinite cone. The proposed method simplifies SDPs with no strictly feasible solution
by solving a sequence of easier optimization problems and could be a useful pre-processing step for SDP solvers. We demonstrate effectiveness of the method on SDPs arising in practice, and describe our publicly-available software implementation.
We also give a post-processing procedure for dual solution recovery that generally applies to facial-reduction-based pre-processing techniques. Joint work with Pablo Parrilo.

Title: Solving the pooling problem using semidefinite programming.
Speaker: Joachim Dahl, MOSEK ApS (DK)

Abstract: The pooling problem is a well-studied difficult nonlinear flow-problem with important applications in the oil- and refinery industry. In this talk we review how to solve this difficult non-convex problem using the Lasserre hierarchy of semidefinite relaxations, and we demonstrate how chordal structure can be exploited to solve larger instances.

Tuesday, June 17, 2014

What if the solver stalls?

In this post we will discuss why the solver get sometimes stalls and how does this relates with the solution quality. What does we mean for stall?

The solver get stalled whenever it cannot make any sensible progress towards the optimal solution.

An iteration of a continuous optimizer in MOSEK consists of
\[ x^+ = x + \alpha d_x\]
where
  • $x$:  Is the current guess for the optimal solution.
  • $d_x$: Is a direction computed in some way by the optimizer.
  • $\alpha$: Is nonnegative step size.
  • $x^+$: Is the updated guess for the optimal solution.
The interpretation is that the optimizer computes a search direction $d_x$ and then takes a step in that direction. The search direction is computed such that when moving in that direction the current solution will be moved closer towards an optimal solution. Normally the step size $\alpha$ is chosen such that the new trial solution $x^+$ is as close as possible to the optimal solution with respect to some merit function. 

If the search direction is badly chosen then the optimal step size might be very close to $0$, in which case the algorithm is stalled. So why does this happens in practice? Typically the search direction $d_x$ is given as the solution of a system of linear equations, say


\[H d_x = h,\]


where it can be proven that if the linear system is solved accurately then good progress is obtained. Unfortunately in practice due to fact that computations are done in finite precision then the search direction may be of poor quality leading to a stall.

To summarize due to numerical issues MOSEK may not be able to compute a good search direction and if that leads to an extremely short step then MOSEK stops and says STALLED. Thus it does not make sense to continue because the subsequent iterations will also leads to small steps and no progress at all.

Observe that when a stall occurs then usually the current solution is very close to an optimal solution and many cases the reported solution is good enough for most practical purposes. Recall that usually the optimization problem solved is approximation of the true problem and even in the best case MOSEK will only report an approximated solution to approximated problem. 

Let's visualize the algorithm execution using a simplified scheme: the feasible region (primal and dual) is the yellowish one and the solution is the green dot on its corner. Algorithm execution generates a sequence of iterates, the green dots, that hopefully will end up in 10.

Interior-point algorithm execution sketch.





























For each iterates, a normalized primal and dual feasibility violation is computed, as well as a measure of optimality violation. Let's call them $r_p,r_d$ and $r_g$ respectively. Ideally, $||(r_p,r_d,r_g)||$ should be driven to zero, but in practice the solver stops when
\[ ||(r_p,r_d,r_g)|| \leq \epsilon_f.\]

Thus $\epsilon_f$ defines a region in which a solution is optimal, i.e. the purple region in the figure. When the solver terminates it provides a solution with a certain solution status. Hopefully, it will be optimal. Otherwise, the solver may still be able to provide a useful solution: for this reason, and to improve flexibility, MOSEK denotes some solutions as near-optimal: the solution would be optimal if we scale up $\epsilon_f$ by a factor $\alpha>1$, i.e.

\[ ||(r_p,r_d,r_g)|| \leq \epsilon_f\alpha.\]

This corresponds to the reddish region. As the algorithm proceeds, we reach the near-optimal region at step (9) and then the optimal one at step (10). If all goes well, we stop in the latter. If we get stalled at (9) we will get a near-optimal solution. But what if the solver get stalled at step (8)? The solution status is unknown in this case.

In general, if the solver is stalled, the solution status is still meaningful since the solver is able to check the solution feasibility and the residual values. In particular a solution could be near-optimal. In our example, step (8) is not even near optimal and could be not very useful, but it is still worth to check it.
In case of stall, user should
  • look at solution summary: provides the primal and dual violation under the column PFEAS and DFEAS, and the MU column measure the optimality violation;
  • retrieve the solution status from the solver.
What can be done to avoid stalls? It is hard to say something about in general. A few good rules to follow are:
  • Avoid nearly feasible or nearly infeasible problems.
  • Make sure the problem is scaled reasonably.
  • Make sure the primal and dual solutions are reasonably bounded i.e. not too large in absolute size.
Users should consider revising their model is stalling happens regularly. If modeling does not help, you are encouraged to contact our support.

Friday, March 28, 2014

SwissQuant Math Challenge on LASSO Regression: the MOSEK way

The Swiss company SwissQuant publishes monthly a math challenge in which they call for people to elaborate and discuss problems of different kind, somehow related to the company business. This month they focus on (quadratic) convex optimization, asking people to proposed specialized algorithm for the OLS-LASSO problem that can beat the established commercial code for quadratic programming as MOSEK. You can find details here Math Challenge March 2014.

Clearly we are glad they appreciate somehow our product, but also we feel challenged in tackling the problem itself. MOSEK is not specialized for OLS-LASSO, but still it can be very efficient we thought, especially in dual form. Moreover, we are always eager to find good test problems, for the core solver but also for our APIs.

The OLS-LASSO problem

So let's start from the formulation given in the challenge, where we are given $T$ samples in dimension $m$:

\begin{equation}\label{main}\tag{OLS-LASSO}
  \begin{aligned}
    \min_{u,b} & \frac{1}{2} || u ||^2 + \sum_{j=1}^{m} \lambda_j |b_j|\\
    &\\
    s.t.&\\
    & u = y - X b
  \end{aligned}
\end{equation}

where $b,\lambda\in \mathbb{R}^m, u,y\in \mathbb{R}^T$. We reformulate problem \ref{main} so to have a linear objective function:

\begin{equation*}
  \begin{aligned}
    \min_{u,b,z,w} &\quad z + \lambda^T w\\
    &\\
    s.t.&\\
    & u + X b = y\\
    & s=1\\
    & (s,z,u) \in Q_R^{T+2}\\
    & w_i \geq |b_i|& \forall i=1,\ldots,m.
  \end{aligned}
\end{equation*}

where $Q_R$ is the rotated cone. There are two way to to get rid of the absolute value:

(1) Linear constraints 

\[ w_i\geq |b_i| \Rightarrow \left\{ \begin{array}{l}  w \geq b \\ w \geq -b \\\end{array}\right.\]

(2) Second-order conic constraint

\[ w_i \geq |b_i| \Leftrightarrow w_i\geq \sqrt{b_i^2} \equiv (w_i,b_i)\in Q^2\]


We will see which primal form works the best. But it's the dual that we want to really see at work. Using the standard procedure outlined in our post about duality, we derive the dual of problem (PQ). It is easier than PL, believe us.

First let's fix a partition of the variable set as $[s,z,u,w,b]$, and clearly states the basic vector and
matrices:


(1) cost vector: $c^T= [0 \quad 1 \quad 0_T \quad \lambda^T \quad 0_m]$;
(2) right-hand side: $b=^T[1 \quad y^T]^T$;
(2) matrix coefficients: $A= \left[ \begin{array}{ccccc} 1 & 0&0_T&0_m&0_m\\ 0&0&I_T& 0_m&X\end{array}\right]$;


We then introduce as many dual variables as primal linear constraints:
$\mu_0$ for the first constraint, and $\mu\in \mathbb{R}^T$ for the
second one. We also include additional slack variables $\gamma$
partitioned in the same way as the primal variables, i.e. $\gamma^T=[\gamma_s,\gamma_z,\gamma_u,\gamma_w,\gamma_b]$.

The dual problem is

\begin{equation*}
  \begin{aligned}
    \max_{\mu_0, \mu, \gamma} & \quad \mu_0 + y^T \mu \\
    &\\
    s.t.&\\
    & c - A^T \left[ \begin{array}{c}\mu_0\\\mu\end{array} \right]= \gamma\\
    & (\gamma_s,\gamma_z,\gamma_u) \in Q_R^{T+2}\\
    & (\gamma_w,\gamma_b) \in \Pi_{i=1}^m Q^2.
  \end{aligned}
\end{equation*}

After some calculations, we obtain:

\begin{equation}\tag{D}
  \begin{aligned}
    \max_{\mu_0,\mu,\gamma_z} &  \quad \mu_0 + y^T \mu \\
    &\\
    s.t.&\\
    &  X^T \mu \leq  \lambda\\
    & \gamma_z=  1\\
    & \left(-\mu_0, \gamma_z, -\mu \right) \in Q_R^{2+T}.
  \end{aligned}
\end{equation}

Try to do the same with PL, you'll get the same model.

The results

We implement these three models using the MOSEK Fusion Python API and run a batch of tests for $m=[10,25,75,100]$ and $T$ from $10000$ to $100000$. To make it easy, $X,\lambda$ and $y$ are all uniformly generated in $[0,1]$. The code that interface with the model looks like


Here you can see the running time for problem PL in green, PQ in red and D in blue. In the first  plot we fix $m$ and let $T$ varies:


and then if we fix $T$ either to $10000$ or $100000$ and we get



Again, the dual is again a clear winner, as in a previous post! No way the primal can even get close to the dual.

But it is also interesting to see how  PQ is as good as PL. Red and green lines are almost indistinguishable. Only for larger $m$, i.e. when the number of cones increases, we can see a significant difference. Otherwise the difference is very very small.




Tuesday, March 11, 2014

How to write the dual problem in a nutshell

Duality in linear programming  is often mentioned and sometimes even used (see [2]). But in our experience, many practitioners unfortunately have a quite blurred idea  about the dual problem and the meaning of it. Things are even worse when considering conic programming, despite the fact that most of the theory remains unchanged. There are at least three good reasons to have a good understanding conic duality:
  • The dual problem could be faster to solve (see our post), even if the complexity is the same.
  • Sensitivity analysis uses dual information (see our post), just think about shadow prices.
  • Infeasibility and unboundedness certificates are stated in terms of duality, using the Farkas' Lemma.
Duality theory for conic optimization is rich and well-established and deserves much more space than a blog post (see for instance [1]). As first step, we will show how to easily derive the dual formulation of a given conic optimization problem. For sake of clarity, we will not consider semidefinite optimization problems, even if the conic framework readily extends to them.

Let assume we are given an optimization problem, which we refer as the primal. If we are lucky, the primal can be reformulated as a conic optimization problem by means of some transformations (see [1],[3]). An hopefully small additional effort is usually needed to cast our conic problem in (primal) standard form. Let the primal variables be reordered and partitioned such that  $x=(x_1,x_2,\ldots,x_k)^T\in \mathbb{R}^n$ with $x_i\in \mathbb{R}^{n_i}$. Then the standard primal form is:

\begin{equation}
\begin{aligned}
  &\min \quad c^Tx &&\\
  & s.t. &&\\
  &&Ax - b = 0 &\\
  &&x_i \in \mathit{K_i^{n_i}} &\quad i=1,\ldots\,k
\end{aligned}
\end{equation}

Note how each block variable $x_i$ belongs to a cone $\mathit{K_i^{n_i}}$; moreover, we can  recover the standard LP formulation just setting $k=1$ and $n_1=n$. In short we may write $x\in \Pi_{i=1}^k K_i^{n_i}$. For our purpose, $\mathit{K_i^{n_i}}$ can be

- the positive orthant $\mathbb{R}^{n_i}$
- a Lorentz cone $L_i^{n_i}$ of dimension $n_i$
- a rotated Lorentz cone $R_i^{n_i}$ of dimension $n_i$

We introduce as many dual variables $y$ as cones in Problem (1) and obtain the dual problem as follows:

\begin{equation}
\begin{aligned}
  &\max \quad b^Ty \\
  & s.t. \\
  &&  A^T y -c \in\Pi_{i=1}^k \mathit{K}_i^*\\
\end{aligned}
\end{equation}

where $\mathit{K}_i^*$ is the dual cone of $\mathit{K}_i$. In practice, the cones we work with are all self-dual, i.e. they are all dual to themselves, and this means roughly speaking $\mathit{K}_i^*\equiv \mathit{K}_i$. Introducing slack variables Problem (2) reads:

\begin{equation}
\begin{aligned}
  &\max \quad b^Ty \\
  & s.t. \\
  && c- A^T y + s= 0\\
   &&s_i \in \mathit{K}^*_i  &\quad i=1,\ldots\,k
\end{aligned}
\end{equation}

which can be converted again in standard form by noticing that $\min x = - \max -x$ and transforming free variables in non negative ones (see for instance [2]).

Summarizing, we recommend to follow these steps:
  1. if possible recast the given problem in conic form
  2. transform the conic form in standard form
  3. derive the dual formulation
  4. simplify the dual if possible
In practice, step 1 requires the biggest effort, while the others follow quite directly. Indeed, the crucial point is to certified the given problem can be expressed in conic form, and we do this actually constructing such a representation. Once we get the conic formulation, most of the job is done. So, working in conic form has also the interesting side-effect of a much simpler access to dual formulation and information.

Check this post to see a practical example! Others will follow in the next days.


[1] Ben-Tal, A., & Nemirovski, A. (2001). Lectures on modern convex optimization: analysis, algorithms, and engineering applications (Vol. 2). Siam.
[2] Papadimitriou, C. H., & Steiglitz, K. (1998). Combinatorial optimization: algorithms and complexity. Courier Dover Publications.
[3] MOSEK modeling manual , 2013, Mosek ApS

Thursday, February 27, 2014

Some pitfalls of the sensitivity analysis for LPs

The old, good sensitivity analysis for LPs...It tries to answer a crucial question:

How does the solution of our optimization model react to small perturbations of the input data?

Don't worry, we are not going to review the principles of the sensitivity analysis, one can refer for instance to [1], but we will show that the commonly used techniques can hide unexpected pitfalls.
In general, an LP sensitivity analyzer returns the shadow price of a given input parameter, i.e. broadly speaking the rate of variation of the objective function with respect to the parameter, and the interval in which the that price is constant.

Every OR practitioner should know this tool and its potential pitfalls. But it is not often the case...
here goes the story: one of our customer was puzzled by the results of the sensitivity analysis he was carrying on some LP problems (related to some kind of unit commitment problem): why the shadow prices of the solutions were sometimes different? And why they did not seem to make much sense to him? 

He boiled down to a VERY minimal example for us:

\begin{equation}
\begin{aligned}
& \min & 10^5 x_1 + x_2 \\
\\
&& x_1  + x_2  =100\\
\\
&& x_1,x_2 \in [0,100]
\end{aligned}
\end{equation}

The problem is so simple that can be solved by hand: the optimal solution is $(x_1^\star, x_2^\star)=(0,100)$. It is also degenerate (either the upper or the lower bounds can be dropped) with multiple optimal basis: to see that, let's recast the problem in standard form:

\begin{equation}
\begin{aligned}
& \min & 10^5 x_1 + x_2 \\
\\
&& x_1  + x_2  =100\\
&& x_1  + s_1  =100\\
&& x_2  + s_2  =100\\
\\
&& x_1,x_2,s_1,s_2 \geq 0
\end{aligned}
\end{equation}

The optimal solution now reads $(x_1^\star, x_2^\star, s_1^\star, s_2^\star )=(0,100,100,0)$. It is straightforward to see that there are two optimal basis: $B_1=\{x_2,s_1,s_2\}$ and $B_2=\{x_2,s_1,x_1\}$.

What if we ask for a sensitivity analysis about the linear constraint in problem (1)?  Using the command line MOSEK sensitivity analyser the answer is:


BOUNDS CONSTRAINTS
INDEX    NAME  BOUND    LEFTRANGE        RIGHTRANGE       LEFTSHADOW       RIGHTSHADOW     
0        c0000 FX       -1.000000e+02    -0.000000e+00    1.000000e+00     1.000000e+00    


that is the RHS can be reduced by up to $100$ (the LEFTRANGE) with unitary shadow price.  But we have no information about what might happen if we increase the RHS. Let's  visualize what we would like to investigate (RHS is renamed as $\beta$):

The gray area represent the region defined by the box constraints. The red line is the feasible region of problem (1) and the optimal value is the red dot on the left-up corner. Varying RHS results in a translation of that feasible region and a different optimal value. The yellow lines/points correspond to the feasible region/optimal solution as RHS decreases; the light-blue ones, corresponding to an increase of RHS,  are not reported by the analyzer. But still, it is clearly possible to increase RHS...so what's going on?

This problem is quite well-known in the OR community. In [3], the main issues and pitfall are clearly summarized: the standard analysis, named Type-I, depends on the optimal basis. If more than one basis corresponds to an optimal solution, the analysis will be in general incomplete because limited by the changing of basis.

In our case, the solutions  obtained decreasing RHS share the same basis, while a different basis corresponds to the other ones. So the scope of our analysis is limited by the basis reported by the solver.

A more accurate analysis can be carried out using more computational intensive techniques, sometimes referred as Type-III sensitivity or Optimal Partition Sensitivity (OPS): simply speaking, a sequence of LP problems based on the current optimal solution are solved in order to asses the sensitivity, regardless of the particular basis that might correspond to the solution (see [2]).

Again, let's look at our example. We use the OPS tool available in MOSEK to analyze again the same constraint. The result follows:

BOUNDS CONSTRAINTS
INDEX    NAME  BOUND    LEFTRANGE        RIGHTRANGE       LEFTSHADOW       RIGHTSHADOW     
0        c0000 FX       -1.000000e+02    1.000000e+02     1.000000e+00     1.000000e+05    

Now we can investigate also the increasing of the RHS! As one might expect, a different shadow price correspond to this side of the RHS interval.

The lesson is that in most of the practical applications, optimal solutions are degenerate and thus the Type-I sensitivity analysis might be incomplete. In general, there is no way to predict which basis will be returned by a solver. The OPS analysis, despite being more computational demanding, can deliver more accurate information and it is therefore a tool that practitioners should consider and learn.

[1] Chvátal, V. (1983). Linear programming. 
[2] Roos C., Terlaky T., Vial J. P. (1997). Theory and algorithms for linear optimization: an interior point approach. Chichester: Wiley.
[3] Koltai T.,  Terlaky T. (2000). The difference between the managerial and mathematical interpretation of sensitivity analysis results in linear programming. International Journal of Production Economics, 65(3), 257-274.



Monday, February 20, 2012

Feature update in the R to MOSEK interface

A new version of the Rmosek package is available. The new features are:
  • support for separable convex optimization,
  • new methods to formulate quadratic programs on conic quadratic form,
  • and a simplified installation process.
Furthermore, a change in input format regarding bounds and cones have been made to decrease the time it takes to construct large problems. Please see the NEWS file for details.

Monday, December 5, 2011

Octave to MOSEK Interface

Octave is a scripting language and interactive environment suited for numerical computations. As part of our efforts to bring powerful optimization tools closer to our customers, MOSEK is pleased to announce an open source Octave to MOSEK interface is now available at Google Code Project Hosting. The interface makes it possible to solve
  • linear,
  • conic quadratic (aka. second order cone), 
  • and mixed-integer 
problems from Octave. As any convex quadratic problem can be reformulated as a conic quadratic problem, the interface can also be employed to solve convex quadratic and quadratically constrained problems. Note that an R to MOSEK interface was released earlier this year.

Wednesday, October 5, 2011

R to MOSEK interface

R is popular tool for statistical computing that has many users in financial industry for example. Therefore, MOSEK is pleased to announce that an open source R to MOSEK interface is now available at R-forge. The interface makes it possible to use the powerful MOSEK optimizers for
  • linear,
  • conic quadratic (aka. second order cone), 
  • and  mixed-integer 
problems from R. Note any convex quadratic problem can reformulated as a conic quadratic problem and hence the interface can be employed to solve convex quadratic and quadratically constrained problems.