By its own description, GNU
Octave is "a high-level language, primarily intended for numerical computations. It provides a convenient command
line interface for solving linear and nonlinear problems numerically,
and for performing other numerical experiments using a language that
is mostly compatible with Matlab. It may also be used as a
batch-oriented language."
So Octave is software for numeric computations that aims for Matlab
compatibility. This aim, in fact, may be more recent, as previous
versions of Octave implemented a different user interface than Matlab,
and this wasn't seen as a drawback, but the newer
versions post the 3.0.x release, explicitly add much functionality to
increase compatibility with Matlab. In the words of the developers
as seen in the mailing lists, Octave doesn't purport to be a
bug-for-bug copy of
Matlab, so things sometimes differ intentionally, but the grand
eventual goal might be to make all the existing and vast codebase
written for Matlab to work in Octave, today still not completely
attained.
Like most other free projects, Octave manages its releases via a
version control system (currently, Mercurial) and makes regular
snapshot releases whenever they seem ready. The lead developer is John
W. Eaton, better known by his net name of jwe. It seems these free
software mad overlords always go by their three initials. At any rate,
jwe first wrote Octave as companion software for an undergraduate
textbook on chemical reactor design written by James B. Rawlings of
the University of Wisconsin-Madison and John G. Ekerdt of the
Universtiy of Texas, and then released it to the community. I don't
think Matlab compatibility was an initial design goal, but rather
something that came along later. jwe has also produced other pieces of
code, such as the original man-db package that many GNU/Linux
distributions use for reading the manpages.
Octave is free software, that is, it is distributed with a license to
copy, modify, and redistribute it. Its development is
quite open, and as of this writing, ever more active. Development, as
is usual for this kind of projects, is coordinated through mailing
lists and source repositories. It used to be that jwe had the final
authority on what code could be committed to the sources, but recently
many other developers have been granted write access to the source
tree, fostering a more bazaar-like
collaboration model. This coincidentially also happened when moving
from an antiquated CVS version control system to Mercurial. There
is a team of packagers for Debian (hence derivatives like Ubuntu),
plus others involved with compiling binaries for Windows and MacOS
X. Although the main source tree has traditionally been very
conservative about the quality of the code it accepts (only jwe had
write access), this has inevitably reversed a little now that so many
others have been granted write access.
To complement the development of the main source tree and vaguely
mimicking Matlab's toolboxes, Octave users have found it useful to
create a repository of Octave functions inspired by Matlab
functionality and keep it in a Sourceforge repository. These
so-called Octave-forge functions give Octave almost all of the core
functionality of Matlab. The 'forge is also much more open about
accepting code, and it's possible one may run into lower-quality code
than what exists in the main Octave branch. I have personally run into
few problems with Octave-forge packages, and often install quite a few
of them in most installations of Octave I've done.
The interface
Octave primarily runs as an interpreter awaiting commands or scripts
from the user. It's mostly a command-line tool written with GNU
readline, although various efforts of creating a "GUI" (as if it
needed one or as if Matlab had one) are in effect. As of this writing
(looks like I'll be saying this a lot) there's an effort to make a GUI
for Octave using the Qt library from Trolltech, as well as a
competing effort to use Gtk+, along with many other aborted attempts
to do so. I personally run it in an xterm (Gnome's terminal, to be
precise), edit my scripts with GNU Emacs, and alt-tab between the
two applications to see how my code is doing after I write it. It is
also possible to embed an Octave session directly in Emacs. For quick
things I just type code directly into the interpreter. It's fast,
easy, and gotten to the point that if I need to compute simple
arithmetic operations like finding the area of a circle, I just
quickly fire up Octave, type in my calculations, and get succinct
results.
The syntax is near identical to Matlab's syntax, although it adds
enhancements of its own (which can be ignored and Matlab-compatible
code can easily be written if desired). The primary data type is the
matrix, although n-dimensional arrays and other structures
also exist; strings are another important data type. The function base
is also largely compatible with Matlab, and any Matlab user will feel
right at home if she sticks to basic functionality. Octave in
particular has nothing like Simulink, which I've never personally
used but I understand is another reason for the foothold Matlab
has as a de-facto standard in the numeric community. I have also not
heard of any attempts at making anything like Simulink for Octave,
although a competing free software packages named Scilab does
attempt to mimic Simulink's behaviour with its Scicos package.
I may be giving the wrong impression here by saying that one needs to
stick to minimal functionality in order to maintain compatibility with
Matlab. By basic functionality I mean things such as Runge-Kutta
solvers for ordinary differential equations, digital signal
processing, sparse matrix computations and spline interpolations.
That is, Octave's codebase is quite usable for any kind of numerical
analysis. Some of the complaints against Octave I read in the users'
help mailing list are about someone coming from Matlab and requiring a
very Matlab-specific function to work in a certain way in Octave.
Getting sophisticated code from Matlab working in Octave can be a
challenge, but if one writes Octave code consistently, it's easy to
accomplish what any kind of numericist would expect from a numerical
software package.
The Octave coding language is something I think of as an enhanced
Matlab language. The Matlab language has some decidedly weird
constructs, no doubt inspired by its Fortran roots, but Octave is
not afraid to add more C-like constructs that are more familiar to
the modern numericist. As an example, for loops in Matlab
have to be ended with an end keyword, which is heavily
overloaded to end any code block, and also to signal the last element
of a matrix when indexing. Octave introduces the endfor,
endif, ..., endfunction keywords that can make code
a little more readable. Matlab also does not have the C-like
arithmetic operator +=, *=, nor even the useful increment operator,
++, but Octave does. Another useful coding feature of Octave is the
unwind-protect mechanism, this time snatched from Lisp, which is
heavily used for the coding of the "standard" library Octave-forge
functions. Octave can also treat the output of functions as operators
like any other object and index them directly. Therefore, something
like "sin(x)(2:end)" or "(a+b)(1:10)" are perfectly valid in Octave,
but not in Matlab.
It is noteworthy that Octave does allow and encourages the same
vectorisation tricks that Matlab uses and encourages. That is,
for-loops are undesirable, and Octave has mechanisms that will often
allow the clever numericist to avoid using them. This results in more
sleek code, usually also shorter statements, and, most importantly,
code that runs faster. It is also often a fun puzzle to find ways to
vectorise certain kinds of code. Unfortunately, Octave does not have
just-in time compiling like Matlab now does (Matlab too didn't have
it once), so it suffers more severely from unvectorised code than
Matlab currently does. The current fix is to become a better vector
coder; it has been determined by the developers that implementing
just-in time compiling for Octave is difficult. It is not a current
priority, although it may be a nice feature of Octave in the future,
and there have been vague suggestions of working towards this goal.
Graphical capabilities and libraries
Octave by default uses the curiously-named gnuplot (it has nothing
to do with the GNU project) for plotting, but there is a myriad of
other possible plotting engines. The gnuplot plotting engine works
well enough for 2d graphics and simple 3d plots, but complex 3d
plotting or animations are beyond gnuplot's reach. There are other
interfaces like PlPlot and Jhandles. Additionally, an experimental
OpenGL backend formerly known as octplot has been integrated into
the main source tree, and it may completely replace gnuplot in a near
future. Octave's graphics have been slowly improving over time,
although they're still strongly tied to gnuplot and alternatives
aren't always obvious to install or use. Some users have nevertheless reported one advantage of gnuplot that also applies to some of the other graphing alternatives in that running it as a separate process from Octave allows better memory management.
Matlab has a very useful ability to use its numeric libraries
standalone without the interpreter, and compile them in another
language, often C or C++. These so-called MEX files, Matlab
Executables, have their counterpart in the liboctave and .oct files in
Octave. Octave is written in C++, and its libraries, many of which
are also written in Fortran, especially for the core numeric libraries
or the routines borrowed from LAPACK and BLAS, can be called from
other C/C++ programs for executables.
And that's Free as in Freedom.
What I mean to say is that Octave is covered by the GPL version 3,
that is, you can redistribute it and/or modify it under the terms of
the GNU General Public License as published by the Free Software
Foundation; version 2 dated June, 2007, or at your option, any later
version.
This has a number of benefits that in my opinion outweigh all of the
fixable discomforts I've mentioned above with Octave. For one, it's
easy to obtain a gratis copy of Octave, and copy it as many times as
one wishes. This enables a
cluster of Octave processes running on different machines
communicating with pipes and sockets. I have read a number of stories
of this kind in the mailing list.
More importantly, unlike Matlab, absolutely all of the source
for Octave is visible. Matlab's source is also largely visible, but
they also keep some very important pieces of code hidden, and this is
utterly unacceptable behaviour for mathematics and science. What kind
of scientist (and in a very real sense, this is what Octave and Matlab
are for: scientific computation) refuses to reveal the procedure of an
experiment or uses the results of someone else's procedure without
even knowing how those results were obtained? Yet, this is the current
status quo, for Matlab is a de-facto standard in the numeric
community, and students of mathematics, computer science, and
engineering worldwide are being taught to use Matlab for scientific
computation, not to mention the existing Matlab codebase, yet it's all
based on a fundamentally flawed premise: that hiding implementation
details is acceptable in the academic community. Or worse, that it's
acceptable to use current copyright law to prevent mathematicians,
engineers, and scientists from freely sharing their work by giving
them crippled software (everyone, even its users, hates Matlab's
copy-prevention mechanism and license manager).
There is no technical limitation for why quality software for numeric
computation should be proprietary. Indeed, R is a free software
de-facto standard within the statistical community, much more widely
used than its proprietary counterparts, and it's a well-polished piece
of free software. If Matlab has more features than Octave, it is
simply a curiousity of historical inertia: Matlab was first, the
creator of Matlab decided to make it proprietary while the creator of
Octave made it free, and more people collaborated with Matlab than
with Octave. Indeed, many Matlab users, despite their complaining
about the price of the software (they probably just copy it anyways
and find ways to circumvent the copy protection mechanism, for this is
exactly what the Mathworks wants), create
this large Matlab codebase that has us gotten us into this fine mess
to begin with. The Matlab users almost always create their software in
a free manner, showing source and allowing redistribution, but it's a
pity that all this effort was expended on a proprietary platform. If
it had been done for Octave instead, there is no reason why Octave
couldn't have been for the numeric community what R is for the
statistical community (and yes, we are different sorts of people).
The Octave community and mailing list is lively and active. Problems
of almost any nature are quickly addressed. Many people are writing
code for Octave at very different levels, from the 'forge function
writers, to the core Octave developers, and the coders working on
graphical engines.
Quality
Octave-based books by renowned experts are starting to appear for
teaching students the fundamentals of numerical analysis.
Octave has the great potential to be a Matlab killer
(Matzilla?), but isn't one yet. Octave, however, is already
much more than that: it is a full-featured scientific computing
environment. I have been using it exclusively for close to two years
now, after I finally purged my computer of the illegal copy of Matlab
I had, and the only reason I look back is in hopes of bringing with me others
who are still back there.
Website: http://www.octave.org