The MOSEK Python optimizer API manual Version 7.0 (Revision 141)
Optimizer API for Python - Documentation - Mosek Optimizer API for Python - Documentation - Mosek
68 CHAPTER 5. BASIC API TUTORIAL • Task.putmaxnumanz. Estimate for the number of non-zeros in A. • Task.putmaxnumqnz. Estimate for the number of non-zeros in the quadratic terms. None of these functions change the problem, they only give hints to the eventual dimension of the problem. If the problem ends up growing larger than this, the estimates are automatically increased. Do not mix put- and get- functions: For instance, the functions Task.putacol and Task.getacol. MOSEK will queue put- commands internally until a get- function is called. If every put- function call is followed by a getfunction call, the queue will have to be flushed often, decreasing efficiency. In general get- commands should not be called often during problem setup. Use the LIFO principle when removing constraints and variables: MOSEK can more efficiently remove constraints and variables with a high index than a small index. An alternative to removing a constraint or a variable is to fix it at 0, and set all relevant coefficients to 0. Generally this will not have any impact on the optimization speed. Add more constraints and variables than you need (now): The cost of adding one constraint or one variable is about the same as adding many of them. Therefore, it may be worthwhile to add many variables instead of one. Initially fix the unused variable at zero, and then later unfix them as needed. Similarly, you can add multiple free constraints and then use them as needed. Use one environment (env) only: If possible share the environment (env) between several tasks. For most applications you need to create only a single env. Do not remove basic variables: When doing re-optimizations, instead of removing a basic variable it may be more efficient to fix the variable at zero and then remove it when the problem is re-optimized and it has left the basis. This makes it easier for MOSEK to restart the simplex optimizer. 5.12.1 API overhead The Python interface is a thin wrapper around a native MOSEK library. The layer between the Python application and the native MOSEK library is made as thin as possible to minimize the overhead from function calls. The methods in mosek.Env and mosek.Task are all written in C and resides in the module pymosek. Each method converts the call parameter data structures (i.e. creates a complete copy of the data), calls a MOSEK function and converts the returned values back into Python structures. The follwing rules will often improve the performance of the MOSEK/Python API:
5.13. CONVENTIONS EMPLOYED IN THE API 69 Reuse Env and Task whenever possible There may be some overhead involved in creating and deleting task and environment objects, so if possible reuse these. Make sure to delete task and environment when not in use anymore Using the with-construction (available in python 2.6 and later) will allow automatic deletion of the environment and task. If this is not an option, use Env. del () and Task. del () to destroy the objects. Failing to do this may cause memory leaks in some cases. Avoid input loops Whenever possible imput data in large chunks or vectors instead of using loops. For small put- and get- methods there is a significant overhead, so for example inputting one row of the A-matrix at the time may be much slower than inputting the whole matrix. For example, a loop with Task.putarow may be replaced with one Task.putarowlist, or a loop of Task.putqobjij may be replaced with Task.putqobj. 5.13 Conventions employed in the API 5.13.1 Naming conventions for arguments In the definition of the MOSEK Python API a consistent naming convention has been used. This implies that whenever for example numcon is an argument in a function definition it indicates the number of constraints. In Table 5.2 the variable names used to specify the problem parameters are listed. The relation between the variable names and the problem parameters is as follows: • The quadratic terms in the objective: q o qosubi[t],qosubj[t] • The linear terms in the objective: = qoval[t], t = 0, . . . , numqonz − 1. (5.13) • The fixed term in the objective: c j = c[j], j = 0, . . . , numvar − 1 (5.14) • The quadratic terms in the constraints: c f = cfix. q qcsubk[t] qcsubi[t],qcsubj[t] = qcval[t], t = 0, . . . , numqcnz − 1. (5.15)
- Page 39 and 40: Chapter 3 Getting support and help
- Page 41 and 42: Chapter 4 Testing installation and
- Page 43 and 44: Chapter 5 Basic API tutorial In thi
- Page 45 and 46: 5.1. THE BASICS 23 5 # 6 # Purpose:
- Page 47 and 48: 5.2. LINEAR OPTIMIZATION 25 and the
- Page 49 and 50: 5.2. LINEAR OPTIMIZATION 27 Load a
- Page 51 and 52: 5.2. LINEAR OPTIMIZATION 29 Optimiz
- Page 53 and 54: 5.2. LINEAR OPTIMIZATION 31 88 task
- Page 55 and 56: 5.2. LINEAR OPTIMIZATION 33 51 mose
- Page 57 and 58: 5.3. CONIC QUADRATIC OPTIMIZATION 3
- Page 59 and 60: 5.3. CONIC QUADRATIC OPTIMIZATION 3
- Page 61 and 62: 5.4. SEMIDEFINITE OPTIMIZATION 39 m
- Page 63 and 64: 5.4. SEMIDEFINITE OPTIMIZATION 41 4
- Page 65 and 66: 5.4. SEMIDEFINITE OPTIMIZATION 43 1
- Page 67 and 68: 5.5. QUADRATIC OPTIMIZATION 45 with
- Page 69 and 70: 5.5. QUADRATIC OPTIMIZATION 47 68 #
- Page 71 and 72: 5.5. QUADRATIC OPTIMIZATION 49 5.5.
- Page 73 and 74: 5.5. QUADRATIC OPTIMIZATION 51 81 a
- Page 75 and 76: 5.6. THE SOLUTION SUMMARY 53 • Th
- Page 77 and 78: 5.7. INTEGER OPTIMIZATION 55 21 # f
- Page 79 and 80: 5.7. INTEGER OPTIMIZATION 57 137 sy
- Page 81 and 82: 5.8. THE SOLUTION SUMMARY FOR MIXED
- Page 83 and 84: 5.9. RESPONSE HANDLING 61 Note that
- Page 85 and 86: 5.10. PROBLEM MODIFICATION AND REOP
- Page 87 and 88: 5.10. PROBLEM MODIFICATION AND REOP
- Page 89: 5.11. SOLUTION ANALYSIS 67 151 # Pu
- Page 93 and 94: 5.13. CONVENTIONS EMPLOYED IN THE A
- Page 95 and 96: 5.13. CONVENTIONS EMPLOYED IN THE A
- Page 97 and 98: 5.13. CONVENTIONS EMPLOYED IN THE A
- Page 99 and 100: Chapter 6 Nonlinear API tutorial Th
- Page 101 and 102: 6.1. SEPARABLE CONVEX (SCOPT) INTER
- Page 103 and 104: 6.1. SEPARABLE CONVEX (SCOPT) INTER
- Page 105 and 106: 6.1. SEPARABLE CONVEX (SCOPT) INTER
- Page 107 and 108: Chapter 7 Advanced API tutorial Thi
- Page 109 and 110: 7.1. THE PROGRESS CALL-BACK 87 71 p
- Page 111 and 112: 7.2. SOLVING LINEAR SYSTEMS INVOLVI
- Page 113 and 114: 7.2. SOLVING LINEAR SYSTEMS INVOLVI
- Page 115 and 116: 7.2. SOLVING LINEAR SYSTEMS INVOLVI
- Page 117 and 118: 7.2. SOLVING LINEAR SYSTEMS INVOLVI
- Page 119 and 120: Chapter 8 A case study 8.1 Portfoli
- Page 121 and 122: 8.1. PORTFOLIO OPTIMIZATION 99 e T
- Page 123 and 124: 8.1. PORTFOLIO OPTIMIZATION 101 is
- Page 125 and 126: 8.1. PORTFOLIO OPTIMIZATION 103 15
- Page 127 and 128: 8.1. PORTFOLIO OPTIMIZATION 105 63
- Page 129 and 130: 8.1. PORTFOLIO OPTIMIZATION 107 8.1
- Page 131 and 132: 8.1. PORTFOLIO OPTIMIZATION 109 110
- Page 133 and 134: 8.1. PORTFOLIO OPTIMIZATION 111 z j
- Page 135 and 136: 8.1. PORTFOLIO OPTIMIZATION 113 Var
- Page 137 and 138: 8.1. PORTFOLIO OPTIMIZATION 115 56
- Page 139 and 140: 8.1. PORTFOLIO OPTIMIZATION 117 172
5.13. CONVENTIONS EMPLOYED IN THE <strong>API</strong> 69<br />
Reuse Env and Task whenever possible<br />
<strong>The</strong>re may be some overhead involved in creating and deleting task and environment objects, so<br />
if possible reuse these.<br />
Make sure to delete task and environment when not in use anymore<br />
Using the with-construction (available in python 2.6 and later) will allow automatic deletion of<br />
the environment and task. If this is not an option, use Env. del () and Task. del () to<br />
destroy the objects. Failing to do this may cause memory leaks in some cases.<br />
Avoid input loops<br />
Whenever possible imput data in large chunks or vectors instead of using loops. For small<br />
put- and get- methods there is a significant overhead, so for example inputting one row of the<br />
A-matrix at the time may be much slower than inputting the whole matrix.<br />
For example, a loop with Task.putarow may be replaced with one Task.putarowlist, or a loop<br />
of Task.putqobjij may be replaced with Task.putqobj.<br />
5.13 Conventions employed in the <strong>API</strong><br />
5.13.1 Naming conventions for arguments<br />
In the definition of the <strong>MOSEK</strong> <strong>Python</strong> <strong>API</strong> a consistent naming convention has been used. This<br />
implies that whenever for example numcon is an argument in a function definition it indicates the<br />
number of constraints.<br />
In Table 5.2 the variable names used to specify the problem parameters are listed. <strong>The</strong> relation between<br />
the variable names and the problem parameters is as follows:<br />
• <strong>The</strong> quadratic terms in the objective:<br />
q o qosubi[t],qosubj[t]<br />
• <strong>The</strong> linear terms in the objective:<br />
= qoval[t], t = 0, . . . , numqonz − 1. (5.13)<br />
• <strong>The</strong> fixed term in the objective:<br />
c j = c[j], j = 0, . . . , numvar − 1 (5.14)<br />
• <strong>The</strong> quadratic terms in the constraints:<br />
c f = cfix.<br />
q qcsubk[t]<br />
qcsubi[t],qcsubj[t]<br />
= qcval[t], t = 0, . . . , numqcnz − 1. (5.15)