octave: External Code Interface
Appendix A External Code Interface
**********************************
"The sum of human wisdom is not contained in any one language"
— Ezra Pound
Octave is a fantastic language for solving many problems in science
and engineering. However, it is not the only computer language and
there are times when you may want to use code written in other
languages. Good reasons for doing so include: 1) not re-inventing the
wheel; existing function libraries which have been thoroughly tested and
debugged or large scale simulation codebases are a good example, 2)
accessing unique capabilities of a different language; for example the
well-known regular expression functions of Perl (but don’t do that
because ‘regexp’ already exists in Octave).
Performance should generally *not* be a reason for using compiled
extensions. Although compiled extensions can run faster, particularly
if they replace a loop in Octave code, this is almost never the best
path to take. First, there are many techniques to speed up Octave
performance while remaining within the language. Second, Octave is a
high-level language that makes it easy to perform common mathematical
tasks. Giving that up means shifting the focus from solving the real
problem to solving a computer programming problem. It means returning
to low-level constructs such as pointers, memory management,
mathematical overflow/underflow, etc. Because of the low level nature,
and the fact that the compiled code is executed outside of Octave, there
is the very real possibility of crashing the interpreter and losing
work.
Before going further, you should first determine if you really need
to bother writing code outside of Octave.
• Can I get the same functionality using the Octave scripting
language alone?
Even when a function already exists outside the language, it may be
better to simply reproduce the behavior in an m-file rather than
attempt to interface to the outside code.
• Is the code thoroughly optimized for Octave?
If performance is an issue you should always start with the
in-language techniques for getting better performance. Chief among
Execution::) which not only makes the code concise and more
understandable but improves performance (10X-100X). If loops must
be used, make sure that the allocation of space for variables takes
place outside the loops using an assignment to a matrix of the
right size, or zeros.
• Does the code make as much use as possible of existing built-in
library routines?
These routines are highly optimized and many do not carry the
overhead of being interpreted.
• Does writing a dynamically linked function represent a useful
investment of your time, relative to staying in Octave?
It will take time to learn Octave’s interface for external code and
there will inevitably be issues with tools such as compilers.
With that said, Octave offers a versatile interface for including
chunks of compiled code as dynamically linked extensions. These
dynamically linked functions can be called from the interpreter in the
same manner as any ordinary function. The interface is bi-directional
and external code can call Octave functions (like ‘plot’) which
otherwise might be very difficult to develop.
The interface is centered around supporting the languages C++, C, and
Fortran. Octave itself is written in C++ and can call external C++/C
code through its native oct-file interface. The C language is also
supported through the mex-file interface for compatibility with MATLAB.
Fortran code is easiest to reach through the oct-file interface.
Because many other languages provide C or C++ APIs it is relatively
simple to build bridges between Octave and other languages. This is
also a way to bridge to hardware resources which often have device
drivers written in C.
Menu
Info Catalog
octave: Packages
octave: Top
octave: Test and Demo Functions