VERY program has areas worth improving. GNU Octave is no exception and I’ve been trying to submit bug reports (via Savannah) only to find that it has just been compromised (therefore temporarily down), so in the mean time, here is the gist of issues that I found so far.

While Octave is proving to be perfectly compatible with all the basic functions in MATLAB it also proves to be ‘compatible’ with MATLAB’s weight problem. Octave’s core is generally light and much faster to start than MATLAB’s, but when it opens child windows (e.g. ImageMagick), then it suffers a limitation due to the maximum number of allowed windows. For some reason, resources appear not to be recovered when images are closed (it may be leaking memory too), so X.org limits are sooner or later reached. This is a bizarre issue that’s hard to reproduce (in Fedora I cannot even open such windows [1, 2, 3]). But anyway, that’s mostly a performance issue. Closing an Octave session also helps as once it’s restarted windows are numbered from 1 upwards once again.

When it comes to vertical listing of files the UNIX way, there is something a little unexpected in Octave’s implementation of it (which may or may not be compatible with other software). The “ls” function, unless it gets invoked with specific options, will pick its data horizontally rather than vertically from standard I/O in the system call. To illustrate this point consider the following:

>>> ls('*.bmp')
MR000192.bmp  MR000200.bmp  MR000208.bmp  MR000216.bmp	MR000224.bmp
MR000193.bmp  MR000201.bmp  MR000209.bmp  MR000217.bmp	MR000225.bmp
MR000194.bmp  MR000202.bmp  MR000210.bmp  MR000218.bmp	MR000226.bmp
MR000195.bmp  MR000203.bmp  MR000211.bmp  MR000219.bmp	MR000227.bmp
MR000196.bmp  MR000204.bmp  MR000212.bmp  MR000220.bmp
MR000197.bmp  MR000205.bmp  MR000213.bmp  MR000221.bmp
MR000198.bmp  MR000206.bmp  MR000214.bmp  MR000222.bmp
MR000199.bmp  MR000207.bmp  MR000215.bmp  MR000223.bmp
>>> a=ls('*.bmp')
a =

MR000192.bmp
MR000200.bmp
MR000208.bmp
MR000216.bmp
MR000224.bmp
MR000193.bmp
MR000201.bmp
MR000209.bmp
MR000217.bmp
MR000225.bmp
MR000194.bmp
MR000202.bmp
MR000210.bmp
MR000218.bmp
MR000226.bmp
MR000195.bmp
MR000203.bmp
MR000211.bmp
MR000219.bmp
MR000227.bmp
MR000196.bmp
MR000204.bmp
MR000212.bmp
MR000220.bmp
MR000197.bmp
MR000205.bmp
MR000213.bmp
MR000221.bmp
MR000198.bmp
MR000206.bmp
MR000214.bmp
MR000222.bmp
MR000199.bmp
MR000207.bmp
MR000215.bmp
MR000223.bmp

The arrangement is supposed to be on a column-by-column basis (the real ordering), but in the case of an assignment the data gets flattened in a way which does not preserve the original file ordering (alpha-numeric in this case).

By all means move from MATLAB to GNU Octave because these issues are not critical and some may be matters of convenience rather than practicality. If anything, this proves that Octave has only minor creases and no major deficiencies. That’s all I could find after heavy usage.

 Add your comment(s) |  Send this to a friend

This entry was posted on Thursday, December 2nd, 2010 at 7:20 am and is filed under Free Software, GNU Octave. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.