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.
Filed under: 
ODAY’S show is the first show of this month. Rather than cover a lot of news we picked topics which we selected in advance all of for us to cover without preparation. This show is shorter than usual because it was recorded around midnight and OpenBytes will publish the show notes very soon.
Today’s show ends with Tom Smith’s usual track. We hope you will join us for future shows and consider subscribing to the show via the RSS feed. You can also visit our archives for past shows. If you have an Identi.ca account, consider subscribing to TechBytes in order to keep up to date. 
