The MOSEK Python optimizer API manual Version 7.0 (Revision 141)

Optimizer API for Python - Documentation - Mosek Optimizer API for Python - Documentation - Mosek

25.11.2015 Views

108 CHAPTER 8. A CASE STUDY 53 offsetx = 0 # Offset of variable x into the API variable. 54 offsets = n # Offset of variable x into the API variable. 55 offsett = n+1 # Offset of variable t into the API variable. 56 57 # x variables. 58 task.putclist(range(offsetx+0,offsetx+n),mu) 59 task.putaijlist(n*[0],range(offsetx+0,offsetx+n),n*[1.0]) 60 for j in range(0,n): 61 task.putaijlist(n*[1+j],range(offsetx+0,offsetx+n),GT[j]) 62 63 task.putvarboundlist(range(offsetx+0,offsetx+n),n*[mosek.boundkey.lo],n*[0.0],n*[inf]) 64 for j in range(0,n): 65 task.putvarname(offsetx+j,"x[%d]" % (1+j)) 66 67 # s variable. 68 task.putvarbound(offsets+0,mosek.boundkey.fr,gamma,gamma) 69 task.putvarname(offsets+0,"s") 70 71 # t variables. 72 task.putaijlist(range(1,n+1),range(offsett+0,offsett+n),n*[-1.0]) 73 task.putvarboundlist(range(offsett+0,offsett+n),n*[mosek.boundkey.fr],n*[-inf],n*[inf]) 74 for j in range(0,n): 75 task.putvarname(offsett+j,"t[%d]" % (1+j)) 76 77 task.appendcone(mosek.conetype.quad,0.0,[offsets] + range(offsett,offsett+n)) 78 task.putconename(0,"stddev") 79 80 task.putobjsense(mosek.objsense.maximize) 81 82 # Turn all log output off. 83 task.putintparam(mosek.iparam.log,0) 84 85 for alpha in alphas: 86 # Dump the problem to a human readable OPF file. 87 #task.writedata("dump.opf") 88 89 task.putcj(offsets+0,-alpha); 90 91 task.optimize() 92 93 # Display the solution summary for quick inspection of results. 94 # task.solutionsummary(mosek.streamtype.msg) 95 96 solsta = task.getsolsta(mosek.soltype.itr) 97 98 if solsta in [mosek.solsta.optimal, mosek.solsta.near optimal]: 99 expret = 0.0 100 x = zeros(n,float) 101 task.getxxslice(mosek.soltype.itr,offsetx+0,offsetx+n,x) 102 for j in range(0,n): 103 expret += mu[j]*x[j] 104 105 stddev = zeros(1,float) 106 task.getxxslice(mosek.soltype.itr,offsets+0,offsets+1,stddev) 107 108 print("\nExpected return %e for gamma %e" % (expret,stddev[0])), 109 else:

8.1. PORTFOLIO OPTIMIZATION 109 110 print("An error occurred when solving for alpha=%e\n" % alpha) 8.1.4 Improving the computational efficiency In practice it is often important to solve the portfolio problem in a short amount of time; this section it is discusses what can be done at the modelling stage to improve the computational efficiency. The computational cost is of course to some extent dependent on the number of constraints and variables in the optimization problem. However, in practice a more important factor is the number nonzeros used to represent the problem. Indeed it is often better to focus at the number of nonzeros in G (see (8.2)) and try to reduce that number by for instance changing the choice of G. In other words, if the computational efficiency should be improved then it is always good idea to start with focusing at the covariance matrix. As an example assume that Σ = D + V V T where D is positive definite diagonal matrix. Moreover, V is a matrix with n rows and p columns. Such a model for the covariance matrix is called a factor model and usually p is much smaller than n. In practice p tends be a small number say less than 100 independent of n. One possible choice for G is the Cholesky factorization of Σ which requires storage proportional to n(n + 1)/2. However, another choice is because then G T = [ D 1/2 V T ] GG T = D + V V T . This choice requires storage proportional to n + pn which is much less than for the Cholesky choice of G. Indeed assuming p is a constant then the difference in storage requirements is a factor of n. The example above exploits the so-called factor structure and demonstrates that an alternative choice of G may lead to a significant reduction in the amount of storage used to represent the problem. This will in most cases also lead to a significant reduction in the solution time. The lesson to be learned is that it is important to investigate how the covariance is formed. Given this knowledge it might be possible to make a special choice for G that helps reducing the storage requirements and enhance the computational efficiency. 8.1.5 Slippage cost The basic Markowitz portfolio model assumes that there are no costs associated with trading the assets and that the returns of the assets is independent of the amount traded. None of those assumptions are usually valid in practice. Therefore, a more realistic model is

8.1. PORTFOLIO OPTIMIZATION 109<br />

110 print("An error occurred when solving for alpha=%e\n" % alpha)<br />

8.1.4 Improving the computational efficiency<br />

In practice it is often important to solve the portfolio problem in a short amount of time; this section<br />

it is discusses what can be done at the modelling stage to improve the computational efficiency.<br />

<strong>The</strong> computational cost is of course to some extent dependent on the number of constraints and<br />

variables in the optimization problem. However, in practice a more important factor is the number<br />

nonzeros used to represent the problem. Indeed it is often better to focus at the number of nonzeros<br />

in G (see (8.2)) and try to reduce that number by for instance changing the choice of G.<br />

In other words, if the computational efficiency should be improved then it is always good idea to start<br />

with focusing at the covariance matrix. As an example assume that<br />

Σ = D + V V T<br />

where D is positive definite diagonal matrix. Moreover, V is a matrix with n rows and p columns.<br />

Such a model for the covariance matrix is called a factor model and usually p is much smaller than n.<br />

In practice p tends be a small number say less than 100 independent of n.<br />

One possible choice for G is the Cholesky factorization of Σ which requires storage proportional to<br />

n(n + 1)/2. However, another choice is<br />

because then<br />

G T =<br />

[<br />

D<br />

1/2<br />

V T ]<br />

GG T = D + V V T .<br />

This choice requires storage proportional to n + pn which is much less than for the Cholesky choice of<br />

G. Indeed assuming p is a constant then the difference in storage requirements is a factor of n.<br />

<strong>The</strong> example above exploits the so-called factor structure and demonstrates that an alternative choice<br />

of G may lead to a significant reduction in the amount of storage used to represent the problem. This<br />

will in most cases also lead to a significant reduction in the solution time.<br />

<strong>The</strong> lesson to be learned is that it is important to investigate how the covariance is formed. Given<br />

this knowledge it might be possible to make a special choice for G that helps reducing the storage<br />

requirements and enhance the computational efficiency.<br />

8.1.5 Slippage cost<br />

<strong>The</strong> basic Markowitz portfolio model assumes that there are no costs associated with trading the assets<br />

and that the returns of the assets is independent of the amount traded. None of those assumptions<br />

are usually valid in practice. <strong>The</strong>refore, a more realistic model is

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!