|
6569
|
1 @node Dynamically Linked Functions |
|
|
2 @appendix Dynamically Linked Functions |
|
|
3 @cindex dynamic-linking |
|
|
4 |
|
|
5 Octave has the possibility of including compiled code as dynamically |
|
|
6 linked extensions and then using these extensions as if they were part |
|
6571
|
7 of Octave itself. Octave has the option of directly calling C++ code |
|
6569
|
8 through its native oct-file interface or C code through its mex |
|
6571
|
9 interface. It can also indirectly call functions written in any other |
|
|
10 language through a simple wrapper. The reasons to write code in a |
|
6569
|
11 compiled language might be either to link to an existing piece of code |
|
|
12 and allow it to be used within Octave, or to allow improved performance |
|
|
13 for key pieces of code. |
|
|
14 |
|
|
15 Before going further, you should first determine if you really need to |
|
6571
|
16 use dynamically linked functions at all. Before proceeding with writing |
|
6569
|
17 any dynamically linked function to improve performance you should |
|
|
18 address ask yourself |
|
|
19 |
|
|
20 @itemize @bullet |
|
|
21 @item |
|
|
22 Can I get the same functionality using the Octave scripting language only. |
|
|
23 @item |
|
6572
|
24 Is it thoroughly optimized Octave code? Vectorization of Octave code, |
|
6569
|
25 doesn't just make it concise, it generally significantly improves its |
|
6571
|
26 performance. Above all, if loops must be used, make sure that the |
|
6569
|
27 allocation of space for variables takes place outside the loops using an |
|
|
28 assignment to a like matrix or zeros. |
|
|
29 @item |
|
|
30 Does it make as much use as possible of existing built-in library |
|
6572
|
31 routines? These are highly optimized and many do not carry the overhead |
|
6569
|
32 of being interpreted. |
|
|
33 @item |
|
|
34 Does writing a dynamically linked function represent useful investment |
|
|
35 of your time, relative to staying in Octave? |
|
|
36 @end itemize |
|
|
37 |
|
|
38 Also, as oct- and mex-files are dynamically linked to octave, they |
|
|
39 introduce to possibility of having Octave abort due to coding errors in |
|
6571
|
40 the user code. For example a segmentation violation in the users code |
|
6569
|
41 will cause Octave to abort. |
|
|
42 |
|
|
43 @menu |
|
6572
|
44 * Oct-Files:: |
|
|
45 * Mex-Files:: |
|
|
46 * Standalone Programs:: |
|
6569
|
47 @end menu |
|
|
48 |
|
|
49 @node Oct-Files |
|
|
50 @section Oct-Files |
|
|
51 @cindex oct-files |
|
|
52 @cindex mkoctfile |
|
|
53 @cindex oct |
|
|
54 |
|
|
55 @menu |
|
6572
|
56 * Getting Started with Oct-Files:: |
|
|
57 * Matrices and Arrays in Oct-Files:: |
|
|
58 * Character Strings in Oct-Files:: |
|
|
59 * Cell Arrays in Oct-Files:: |
|
|
60 * Structures in Oct-Files:: |
|
|
61 * Sparse Matrices in Oct-Files:: |
|
|
62 * Accessing Global Variables in Oct-Files:: |
|
|
63 * Calling Octave Functions from Oct-Files:: |
|
|
64 * Calling External Code from Oct-Files:: |
|
|
65 * Allocating Local Memory in Oct-Files:: |
|
|
66 * Input Parameter Checking in Oct-Files:: |
|
|
67 * Exception and Error Handling in Oct-Files:: |
|
|
68 * Documentation and Test of Oct-Files:: |
|
|
69 * Application Programming Interface for Oct-Files:: |
|
6569
|
70 @end menu |
|
|
71 |
|
|
72 @node Getting Started with Oct-Files |
|
|
73 @subsection Getting Started with Oct-Files |
|
|
74 |
|
|
75 The basic command to build oct-files is @code{mkoctfile} and it can be |
|
|
76 call from within octave or from the command line. |
|
|
77 |
|
|
78 @DOCSTRING(mkoctfile) |
|
|
79 |
|
|
80 Consider the short example |
|
|
81 |
|
|
82 @example |
|
|
83 @group |
|
6577
|
84 @verbatiminclude @value{top_srcdir}/examples/helloworld.cc |
|
6569
|
85 @end group |
|
|
86 @end example |
|
|
87 |
|
|
88 This example although short introduces the basics of writing a C++ |
|
6571
|
89 function that can be dynamically linked to Octave. The easiest way to |
|
6569
|
90 make available most of the definitions that might be necessary for an |
|
|
91 oct-file in Octave is to use the @code{#include <octave/oct.h>} |
|
6571
|
92 header. |
|
6569
|
93 |
|
|
94 The macro that defines the entry point into the dynamically loaded |
|
6572
|
95 function is @code{DEFUN_DLD}. This macro takes four arguments, these being |
|
6569
|
96 |
|
|
97 @enumerate 1 |
|
6571
|
98 @item The function name as it will be seen in Octave, |
|
6572
|
99 @item The list of arguments to the function of type @code{octave_value_list}, |
|
6569
|
100 @item The number of output arguments, which can and often is omitted if |
|
|
101 not used, and |
|
|
102 @item The string that will be seen as the help text of the function. |
|
|
103 @end enumerate |
|
|
104 |
|
6572
|
105 The return type of functions defined with @code{DEFUN_DLD} is always |
|
|
106 @code{octave_value_list}. |
|
6569
|
107 |
|
|
108 There are a couple of important considerations in the choice of function |
|
6571
|
109 name. Firstly, it must be a valid Octave function name and so must be a |
|
6569
|
110 sequence of letters, digits and underscores, not starting with a |
|
6571
|
111 digit. Secondly, as Octave uses the function name to define the filename |
|
6572
|
112 it attempts to find the function in, the function name in the @code{DEFUN_DLD} |
|
6571
|
113 macro must match the filename of the oct-file. Therefore, the above |
|
6572
|
114 function should be in a file @file{helloworld.cc}, and it should be |
|
|
115 compiled to an oct-file using the command |
|
6569
|
116 |
|
|
117 @example |
|
|
118 mkoctfile helloworld.cc |
|
|
119 @end example |
|
|
120 |
|
|
121 This will create a file call helloworld.oct, that is the compiled |
|
6571
|
122 version of the function. It should be noted that it is perfectly |
|
6572
|
123 acceptable to have more than one @code{DEFUN_DLD} function in a source |
|
6571
|
124 file. However, there must either be a symbolic link to the oct-file for |
|
6572
|
125 each of the functions defined in the source code with the @code{DEFUN_DLD} |
|
6569
|
126 macro or the autoload (@ref{Function Files}) function should be used. |
|
|
127 |
|
|
128 The rest of this function then shows how to find the number of input |
|
|
129 arguments, how to print through the octave pager, and return from the |
|
6571
|
130 function. After compiling this function as above, an example of its use |
|
6569
|
131 is |
|
|
132 |
|
|
133 @example |
|
|
134 @group |
|
6572
|
135 helloworld (1, 2, 3) |
|
|
136 @print{} Hello World has 3 input arguments and 0 output arguments. |
|
6569
|
137 @end group |
|
|
138 @end example |
|
|
139 |
|
|
140 @node Matrices and Arrays in Oct-Files |
|
|
141 @subsection Matrices and Arrays in Oct-Files |
|
|
142 |
|
|
143 Octave supports a number of different array and matrix classes, the |
|
6571
|
144 majority of which are based on the Array class. The exception is the |
|
|
145 sparse matrix types discussed separately below. There are three basic |
|
|
146 matrix types |
|
6569
|
147 |
|
6572
|
148 @table @code |
|
6569
|
149 @item Matrix |
|
|
150 A double precision matrix class defined in dMatrix.h, |
|
|
151 @item ComplexMatrix |
|
|
152 A complex matrix class defined in CMatrix.h, and |
|
|
153 @item BoolMatrix |
|
|
154 A boolean matrix class defined in boolMatrix.h. |
|
|
155 @end table |
|
|
156 |
|
6571
|
157 These are the basic two-dimensional matrix types of octave. In |
|
6569
|
158 additional there are a number of multi-dimensional array types, these |
|
|
159 being |
|
|
160 |
|
6572
|
161 @table @code |
|
6569
|
162 @item NDArray |
|
6572
|
163 A double precision array class defined in @file{dNDArray.h} |
|
6569
|
164 @item ComplexNDarray |
|
6572
|
165 A complex array class defined in @file{CNDArray.h} |
|
6569
|
166 @item boolNDArray |
|
6572
|
167 A boolean array class defined in @file{boolNDArray.h} |
|
|
168 @item int8NDArray |
|
|
169 @itemx int16NDArray |
|
|
170 @itemx int32NDArray |
|
|
171 @itemx int64NDArray |
|
|
172 8, 16, 32 and 64-bit signed array classes defined in |
|
|
173 @file{int8NDArray.h}, @file{int16NDArray.h}, etc. |
|
|
174 @item uint8NDArray |
|
|
175 @itemx uint16NDArray |
|
|
176 @itemx uint32NDArray |
|
|
177 @itemx uint64NDArray |
|
|
178 8, 16, 32 and 64-bit unsigned array classes defined in |
|
|
179 @file{uint8NDArray.h}, @file{uint16NDArray.h}, etc. |
|
6569
|
180 @end table |
|
|
181 |
|
|
182 There are several basic means of constructing matrices of |
|
6572
|
183 multi-dimensional arrays. Considering the @code{Matrix} type as an |
|
|
184 example |
|
6569
|
185 |
|
|
186 @itemize @bullet |
|
6571
|
187 @item |
|
|
188 We can create an empty matrix or array with the empty constructor. For |
|
6569
|
189 example |
|
|
190 |
|
|
191 @example |
|
|
192 Matrix a; |
|
|
193 @end example |
|
|
194 |
|
|
195 This can be used on all matrix and array types |
|
6571
|
196 @item |
|
|
197 Define the dimensions of the matrix or array with a dim_vector. For |
|
6569
|
198 example |
|
|
199 |
|
|
200 @example |
|
|
201 @group |
|
6572
|
202 dim_vector dv (2); |
|
6569
|
203 dv(0) = 2; dv(1) = 2; |
|
6572
|
204 Matrix a (dv); |
|
6569
|
205 @end group |
|
|
206 @end example |
|
|
207 |
|
|
208 This can be used on all matrix and array types |
|
|
209 @item |
|
6572
|
210 Define the number of rows and columns in the matrix. For example |
|
6569
|
211 |
|
|
212 @example |
|
6572
|
213 Matrix a (2, 2) |
|
6569
|
214 @end example |
|
|
215 |
|
|
216 However, this constructor can only be used with the matrix types. |
|
|
217 @end itemize |
|
|
218 |
|
|
219 These types all share a number of basic methods and operators, a |
|
|
220 selection of which include |
|
|
221 |
|
6572
|
222 @deftypefn Method T& {operator ()} (octave_idx_type) |
|
|
223 @deftypefnx Method T& elem (octave_idx_type) |
|
|
224 The @code{()} operator or @code{elem} method allow the values of the |
|
|
225 matrix or array to be read or set. These can take a single argument, |
|
|
226 which is of type @code{octave_idx_type}, that is the index into the matrix or |
|
6571
|
227 array. Additionally, the matrix type allows two argument versions of the |
|
6572
|
228 @code{()} operator and elem method, giving the row and column index of the |
|
6569
|
229 value to obtain or set. |
|
6572
|
230 @end deftypefn |
|
6569
|
231 |
|
|
232 Note that these function do significant error checking and so in some |
|
|
233 circumstances the user might prefer the access the data of the array or |
|
|
234 matrix directly through the fortran_vec method discussed below. |
|
6572
|
235 |
|
|
236 @deftypefn Method octave_idx_type nelem (void) const |
|
6569
|
237 The total number of elements in the matrix or array. |
|
6572
|
238 @end deftypefn |
|
|
239 |
|
|
240 @deftypefn Method size_t byte_size (void) const |
|
6569
|
241 The number of bytes used to store the matrix or array. |
|
6572
|
242 @end deftypefn |
|
|
243 |
|
|
244 @deftypefn Method dim_vector dims (void) const |
|
6569
|
245 The dimensions of the matrix or array in value of type dim_vector. |
|
6572
|
246 @end deftypefn |
|
|
247 |
|
|
248 @deftypefn Method void resize (const dim_vector&) |
|
|
249 A method taking either an argument of type @code{dim_vector}, or in the |
|
|
250 case of a matrix two arguments of type @code{octave_idx_type} defining |
|
|
251 the number of rows and columns in the matrix. |
|
|
252 @end deftypefn |
|
|
253 |
|
|
254 @deftypefn Method T* fortran_vec (void) |
|
6569
|
255 This method returns a pointer to the underlying data of the matrix or a |
|
|
256 array so that it can be manipulated directly, either within Octave or by |
|
|
257 an external library. |
|
6572
|
258 @end deftypefn |
|
6569
|
259 |
|
6572
|
260 Operators such an @code{+}, @code{-}, or @code{*} can be used on the |
|
|
261 majority of the above types. In addition there are a number of methods |
|
|
262 that are of interest only for matrices such as @code{transpose}, |
|
|
263 @code{hermitian}, @code{solve}, etc. |
|
6569
|
264 |
|
|
265 The typical way to extract a matrix or array from the input arguments of |
|
6572
|
266 @code{DEFUN_DLD} function is as follows |
|
6569
|
267 |
|
|
268 @example |
|
|
269 @group |
|
6577
|
270 @verbatiminclude @value{top_srcdir}/examples/addtwomatrices.cc |
|
6569
|
271 @end group |
|
|
272 @end example |
|
|
273 |
|
|
274 To avoid segmentation faults causing Octave to abort, this function |
|
|
275 explicitly checks that there are sufficient arguments available before |
|
6571
|
276 accessing these arguments. It then obtains two multi-dimensional arrays |
|
6572
|
277 of type @code{NDArray} and adds these together. Note that the array_value |
|
|
278 method is called without using the @code{is_matrix_type} type, and instead the |
|
6571
|
279 error_state is checked before returning @code{A + B}. The reason to |
|
6569
|
280 prefer this is that the arguments might be a type that is not an |
|
6572
|
281 @code{NDArray}, but it would make sense to convert it to one. The |
|
|
282 @code{array_value} method allows this conversion to be performed |
|
|
283 transparently if possible, and sets @code{error_state} if it is not. |
|
6569
|
284 |
|
6572
|
285 @code{A + B}, operating on two @code{NDArray}'s returns an |
|
|
286 @code{NDArray}, which is cast to an @code{octave_value} on the return |
|
|
287 from the function. An example of the use of this demonstration function |
|
|
288 is |
|
6569
|
289 |
|
|
290 @example |
|
|
291 @group |
|
6572
|
292 addtwomatrices (ones (2, 2), ones (2, 2)) |
|
6569
|
293 @result{} 2 2 |
|
|
294 2 2 |
|
|
295 @end group |
|
|
296 @end example |
|
|
297 |
|
6572
|
298 A list of the basic @code{Matrix} and @code{Array} types, the methods to |
|
|
299 extract these from an @code{octave_value} and the associated header is |
|
|
300 listed below. |
|
6569
|
301 |
|
|
302 @multitable @columnfractions .3 .4 .3 |
|
6572
|
303 @item @code{RowVector} @tab @code{row_vector_value} @tab @file{dRowVector.h} |
|
|
304 @item @code{ComplexRowVector} @tab @code{complex_row_vector_value} @tab @file{CRowVector.h} |
|
|
305 @item @code{ColumnVector} @tab @code{column_vector_value} @tab @file{dColVector.h} |
|
|
306 @item @code{ComplexColumnVector} @tab @code{complex_column_vector_value} @tab @file{CColVector.h} |
|
|
307 @item @code{Matrix} @tab @code{matrix_value} @tab @file{dMatrix.h} |
|
|
308 @item @code{ComplexMatrix} @tab @code{complex_matrix_value} @tab @file{CMatrix.h} |
|
|
309 @item @code{boolMatrix} @tab @code{bool_matrix_value} @tab @file{boolMatrix.h} |
|
|
310 @item @code{charMatrix} @tab @code{char_matrix_value} @tab @file{chMatrix.h} |
|
|
311 @item @code{NDArray} @tab @code{array_value} @tab @file{dNDArray.h} |
|
|
312 @item @code{ComplexNDArray} @tab @code{complex_array_value} @tab @file{CNDArray.h} |
|
|
313 @item @code{boolNDArray} @tab @code{bool_array_value} @tab @file{boolNDArray.h} |
|
|
314 @item @code{charNDArray} @tab @code{char_array_value} @tab @file{charNDArray.h} |
|
|
315 @item @code{int8NDArray} @tab @code{int8_array_value} @tab @file{int8NDArray.h} |
|
|
316 @item @code{int16NDArray} @tab @code{int16_array_value} @tab @file{int16NDArray.h} |
|
|
317 @item @code{int32NDArray} @tab @code{int32_array_value} @tab @file{int32NDArray.h} |
|
|
318 @item @code{int64NDArray} @tab @code{int64_array_value} @tab @file{int64NDArray.h} |
|
|
319 @item @code{uint8NDArray} @tab @code{uint8_array_value} @tab @file{uint8NDArray.h} |
|
|
320 @item @code{uint16NDArray} @tab @code{uint16_array_value} @tab @file{uint16NDArray.h} |
|
|
321 @item @code{uint32NDArray} @tab @code{uint32_array_value} @tab @file{uint32NDArray.h} |
|
|
322 @item @code{uint64NDArray} @tab @code{uint64_array_value} @tab @file{uint64NDArray.h} |
|
6569
|
323 @end multitable |
|
|
324 |
|
6572
|
325 @node Character Strings in Oct-Files |
|
|
326 @subsection Character Strings in Oct-Files |
|
|
327 |
|
|
328 In Octave a character string is just a special @code{Array} class. |
|
|
329 Consider the example |
|
|
330 |
|
|
331 @example |
|
|
332 @group |
|
6577
|
333 @verbatiminclude @value{top_srcdir}/examples/stringdemo.cc |
|
6572
|
334 @end group |
|
|
335 @end example |
|
|
336 |
|
|
337 An example of the of the use of this function is |
|
|
338 |
|
|
339 @example |
|
|
340 @group |
|
|
341 s0 = ["First String"; "Second String"]; |
|
|
342 [s1,s2] = stringdemo (s0) |
|
|
343 @result{} s1 = Second String |
|
|
344 First String |
|
|
345 |
|
|
346 @result{} s2 = First String |
|
|
347 Second String |
|
|
348 |
|
|
349 typeinfo (s2) |
|
|
350 @result{} sq_string |
|
|
351 typeinfo (s1) |
|
|
352 @result{} string |
|
|
353 @end group |
|
|
354 @end example |
|
|
355 |
|
|
356 One additional complication of strings in Octave is the difference |
|
|
357 between single quoted and double quoted strings. To find out if an |
|
|
358 @code{octave_value} contains a single or double quoted string an example is |
|
|
359 |
|
|
360 @example |
|
|
361 @group |
|
|
362 if (args(0).is_sq_string ()) |
|
|
363 octave_stdout << "First argument is a singularly quoted string\n"; |
|
|
364 else if (args(0).is_dq_string ()) |
|
|
365 octave_stdout << "First argument is a doubly quoted string\n"; |
|
|
366 @end group |
|
|
367 @end example |
|
|
368 |
|
|
369 Note however, that both types of strings are represented by the |
|
|
370 @code{charNDArray} type, and so when assigning to an |
|
|
371 @code{octave_value}, the type of string should be specified. For example |
|
|
372 |
|
|
373 @example |
|
|
374 @group |
|
|
375 octave_value_list retval; |
|
|
376 charNDArray c; |
|
|
377 @dots{} |
|
6577
|
378 // Create single quoted string |
|
|
379 retval(1) = octave_value (ch, true, '\''); |
|
|
380 |
|
|
381 // Create a double quoted string |
|
|
382 retval(0) = octave_value (ch, true); |
|
6572
|
383 @end group |
|
|
384 @end example |
|
|
385 |
|
|
386 @node Cell Arrays in Oct-Files |
|
|
387 @subsection Cell Arrays in Oct-Files |
|
|
388 |
|
|
389 Octave's cell type is equally accessible within an oct-files. A cell |
|
|
390 array is just an array of @code{octave_value}s, and so each element of the cell |
|
|
391 array can then be treated just like any other @code{octave_value}. A simple |
|
|
392 example is |
|
|
393 |
|
|
394 @example |
|
|
395 @group |
|
6577
|
396 @verbatiminclude @value{top_srcdir}/examples/celldemo.cc |
|
6572
|
397 @end group |
|
|
398 @end example |
|
|
399 |
|
|
400 Note that cell arrays are used less often in standard oct-files and so |
|
|
401 the @file{Cell.h} header file must be explicitly included. The rest of this |
|
|
402 example extracts the @code{octave_value}s one by one from the cell array and |
|
|
403 returns be as individual return arguments. For example consider |
|
|
404 |
|
|
405 @example |
|
|
406 @group |
|
|
407 [b1, b2, b3] = celldemo (@{1, [1, 2], "test"@}) |
|
|
408 @result{} |
|
|
409 b1 = 1 |
|
|
410 b2 = |
|
|
411 |
|
|
412 1 2 |
|
|
413 |
|
|
414 b3 = test |
|
|
415 @end group |
|
|
416 @end example |
|
|
417 |
|
|
418 @node Structures in Oct-Files |
|
|
419 @subsection Structures in Oct-Files |
|
|
420 |
|
|
421 A structure in Octave is map between a number of fields represented and |
|
|
422 their values. The Standard Template Library @code{map} class is used, |
|
|
423 with the pair consisting of a @code{std::string} and an octave |
|
|
424 @code{Cell} variable. |
|
|
425 |
|
|
426 A simple example demonstrating the use of structures within oct-files is |
|
|
427 |
|
|
428 @example |
|
|
429 @group |
|
6577
|
430 @verbatiminclude @value{top_srcdir}/examples/structdemo.cc |
|
6572
|
431 @end group |
|
|
432 @end example |
|
|
433 |
|
|
434 An example of its use is |
|
|
435 |
|
|
436 @example |
|
|
437 @group |
|
|
438 x.a = 1; x.b = "test"; x.c = [1, 2]; |
|
|
439 structdemo (x, "b") |
|
|
440 @result{} selected = test |
|
|
441 @end group |
|
|
442 @end example |
|
|
443 |
|
|
444 The commented code above demonstrates how to iterated over all of the |
|
|
445 fields of the structure, where as the following code demonstrates finding |
|
|
446 a particular field in a more concise manner. |
|
|
447 |
|
|
448 As can be seen the @code{contents} method of the @code{Octave_map} class |
|
|
449 returns a @code{Cell} which allows structure arrays to be represented. |
|
|
450 Therefore, to obtain the underlying @code{octave_value} we write |
|
|
451 |
|
|
452 @example |
|
|
453 octave_value tmp = arg0.contents (p1) (0); |
|
|
454 @end example |
|
|
455 |
|
|
456 where the trailing (0) is the () operator on the @code{Cell} object. |
|
|
457 |
|
|
458 @node Sparse Matrices in Oct-Files |
|
|
459 @subsection Sparse Matrices in Oct-Files |
|
6569
|
460 |
|
|
461 There are three classes of sparse objects that are of interest to the |
|
|
462 user. |
|
|
463 |
|
6572
|
464 @table @code |
|
6569
|
465 @item SparseMatrix |
|
|
466 A double precision sparse matrix class |
|
|
467 @item SparseComplexMatrix |
|
|
468 A complex sparse matrix class |
|
|
469 @item SparseBoolMatrix |
|
|
470 A boolean sparse matrix class |
|
|
471 @end table |
|
|
472 |
|
|
473 All of these classes inherit from the @code{Sparse<T>} template class, |
|
6571
|
474 and so all have similar capabilities and usage. The @code{Sparse<T>} |
|
6569
|
475 class was based on Octave @code{Array<T>} class, and so users familiar |
|
6572
|
476 with Octave's @code{Array} classes will be comfortable with the use of |
|
6569
|
477 the sparse classes. |
|
|
478 |
|
|
479 The sparse classes will not be entirely described in this section, due |
|
6572
|
480 to their similarity with the existing @code{Array} classes. However, |
|
|
481 there are a few differences due the different nature of sparse objects, |
|
|
482 and these will be described. Firstly, although it is fundamentally |
|
|
483 possible to have N-dimensional sparse objects, the Octave sparse classes do |
|
6571
|
484 not allow them at this time. So all operations of the sparse classes |
|
6569
|
485 must be 2-dimensional. This means that in fact @code{SparseMatrix} is |
|
|
486 similar to Octave's @code{Matrix} class rather than its |
|
|
487 @code{NDArray} class. |
|
|
488 |
|
|
489 @menu |
|
6572
|
490 * Array and Sparse Differences:: |
|
|
491 * Creating Sparse Matrices in Oct-Files:: |
|
|
492 * Using Sparse Matrices in Oct-Files:: |
|
6569
|
493 @end menu |
|
|
494 |
|
6572
|
495 @node Array and Sparse Differences |
|
6569
|
496 @subsubsection The Differences between the Array and Sparse Classes |
|
|
497 |
|
|
498 The number of elements in a sparse matrix is considered to be the number |
|
6571
|
499 of non-zero elements rather than the product of the dimensions. Therefore |
|
6569
|
500 |
|
|
501 @example |
|
6577
|
502 @group |
|
|
503 SparseMatrix sm; |
|
|
504 @dots{} |
|
|
505 int nel = sm.nelem (); |
|
|
506 @end group |
|
6569
|
507 @end example |
|
|
508 |
|
6571
|
509 returns the number of non-zero elements. If the user really requires the |
|
6569
|
510 number of elements in the matrix, including the non-zero elements, they |
|
6571
|
511 should use @code{numel} rather than @code{nelem}. Note that for very |
|
6569
|
512 large matrices, where the product of the two dimensions is large that |
|
|
513 the representation of the an unsigned int, then @code{numel} can overflow. |
|
|
514 An example is @code{speye(1e6)} which will create a matrix with a million |
|
6571
|
515 rows and columns, but only a million non-zero elements. Therefore the |
|
6569
|
516 number of rows by the number of columns in this case is more than two |
|
|
517 hundred times the maximum value that can be represented by an unsigned int. |
|
|
518 The use of @code{numel} should therefore be avoided useless it is known |
|
|
519 it won't overflow. |
|
|
520 |
|
|
521 Extreme care must be take with the elem method and the "()" operator, |
|
6571
|
522 which perform basically the same function. The reason is that if a |
|
6569
|
523 sparse object is non-const, then Octave will assume that a |
|
6571
|
524 request for a zero element in a sparse matrix is in fact a request |
|
|
525 to create this element so it can be filled. Therefore a piece of |
|
6569
|
526 code like |
|
|
527 |
|
|
528 @example |
|
6577
|
529 @group |
|
|
530 SparseMatrix sm; |
|
|
531 @dots{} |
|
|
532 for (int j = 0; j < nc; j++) |
|
|
533 for (int i = 0; i < nr; i++) |
|
|
534 std::cerr << " (" << i << "," << j << "): " << sm(i,j) |
|
|
535 << std::endl; |
|
|
536 @end group |
|
6569
|
537 @end example |
|
|
538 |
|
|
539 is a great way of turning the sparse matrix into a dense one, and a |
|
|
540 very slow way at that since it reallocates the sparse object at each |
|
|
541 zero element in the matrix. |
|
|
542 |
|
|
543 An easy way of preventing the above from happening is to create a temporary |
|
6571
|
544 constant version of the sparse matrix. Note that only the container for |
|
6569
|
545 the sparse matrix will be copied, while the actual representation of the |
|
6571
|
546 data will be shared between the two versions of the sparse matrix. So this |
|
|
547 is not a costly operation. For example, the above would become |
|
6569
|
548 |
|
|
549 @example |
|
6577
|
550 @group |
|
|
551 SparseMatrix sm; |
|
|
552 @dots{} |
|
|
553 const SparseMatrix tmp (sm); |
|
|
554 for (int j = 0; j < nc; j++) |
|
|
555 for (int i = 0; i < nr; i++) |
|
|
556 std::cerr << " (" << i << "," << j << "): " << tmp(i,j) |
|
|
557 << std::endl; |
|
|
558 @end group |
|
6569
|
559 @end example |
|
|
560 |
|
|
561 Finally, as the sparse types aren't just represented as a contiguous |
|
|
562 block of memory, the @code{fortran_vec} method of the @code{Array<T>} |
|
6571
|
563 is not available. It is however replaced by three separate methods |
|
6569
|
564 @code{ridx}, @code{cidx} and @code{data}, that access the raw compressed |
|
|
565 column format that the Octave sparse matrices are stored in. |
|
|
566 Additionally, these methods can be used in a manner similar to @code{elem}, |
|
6571
|
567 to allow the matrix to be accessed or filled. However, in that case it is |
|
6569
|
568 up to the user to respect the sparse matrix compressed column format |
|
|
569 discussed previous. |
|
|
570 |
|
6572
|
571 @node Creating Sparse Matrices in Oct-Files |
|
|
572 @subsubsection Creating Sparse Matrices in Oct-Files |
|
6569
|
573 |
|
6572
|
574 You have several alternatives for creating a sparse matrix. |
|
|
575 You can first create the data as three vectors representing the |
|
6569
|
576 row and column indexes and the data, and from those create the matrix. |
|
6572
|
577 Or alternatively, you can create a sparse matrix with the appropriate |
|
6571
|
578 amount of space and then fill in the values. Both techniques have their |
|
6569
|
579 advantages and disadvantages. |
|
|
580 |
|
6572
|
581 Here is an example of how to create a small sparse matrix with the first |
|
|
582 technique |
|
6569
|
583 |
|
|
584 @example |
|
6577
|
585 @group |
|
|
586 int nz = 4, nr = 3, nc = 4; |
|
|
587 |
|
|
588 ColumnVector ridx (nz); |
|
|
589 ColumnVector cidx (nz); |
|
|
590 ColumnVector data (nz); |
|
6569
|
591 |
|
6577
|
592 ridx(0) = 0; ridx(1) = 0; ridx(2) = 1; ridx(3) = 2; |
|
|
593 cidx(0) = 0; cidx(1) = 1; cidx(2) = 3; cidx(3) = 3; |
|
|
594 data(0) = 1; data(1) = 2; data(2) = 3; data(3) = 4; |
|
6569
|
595 |
|
6577
|
596 SparseMatrix sm (data, ridx, cidx, nr, nc); |
|
|
597 @end group |
|
6569
|
598 @end example |
|
|
599 |
|
6572
|
600 @noindent |
|
6571
|
601 which creates the matrix given in section @ref{Storage}. Note that |
|
6569
|
602 the compressed matrix format is not used at the time of the creation |
|
6571
|
603 of the matrix itself, however it is used internally. |
|
6569
|
604 |
|
|
605 As previously mentioned, the values of the sparse matrix are stored |
|
6571
|
606 in increasing column-major ordering. Although the data passed by the |
|
6569
|
607 user does not need to respect this requirement, the pre-sorting the |
|
|
608 data significantly speeds up the creation of the sparse matrix. |
|
|
609 |
|
|
610 The disadvantage of this technique of creating a sparse matrix is |
|
6571
|
611 that there is a brief time where two copies of the data exists. Therefore |
|
6569
|
612 for extremely memory constrained problems this might not be the right |
|
|
613 technique to create the sparse matrix. |
|
|
614 |
|
|
615 The alternative is to first create the sparse matrix with the desired |
|
6571
|
616 number of non-zero elements and then later fill those elements in. The |
|
|
617 easiest way to do this is |
|
6569
|
618 |
|
6571
|
619 @example |
|
6577
|
620 @group |
|
|
621 int nz = 4, nr = 3, nc = 4; |
|
|
622 SparseMatrix sm (nr, nc, nz); |
|
|
623 sm(0,0) = 1; sm(0,1) = 2; sm(1,3) = 3; sm(2,3) = 4; |
|
|
624 @end group |
|
6569
|
625 @end example |
|
|
626 |
|
6571
|
627 That creates the same matrix as previously. Again, although it is not |
|
6569
|
628 strictly necessary, it is significantly faster if the sparse matrix is |
|
|
629 created in this manner that the elements are added in column-major |
|
6571
|
630 ordering. The reason for this is that if the elements are inserted |
|
6569
|
631 at the end of the current list of known elements then no element |
|
|
632 in the matrix needs to be moved to allow the new element to be |
|
6571
|
633 inserted. Only the column indexes need to be updated. |
|
6569
|
634 |
|
|
635 There are a few further points to note about this technique of creating |
|
6572
|
636 a sparse matrix. Firstly, it is possible to create a sparse matrix |
|
6571
|
637 with fewer elements than are actually inserted in the matrix. Therefore |
|
6569
|
638 |
|
6571
|
639 @example |
|
6577
|
640 @group |
|
|
641 int nz = 4, nr = 3, nc = 4; |
|
|
642 SparseMatrix sm (nr, nc, 0); |
|
|
643 sm(0,0) = 1; sm(0,1) = 2; sm(1,3) = 3; sm(2,3) = 4; |
|
|
644 @end group |
|
6569
|
645 @end example |
|
|
646 |
|
6572
|
647 @noindent |
|
|
648 is perfectly valid. However it is a very bad idea. The reason is that |
|
6569
|
649 as each new element is added to the sparse matrix the space allocated |
|
6571
|
650 to it is increased by reallocating the memory. This is an expensive |
|
6569
|
651 operation, that will significantly slow this means of creating a sparse |
|
6572
|
652 matrix. Furthermore, it is possible to create a sparse matrix with |
|
|
653 too much storage, so having @var{nz} above equaling 6 is also valid. |
|
6569
|
654 The disadvantage is that the matrix occupies more memory than strictly |
|
|
655 needed. |
|
|
656 |
|
6572
|
657 It is not always easy to know the number of non-zero elements prior |
|
6571
|
658 to filling a matrix. For this reason the additional storage for the |
|
6569
|
659 sparse matrix can be removed after its creation with the |
|
6571
|
660 @dfn{maybe_compress} function. Furthermore, the maybe_compress can |
|
6569
|
661 deallocate the unused storage, but it can equally remove zero elements |
|
|
662 from the matrix. The removal of zero elements from the matrix is |
|
|
663 controlled by setting the argument of the @dfn{maybe_compress} function |
|
6572
|
664 to be @samp{true}. However, the cost of removing the zeros is high because it |
|
6571
|
665 implies resorting the elements. Therefore, if possible it is better |
|
|
666 is the user doesn't add the zeros in the first place. An example of |
|
6569
|
667 the use of @dfn{maybe_compress} is |
|
|
668 |
|
|
669 @example |
|
6577
|
670 @group |
|
6569
|
671 int nz = 6, nr = 3, nc = 4; |
|
6577
|
672 |
|
6569
|
673 SparseMatrix sm1 (nr, nc, nz); |
|
|
674 sm1(0,0) = 1; sm1(0,1) = 2; sm1(1,3) = 3; sm1(2,3) = 4; |
|
|
675 sm1.maybe_compress (); // No zero elements were added |
|
|
676 |
|
|
677 SparseMatrix sm2 (nr, nc, nz); |
|
6571
|
678 sm2(0,0) = 1; sm2(0,1) = 2; sm(0,2) = 0; sm(1,2) = 0; |
|
6569
|
679 sm1(1,3) = 3; sm1(2,3) = 4; |
|
|
680 sm2.maybe_compress (true); // Zero elements were added |
|
6577
|
681 @end group |
|
6569
|
682 @end example |
|
|
683 |
|
|
684 The use of the @dfn{maybe_compress} function should be avoided if |
|
|
685 possible, as it will slow the creation of the matrices. |
|
|
686 |
|
|
687 A third means of creating a sparse matrix is to work directly with |
|
6571
|
688 the data in compressed row format. An example of this technique might |
|
6569
|
689 be |
|
|
690 |
|
|
691 @c Note the @verbatim environment is a relatively new addition to texinfo. |
|
6571
|
692 @c Therefore use the @example environment and replace @, with @@, |
|
6569
|
693 @c { with @{, etc |
|
|
694 |
|
|
695 @example |
|
6577
|
696 @group |
|
|
697 octave_value arg; |
|
|
698 @dots{} |
|
|
699 int nz = 6, nr = 3, nc = 4; // Assume we know the max no nz |
|
|
700 SparseMatrix sm (nr, nc, nz); |
|
|
701 Matrix m = arg.matrix_value (); |
|
6569
|
702 |
|
6577
|
703 int ii = 0; |
|
|
704 sm.cidx (0) = 0; |
|
|
705 for (int j = 1; j < nc; j++) |
|
|
706 @{ |
|
|
707 for (int i = 0; i < nr; i++) |
|
|
708 @{ |
|
|
709 double tmp = foo (m(i,j)); |
|
|
710 if (tmp != 0.) |
|
|
711 @{ |
|
|
712 sm.data(ii) = tmp; |
|
|
713 sm.ridx(ii) = i; |
|
|
714 ii++; |
|
|
715 @} |
|
|
716 @} |
|
|
717 sm.cidx(j+1) = ii; |
|
|
718 @} |
|
|
719 sm.maybe_compress (); // If don't know a-priori the final no of nz. |
|
|
720 @end group |
|
6569
|
721 @end example |
|
|
722 |
|
6572
|
723 @noindent |
|
6569
|
724 which is probably the most efficient means of creating the sparse matrix. |
|
|
725 |
|
|
726 Finally, it might sometimes arise that the amount of storage initially |
|
6571
|
727 created is insufficient to completely store the sparse matrix. Therefore, |
|
6569
|
728 the method @code{change_capacity} exists to reallocate the sparse memory. |
|
6571
|
729 The above example would then be modified as |
|
6569
|
730 |
|
|
731 @example |
|
6577
|
732 @group |
|
|
733 octave_value arg; |
|
|
734 @dots{} |
|
|
735 int nz = 6, nr = 3, nc = 4; // Assume we know the max no nz |
|
|
736 SparseMatrix sm (nr, nc, nz); |
|
|
737 Matrix m = arg.matrix_value (); |
|
6569
|
738 |
|
6577
|
739 int ii = 0; |
|
|
740 sm.cidx (0) = 0; |
|
|
741 for (int j = 1; j < nc; j++) |
|
|
742 @{ |
|
|
743 for (int i = 0; i < nr; i++) |
|
|
744 @{ |
|
|
745 double tmp = foo (m(i,j)); |
|
|
746 if (tmp != 0.) |
|
|
747 @{ |
|
|
748 if (ii == nz) |
|
|
749 @{ |
|
|
750 nz += 2; // Add 2 more elements |
|
|
751 sm.change_capacity (nz); |
|
|
752 @} |
|
|
753 sm.data(ii) = tmp; |
|
|
754 sm.ridx(ii) = i; |
|
|
755 ii++; |
|
|
756 @} |
|
|
757 @} |
|
|
758 sm.cidx(j+1) = ii; |
|
|
759 @} |
|
|
760 sm.maybe_mutate (); // If don't know a-priori the final no of nz. |
|
|
761 @end group |
|
6569
|
762 @end example |
|
|
763 |
|
|
764 Note that both increasing and decreasing the number of non-zero elements in |
|
6571
|
765 a sparse matrix is expensive, as it involves memory reallocation. Also as |
|
6569
|
766 parts of the matrix, though not its entirety, exist as the old and new copy |
|
6571
|
767 at the same time, additional memory is needed. Therefore if possible this |
|
6569
|
768 should be avoided. |
|
|
769 |
|
6572
|
770 @node Using Sparse Matrices in Oct-Files |
|
6569
|
771 @subsubsection Using Sparse Matrices in Oct-Files |
|
|
772 |
|
|
773 Most of the same operators and functions on sparse matrices that are |
|
|
774 available from the Octave are equally available with oct-files. |
|
|
775 The basic means of extracting a sparse matrix from an @code{octave_value} |
|
|
776 and returning them as an @code{octave_value}, can be seen in the |
|
|
777 following example |
|
|
778 |
|
|
779 @example |
|
6577
|
780 @group |
|
|
781 octave_value_list retval; |
|
6569
|
782 |
|
6577
|
783 SparseMatrix sm = args(0).sparse_matrix_value (); |
|
|
784 SparseComplexMatrix scm = args(1).sparse_complex_matrix_value (); |
|
|
785 SparseBoolMatrix sbm = args(2).sparse_bool_matrix_value (); |
|
|
786 @dots{} |
|
|
787 retval(2) = sbm; |
|
|
788 retval(1) = scm; |
|
|
789 retval(0) = sm; |
|
|
790 @end group |
|
6569
|
791 @end example |
|
|
792 |
|
|
793 The conversion to an octave-value is handled by the sparse |
|
|
794 @code{octave_value} constructors, and so no special care is needed. |
|
|
795 |
|
|
796 @node Accessing Global Variables in Oct-Files |
|
|
797 @subsection Accessing Global Variables in Oct-Files |
|
|
798 |
|
|
799 Global variables allow variables in the global scope to be |
|
6571
|
800 accessed. Global variables can easily be accessed with oct-files using |
|
6569
|
801 the support functions @code{get_global_value} and |
|
6571
|
802 @code{set_global_value}. @code{get_global_value} takes two arguments, |
|
|
803 the first is a string representing the variable name to obtain. The |
|
6569
|
804 second argument is a boolean argument specifying what to do in the case |
|
6571
|
805 that no global variable of the desired name is found. An example of the |
|
6569
|
806 use of these two functions is |
|
|
807 |
|
|
808 @example |
|
|
809 @group |
|
6577
|
810 @verbatiminclude @value{top_srcdir}/examples/globaldemo.cc |
|
6569
|
811 @end group |
|
6571
|
812 @end example |
|
6569
|
813 |
|
|
814 An example of its use is |
|
|
815 |
|
|
816 @example |
|
|
817 @group |
|
|
818 global a b |
|
|
819 b = 10; |
|
|
820 globaldemo ("b") |
|
|
821 @result{} 10 |
|
|
822 globaldemo ("c") |
|
|
823 @result{} "Global variable not found" |
|
|
824 num2str (a) |
|
|
825 @result{} 42 |
|
|
826 @end group |
|
|
827 @end example |
|
|
828 |
|
|
829 @node Calling Octave Functions from Oct-Files |
|
|
830 @subsection Calling Octave Functions from Oct-Files |
|
|
831 |
|
|
832 There is often a need to be able to call another octave function from |
|
|
833 within an oct-file, and there are many examples of such within octave |
|
6571
|
834 itself. For example the @code{quad} function is an oct-file that |
|
6569
|
835 calculates the definite integral by quadrature over a user supplied |
|
|
836 function. |
|
|
837 |
|
6571
|
838 There are also many ways in which a function might be passed. It might |
|
|
839 be passed as one of |
|
6569
|
840 |
|
|
841 @enumerate 1 |
|
|
842 @item Function Handle |
|
|
843 @item Anonymous Function Handle |
|
|
844 @item Inline Function |
|
|
845 @item String |
|
|
846 @end enumerate |
|
|
847 |
|
|
848 The example below demonstrates an example that accepts all four means of |
|
6571
|
849 passing a function to an oct-file. |
|
6569
|
850 |
|
|
851 @example |
|
|
852 @group |
|
6577
|
853 @verbatiminclude @value{top_srcdir}/examples/funcdemo.cc |
|
6569
|
854 @end group |
|
|
855 @end example |
|
|
856 |
|
|
857 The first argument to this demonstration is the user supplied function |
|
|
858 and the following arguments are all passed to the user function. |
|
|
859 |
|
|
860 @example |
|
|
861 @group |
|
6572
|
862 funcdemo (@@sin,1) |
|
6569
|
863 @result{} 0.84147 |
|
6572
|
864 funcdemo (@@(x) sin(x), 1) |
|
6569
|
865 @result{} 0.84147 |
|
6572
|
866 funcdemo (inline ("sin(x)"), 1) |
|
6569
|
867 @result{} 0.84147 |
|
6572
|
868 funcdemo ("sin",1) |
|
6569
|
869 @result{} 0.84147 |
|
|
870 funcdemo (@@atan2, 1, 1) |
|
|
871 @result{} 0.78540 |
|
|
872 @end group |
|
|
873 @end example |
|
|
874 |
|
|
875 When the user function is passed as a string, the treatment of the |
|
6571
|
876 function is different. In some cases it is necessary to always have the |
|
6572
|
877 user supplied function as an @code{octave_function} object. In that |
|
|
878 case the string argument can be used to create a temporary function like |
|
6569
|
879 |
|
|
880 @example |
|
|
881 @group |
|
6577
|
882 std::octave fcn_name = unique_symbol_name ("__fcn__"); |
|
|
883 std::string fname = "function y = "; |
|
|
884 fname.append (fcn_name); |
|
|
885 fname.append ("(x) y = "); |
|
|
886 fcn = extract_function (args(0), "funcdemo", fcn_name, |
|
|
887 fname, "; endfunction"); |
|
|
888 @dots{} |
|
|
889 if (fcn_name.length ()) |
|
|
890 clear_function (fcn_name); |
|
6569
|
891 @end group |
|
|
892 @end example |
|
|
893 |
|
6571
|
894 There are two important things to know in this case. The number of input |
|
6569
|
895 arguments to the user function is fixed, and in the above is a single |
|
|
896 argument, and secondly to avoid leaving the temporary function in the |
|
|
897 Octave symbol table it should be cleared after use. |
|
|
898 |
|
|
899 @node Calling External Code from Oct-Files |
|
|
900 @subsection Calling External Code from Oct-Files |
|
|
901 |
|
|
902 Linking external C code to Octave is relatively simple, as the C |
|
6571
|
903 functions can easily be called directly from C++. One possible issue is |
|
6569
|
904 the declarations of the external C functions might need to be explicitly |
|
6571
|
905 defined as C functions to the compiler. If the declarations of the |
|
6569
|
906 external C functions are in the header @code{foo.h}, then the manner in |
|
|
907 which to ensure that the C++ compiler treats these declarations as C |
|
|
908 code is |
|
|
909 |
|
|
910 @example |
|
|
911 @group |
|
|
912 #ifdef __cplusplus |
|
6571
|
913 extern "C" |
|
6569
|
914 @{ |
|
|
915 #endif |
|
|
916 #include "foo.h" |
|
|
917 #ifdef __cplusplus |
|
|
918 @} /* end extern "C" */ |
|
|
919 #endif |
|
|
920 @end group |
|
|
921 @end example |
|
|
922 |
|
6571
|
923 Calling Fortran code however can pose some difficulties. This is due to |
|
6569
|
924 differences in the manner in compilers treat the linking of Fortran code |
|
6571
|
925 with C or C++ code. Octave supplies a number of macros that allow |
|
6569
|
926 consistent behavior across a number of compilers. |
|
|
927 |
|
|
928 The underlying Fortran code should use the @code{XSTOPX} function to |
|
6571
|
929 replace the Fortran @code{STOP} function. @code{XSTOPX} uses the Octave |
|
6569
|
930 exception handler to treat failing cases in the fortran code |
|
6571
|
931 explicitly. Note that Octave supplies its own replacement blas |
|
6569
|
932 @code{XERBLA} function, which uses @code{XSTOPX}. |
|
|
933 |
|
6572
|
934 If the underlying code calls @code{XSTOPX}, then the @code{F77_XFCN} |
|
6571
|
935 macro should be used to call the underlying fortran function. The Fortran |
|
6569
|
936 exception state can then be checked with the global variable |
|
6572
|
937 @code{f77_exception_encountered}. If @code{XSTOPX} will not be called, |
|
6569
|
938 then the @code{F77_FCN} macro should be used instead to call the Fortran |
|
|
939 code. |
|
|
940 |
|
|
941 There is no harm in using @code{F77_XFCN} in all cases, except that for |
|
|
942 Fortran code that is short running and executes a large number of times, |
|
6571
|
943 there is potentially an overhead in doing so. However, if @code{F77_FCN} |
|
6569
|
944 is used with code that calls @code{XSTOP}, Octave can generate a |
|
|
945 segmentation fault. |
|
|
946 |
|
|
947 An example of the inclusion of a Fortran function in an oct-file is |
|
|
948 given in the following example, where the C++ wrapper is |
|
|
949 |
|
|
950 @example |
|
|
951 @group |
|
6577
|
952 @verbatiminclude @value{top_srcdir}/examples/fortdemo.cc |
|
6569
|
953 @end group |
|
|
954 @end example |
|
|
955 |
|
6572
|
956 @noindent |
|
6569
|
957 and the fortran function is |
|
|
958 |
|
|
959 @example |
|
|
960 @group |
|
6577
|
961 @verbatiminclude @value{top_srcdir}/examples/fortsub.f |
|
6569
|
962 @end group |
|
|
963 @end example |
|
|
964 |
|
|
965 This example demonstrates most of the features needed to link to an |
|
|
966 external Fortran function, including passing arrays and strings, as well |
|
6571
|
967 as exception handling. An example of the behavior of this function is |
|
6569
|
968 |
|
|
969 @example |
|
|
970 @group |
|
6572
|
971 [b, s] = fortdemo (1:3) |
|
6569
|
972 @result{} |
|
|
973 b = 1.00000 0.50000 0.33333 |
|
|
974 s = There are 3 values in the input vector |
|
|
975 [b, s] = fortdemo(0:3) |
|
|
976 error: fortsub:divide by zero |
|
|
977 error: exception encountered in Fortran subroutine fortsub_ |
|
|
978 error: fortdemo: error in fortran |
|
|
979 @end group |
|
|
980 @end example |
|
|
981 |
|
|
982 @node Allocating Local Memory in Oct-Files |
|
|
983 @subsection Allocating Local Memory in Oct-Files |
|
|
984 |
|
|
985 Allocating memory within an oct-file might seem easy as the C++ |
|
6571
|
986 new/delete operators can be used. However, in that case care must be |
|
|
987 taken to avoid memory leaks. The preferred manner in which to allocate |
|
6572
|
988 memory for use locally is to use the @code{OCTAVE_LOCAL_BUFFER} macro. |
|
|
989 An example of its use is |
|
6569
|
990 |
|
|
991 @example |
|
|
992 OCTAVE_LOCAL_BUFFER (double, tmp, len) |
|
|
993 @end example |
|
|
994 |
|
|
995 that returns a pointer @code{tmp} of type @code{double *} of length |
|
|
996 @code{len}. |
|
|
997 |
|
|
998 @node Input Parameter Checking in Oct-Files |
|
|
999 @subsection Input Parameter Checking in Oct-Files |
|
|
1000 |
|
|
1001 WRITE ME |
|
|
1002 |
|
|
1003 @node Exception and Error Handling in Oct-Files |
|
|
1004 @subsection Exception and Error Handling in Oct-Files |
|
|
1005 |
|
|
1006 Another important feature of Octave is its ability to react to the user |
|
6571
|
1007 typing @kbd{Control-C} even during calculations. This ability is based on the |
|
6569
|
1008 C++ exception handler, where memory allocated by the C++ new/delete |
|
6571
|
1009 methods are automatically released when the exception is treated. When |
|
6569
|
1010 writing an oct-file, to allow Octave to treat the user typing @kbd{Control-C}, |
|
6571
|
1011 the @code{OCTAVE_QUIT} macro is supplied. For example |
|
6569
|
1012 |
|
|
1013 @example |
|
|
1014 @group |
|
6577
|
1015 for (octave_idx_type i = 0; i < a.nelem (); i++) |
|
|
1016 @{ |
|
|
1017 OCTAVE_QUIT; |
|
|
1018 b.elem(i) = 2. * a.elem(i); |
|
|
1019 @} |
|
6569
|
1020 @end group |
|
|
1021 @end example |
|
|
1022 |
|
6572
|
1023 The presence of the @code{OCTAVE_QUIT} macro in the inner loop allows Octave to |
|
6571
|
1024 treat the user request with the @kbd{Control-C}. Without this macro, the user |
|
6569
|
1025 must either wait for the function to return before the interrupt is |
|
|
1026 processed, or press @kbd{Control-C} three times to force Octave to exit. |
|
|
1027 |
|
6572
|
1028 The @code{OCTAVE_QUIT} macro does impose a very small speed penalty, and so for |
|
6569
|
1029 loops that are known to be small it might not make sense to include |
|
6572
|
1030 @code{OCTAVE_QUIT}. |
|
6569
|
1031 |
|
|
1032 When creating an oct-file that uses an external libraries, the function |
|
|
1033 might spend a significant portion of its time in the external |
|
6572
|
1034 library. It is not generally possible to use the @code{OCTAVE_QUIT} macro in |
|
6571
|
1035 this case. The alternative in this case is |
|
6569
|
1036 |
|
|
1037 @example |
|
|
1038 @group |
|
6577
|
1039 BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE; |
|
|
1040 @dots{} some code that calls a "foreign" function @dots{} |
|
|
1041 END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE; |
|
6569
|
1042 @end group |
|
|
1043 @end example |
|
|
1044 |
|
|
1045 The disadvantage of this is that if the foreign code allocates any |
|
|
1046 memory internally, then this memory might be lost during an interrupt, |
|
6571
|
1047 without being deallocated. Therefore, ideally Octave itself should |
|
6569
|
1048 allocate any memory that is needed by the foreign code, with either the |
|
6572
|
1049 fortran_vec method or the @code{OCTAVE_LOCAL_BUFFER} macro. |
|
6569
|
1050 |
|
6571
|
1051 The Octave unwind_protect mechanism (@ref{The unwind_protect Statement}) |
|
|
1052 can also be used in oct-files. In conjunction with the exception |
|
6569
|
1053 handling of Octave, it is important to enforce that certain code is run |
|
6571
|
1054 to allow variables, etc to be restored even if an exception occurs. An |
|
6569
|
1055 example of the use of this mechanism is |
|
|
1056 |
|
|
1057 @example |
|
|
1058 @group |
|
6577
|
1059 @verbatiminclude @value{top_srcdir}/examples/unwinddemo.cc |
|
6569
|
1060 @end group |
|
|
1061 @end example |
|
|
1062 |
|
|
1063 As can be seen in the example |
|
|
1064 |
|
|
1065 @example |
|
|
1066 @group |
|
6572
|
1067 unwinddemo (1, 0) |
|
6569
|
1068 @result{} Inf |
|
|
1069 1 / 0 |
|
|
1070 @result{} warning: division by zero |
|
|
1071 Inf |
|
|
1072 @end group |
|
|
1073 @end example |
|
|
1074 |
|
|
1075 The division by zero (and in fact all warnings) is disabled in the |
|
|
1076 @code{unwinddemo} function. |
|
|
1077 |
|
|
1078 @node Documentation and Test of Oct-Files |
|
|
1079 @subsection Documentation and Test of Oct-Files |
|
|
1080 |
|
6572
|
1081 WRITE ME, reference how to use Texinfo in oct-file and embed test code. |
|
6569
|
1082 |
|
|
1083 @node Application Programming Interface for Oct-Files |
|
|
1084 @subsection Application Programming Interface for Oct-Files |
|
|
1085 |
|
|
1086 WRITE ME, using Coda section 1.3 as a starting point. |
|
|
1087 |
|
|
1088 @node Mex-Files |
|
|
1089 @section Mex-Files |
|
|
1090 @cindex mex-files |
|
|
1091 @cindex mex |
|
|
1092 |
|
|
1093 Octave includes an interface to allow legacy mex-files to be compiled |
|
6571
|
1094 and used with Octave. This interface can also be used to share code |
|
|
1095 between Octave and non Octave users. However, as mex-files expose the |
|
6569
|
1096 intern API of a product alternative to Octave, and the internal |
|
|
1097 structure of Octave is different to this product, a mex-file can never |
|
6571
|
1098 have the same performance in Octave as the equivalent oct-file. In |
|
6569
|
1099 particular to support the manner in which mex-files access the variables |
|
|
1100 passed to mex functions, there are a significant number of additional |
|
6571
|
1101 copies of memory when calling or returning from a mex function. For this |
|
6569
|
1102 reason, new code should be written using the oct-file interface |
|
|
1103 discussed above if possible. |
|
|
1104 |
|
|
1105 @menu |
|
6572
|
1106 * Getting Started with Mex-Files:: |
|
|
1107 * Structures with Mex-Files:: |
|
|
1108 * Sparse Matrices with Mex-Files:: |
|
|
1109 * Calling External Functions in Mex-Files:: |
|
6569
|
1110 @end menu |
|
|
1111 |
|
|
1112 @node Getting Started with Mex-Files |
|
|
1113 @subsection Getting Started with Mex-Files |
|
|
1114 |
|
|
1115 The basic command to build a mex-file is either @code{mkoctfile --mex} or |
|
6571
|
1116 @code{mex}. The first can either be used from within Octave or from the |
|
|
1117 commandline. However, to avoid issues with the installation of other |
|
6569
|
1118 products, the use of the command @code{mex} is limited to within Octave. |
|
|
1119 |
|
|
1120 @DOCSTRING(mex) |
|
|
1121 |
|
|
1122 @DOCSTRING(mexext) |
|
|
1123 |
|
|
1124 One important difference between the use of mex with other products and |
|
|
1125 with Octave is that the header file "matrix.h" is implicitly included |
|
6571
|
1126 through the inclusion of "mex.h". This is to avoid a conflict with the |
|
6569
|
1127 Octave file "Matrix.h" with operating systems and compilers that don't |
|
|
1128 distinguish between filenames in upper and lower case |
|
|
1129 |
|
|
1130 Consider the short example |
|
|
1131 |
|
|
1132 @example |
|
|
1133 @group |
|
6577
|
1134 @verbatiminclude @value{top_srcdir}/examples/firstmexdemo.c |
|
6569
|
1135 @end group |
|
|
1136 @end example |
|
|
1137 |
|
|
1138 This simple example demonstrates the basics of writing a mex-file. |
|
|
1139 |
|
|
1140 WRITE ME |
|
|
1141 |
|
6572
|
1142 @node Structures with Mex-Files |
|
|
1143 @subsection Structures with Mex-Files |
|
6569
|
1144 |
|
|
1145 WRITE ME |
|
|
1146 |
|
|
1147 @node Sparse Matrices with Mex-Files |
|
|
1148 @subsection Sparse Matrices with Mex-Files |
|
|
1149 |
|
|
1150 WRITE ME |
|
|
1151 |
|
|
1152 @node Calling External Functions in Mex-Files |
|
|
1153 @subsection Calling External Functions in Mex-Files |
|
|
1154 |
|
|
1155 WRITE ME |
|
|
1156 |
|
|
1157 @node Standalone Programs |
|
|
1158 @section Standalone Programs |
|
|
1159 |
|
|
1160 The libraries Octave itself uses, can be utilized in standalone |
|
6571
|
1161 applications. These applications then have access, for example, to the |
|
6569
|
1162 array and matrix classes as well as to all the Octave algorithms. The |
|
|
1163 following C++ program, uses class Matrix from liboctave.a or |
|
|
1164 liboctave.so. |
|
|
1165 |
|
|
1166 @example |
|
|
1167 @group |
|
|
1168 #include <iostream> |
|
|
1169 #include <octave/oct.h> |
|
|
1170 int |
|
|
1171 main (void) |
|
|
1172 @{ |
|
|
1173 std::cout << "Hello Octave world!\n"; |
|
6572
|
1174 int n = 2; |
|
|
1175 Matrix a_matrix = Matrix (n, n); |
|
|
1176 for (octave_idx_type i = 0; i < n; i++) |
|
6569
|
1177 @{ |
|
6572
|
1178 for (octave_idx_type j = 0; j < n; j++) |
|
6569
|
1179 @{ |
|
6572
|
1180 a_matrix(row,column) = (i+1)*10 + (j+1); |
|
6569
|
1181 @} |
|
|
1182 @} |
|
|
1183 std::cout << a_matrix; |
|
|
1184 return 0; |
|
|
1185 @} |
|
|
1186 @end group |
|
|
1187 @end example |
|
|
1188 |
|
|
1189 mkoctfile can then be used to build a standalone application with a |
|
|
1190 command like |
|
|
1191 |
|
|
1192 @example |
|
|
1193 @group |
|
|
1194 $ mkoctfile --link-stand-alone hello.cc -o hello |
|
|
1195 $ ./hello |
|
|
1196 Hello Octave world! |
|
|
1197 11 12 |
|
|
1198 21 22 |
|
|
1199 $ |
|
|
1200 @end group |
|
|
1201 @end example |
|
|
1202 |
|
|
1203 Note that the application @code{hello} will be dynamically linked |
|
|
1204 against the octave libraries and any octave support libraries. |
