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.

GNU Octave is free software

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.