FAQ: Difference between revisions

This is a list of frequently asked questions (FAQ) for GNU Octave users.

=General=

==What is Octave-Forge?==

==Who uses Octave?==

The GNU Project was launched in 1984 to develop a complete Unix-like operating system which is free software: the GNU system.

The Free Software Foundation (FSF) is the principal organizational sponsor of the GNU Project.

Octave is also free software; you can redistribute it and/or modify it under the terms of the GNU General Public License, version 3, as published by the Free Software Foundation, or at your option any later version.

== How can I cite Octave? ==

==How can I get involved in Octave development?==

=Licensing issues=

* First official release of the GUI.

* Release of official windows binaries.

* OpenGL graphics with Qt widgets.

* Several functions for reading, writing, and recording of audio.

* http://www.octave.org/download.html

Since Octave is distributed under the terms of the GPL, you can get Octave from a friend who has a copy, or from the Octave website.

* http://www.octave.org/download.html

==How do I get a copy of Octave for (some other platform)?==

Yes, but development is done primarily with GCC, so you may hit some incompatibilities. Octave is intended to be portable to any standard conforming compiler. If you have difficulties that you think are bugs, please report them to the http://bugs.octave.org bug tracker, or ask for help on the [mailto:help@octave.org mailing list].

=Coding=

As a natural extension of this, functions can also be defined in script files (m-files whose first non-comment line isn't {{Codeline|function out = foo (...)}})

===Comments with #===

     x += 1;

   until (x == 10)

==How does Octave solve linear systems?==

would produce value 9999999999999990000, which is close to the maximum possible value for the uint64 type, but can't be at the moment input directly, doing uint64(9999999999999990000), due to the mentioned error of rounding.

=Common problems=

Floating point arithmetic is an approximation '''in binary''' to arithmetic on real or complex numbers. Just like you cannot represent 1/3 exactly in decimal arithmetic (0.333333 is only a rough approximation to 1/3), you cannot represent some fractions like <math>1/10</math> exactly in base 2. In binary, the representation to one tenth is <math>0.0\overline{0011}_b</math> where the bar indicates that it repeats infinitely (like how <math>1/6 = 0.1\overline{6}_d</math> in decimal). Because this infinite repetition cannot be represented exactly with a finite number of digits, rounding errors occur for values that appear to be exact in decimal but are in fact approximations in binary, such as for example how 0.3 - 0.2 - 0.1 is not equal to zero.

Like death and taxes, rounding errors are a fact of life. You cannot avoid them. You can only move a rounding error from one part of a computation to another, or you can use more precision and delay the rounding error. One way to delay the rounding error is to use arbitrary precision arithmetic, which is inevitably slower as it has to be implemented in software instead of hardware. You may use the vpa function from the symbolic package for this purpose.

== I have installed a package but still get a "foo undefined" error ==

== Missing lines when printing under Windows with OpenGL toolkit and Intel integrated GPU ==

See also https://www.opengl.org/wiki/FAQ#Why_is_my_GL_version_only_1.4_or_lower.3F

People often ask

You should also look at the pages http://octave.sourceforge.net/packages.php and http://octave.sourceforge.net/docs.html that have a function reference that is up to date. You can use this function reference to see the number of octave functions that are available and their Matlab compatibility.

Octave has limited support for nested functions. That is

The authors of Octave consider the nested function scoping rules of Matlab to be more problems than they are worth as they introduce difficult to find bugs as inadvertently modifying a variable in a nested function that is also used in the parent is particularly easy for those not attentive to detail.

There are a few core Matlab syntaxes that are not accepted by Octave, these being

* Matlab classdef object oriented programming is not yet supported, though work is underway in a branch of the development tree.

Matlab includes a "Just-In-Time" compiler. This compiler allows the acceleration of for-loops in Matlab to almost native performance with certain restrictions. The JIT must know the return type of all functions called in the loops and so you can't include user functions in the loop of JIT optimized loops. Octave doesn't have a JIT and so to some might seem slower than Matlab. For this reason you must vectorize your code as much as possible. The MathWorks themselves have a good document discussing vectorization at http://www.mathworks.com/support/tech-notes/1100/1109.html.

On a related point, there is no Octave compiler, and so you can't convert your Octave code into a binary for additional speed or distribution. There have been several aborted attempts at creating an Octave compiler. Should the JIT compiler above ever be implemented, an Octave compiler should be more feasible.

There are no Matlab compatible GUI functions yet.  This might be an issue if you intend to exchange Octave code with Matlab users. There are a number of bindings from Octave to {{Forge|tcl-octave|Tcl/Tk}}, [http://octaviz.sourceforge.net/index.php? VTK] and {{Forge|zenity}} for example, that can be used for a GUI, but these are not Matlab compatible. Work on a Matlab compatible GUI is in an alpha stage in the QtHandles project, which may form part of a future release of Octave.

Octave itself includes no Simulink support. Typically the simulink models lag research and are less flexible, so shouldn't really be used in a research environment. However, some Matlab users that try to use Octave complain about this lack.

Octave includes an API to the Matlab MEX interface. However, as MEX is an API to the internals of Matlab and the internals of Octave differ from Matlab, there is necessarily a manipulation of the data to convert from a MEX interface to the Octave equivalent. This is notable for all complex matrices, where Matlab stores complex arrays as real and imaginary parts, whereas Octave respects the C99/C++ standards of co-locating the real/imag parts in memory. Also due to the way Matlab allows access to the arrays passed through a pointer, the MEX interface might require copies of arrays (even non complex ones).

Block comments denoted by {{Codeline|#{}} and {{Codeline|#&#125;}}  markers (or {{Codeline|%{}} and {{Codeline|%&#125;}}) are supported by Octave with some limitations. The major limitation is that block comments are not supported within [] or {}.

There are some differences in the mat v5 file format accepted by Octave. Matlab recently introduced the "-V7.3" save option which is an HDF5 format which is particularly useful for 64-bit platforms where the standard Matlab format can not correctly save variables. Octave accepts HDF5 files, but is not yet compatible with the "-v7.3" versions produced by Matlab.

Finally, some multi-byte Unicode characters aren't yet treated in mat-files.

Thanks to Daniel Kraft's 2011 Google Summer of Code project, Octave has a profiler since version 3.6.0. However, at the moment it only produces text output and has its own makeshift interface for hierarchical profiling.

Octave is a community project and so the toolboxes that exist are donated by those interested in them through [[Octave Forge]]. These might be lacking in certain functionality relative to the Matlab toolboxes, and might not exactly duplicate the Matlab functionality or interface.

The {{Codeline|&}} and {{Codeline|&#124;}} operators in Matlab short-circuit when included in a condition (e.g. an {{Codeline|if}} or {{Codeline|while}} statement) and not otherwise. In Octave only the {{Codeline|&&}} and {{Codeline|&#124;&#124;}} short circuit. Note that this means that

because, despite the name, the {{Codeline|all}} is really returning true if none of the elements of the matrix are zero, and since there are no elements, well, none of them are zero. This is an example of [http://en.wikipedia.org/wiki/Vacuous_truth vacuous truth]. But, somewhere along the line, someone decided that {{Codeline|if ([])}} should be false. Mathworks probably thought it just looks wrong to have {{Codeline|[]}} be true in this context even if you can use logical gymnastics to convince yourself that "all" the elements of an empty matrix are nonzero. Octave however duplicates this behavior for {{Codeline|if}} statements containing empty matrices.

Matlab's solvers as used by the operators mldivide (\) and mrdivide (/), use a different approach than Octave's in the case of singular, under-, or over-determined matrices. In the case of a singular matrix, Matlab returns the result given by the LU decomposition, even though the underlying solver has flagged the result as erroneous. Octave has made the choice of falling back to a minimum norm solution of matrices that have been flagged as singular which arguably is a better result for these cases.

Since the mldivide (\) and mrdivide (/) operators are often part of a more complex expression, where there is no room to react to warnings or flags, it should prefer intelligence (robustness) to speed, and so the Octave developers are firmly of the opinion that Octave's approach for singular, under- and over-determined matrices is a better choice than Matlab's.

The extensions in Octave over MATLAB syntax are very useful, but might cause issues when sharing with Matlab users. A list of the major extensions that should be avoided to be compatible with Matlab are:

made it free software so we could reuse large chunks of it which were

incorporated in what is now the Octave GUI.