bugGNU Octave - Bugs: bug #33533, strvcat Matlab compatibility issue


bug #33533: strvcat Matlab compatibility issue

Submitted by:  Arnaud Delorme <arnodelorme>
Submitted on:  Sat 11 Jun 2011 03:37:16 PM UTC  
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  3.4.0 Operating System:  Any

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Fri 29 Jul 2011 07:36:06 AM UTC, comment #12:

After some consideration, I have decided to undo my previous cset.

Rik is right. We like to check arguments a little more in Octave. Moreover, not only are you relying on undocumented behaviour of strvcat, but the Mathworks themselves have already deprecated strvcat in favour of char and will soon remove it from Matlab, precisely because it doesn't check its arguments carefully enough. You will soon have to change your code even if you want to keep using Matlab.

If we keep strvcat in Octave, at least we should keep a version that doesn't have the undesirable behaviour for which the Mathworks is deprecating it.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 28 Jul 2011 05:27:46 AM UTC, comment #11:

I agree about the "license managers and artificial black boxes". Nevertheless, I still use Matlab 99% of the time because Octave graphical capabilities (at least from what I have seen) do not come close to Matlab (although Matlab is actually only relying on Java and the graphics are actually pretty poor). I think it is too bad that Octave has tried to stick with GNUPLOT which a tool from the 80s. I have seen other preliminary solutions under Octave but they are not mature. Java would be the way to go.

Arnaud Delorme <arnodelorme>
Thu 28 Jul 2011 05:11:25 AM UTC, comment #10:

Popularity has never been our ultimate goal. I feel like we're building a giant nicotine patch. I see our ultimate goal is to make people stop using Matlab because science and scientific computing should not progress with license managers and artificial black boxes. If SciPy or Octave or Scilab works for you better than Matlab, great, at least it's not Matlab. In this case, it probably would have been a lot more work for you to rewrite your code in SciPy or Scilab or something else than to change a few lines to make it work in Octave. I think Octave has mostly succeeded for you.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 28 Jul 2011 04:51:30 AM UTC, comment #9:

Yes you are right. But for Octave to gain more popularity and not be (completely) superseded by Python, you might have to bend some rules of good conduct. The popularity of Octave mainly comes from the fact it is compatible with Matlab. If you do not capitalize on that asset, then Octave might not grow as it should.

Arnaud Delorme <arnodelorme>
Thu 28 Jul 2011 04:39:58 AM UTC, comment #8:

Many things besides that flag would be nice. We don't have the time or energy to implement them all. Enforcing bug-for-bug compatibility with Matlab is a wild goose chase, and we cannot afford it. We've never promised that amount of compatibility with Matlab, and we try to stick to what makes sense and what the Mathworks documents.

In this particular case, you seem to be relying on an undocumented bug of Matlab. Octave has never aimed to be a bug-for-bug copy of Matlab, and if your code happened to work with Matlab, should we ensure it also works here? I pushed the change because I thought it was harmless enough, but Rik is making me have second thoughts. I didn't realise it was an undocumented Matlab bug you wanted us to reproduce in Octave.

What's more important, the work you would have to do in order to make your script not rely on Matlab bugs, or the work we would have to do to chase all of those bugs?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 28 Jul 2011 03:44:51 AM UTC, comment #7:

Without altering the Octave philosophy, it would be nice to have a flag in Octave that enforces more Matlab compatibility so Octave functions can behave as Matlab does (and reproduce Matlab bugs). I think this would be beneficial to a lot of people who do not want to spend time adapting scripts.

For instance, I wrote a whole software under Matlab (more than 50 000 lines of code). I wanted to enforce the Octave compatibility (computation only not graphics) to allow users to perform computation on supercomputers (because Matlab requires one license per node and using it on supercomputers would be too expensive). However I still mostly use Matlab. According to recent polls, the market share between Octave and Matlab is still 1 to 10 I think.


Arnaud Delorme <arnodelorme>
Thu 28 Jul 2011 03:25:24 AM UTC, comment #6:

I'm not certain this is the correct fix. According to the documentation (http://www.mathworks.com/help/techdoc/ref/strvcat.html) strvcat can operate on (strings or char arrays) or (cellstrs).

The example given by the issue reporter

is really an empty cell array and not an emtpy cellstr array. Thus, I would like Octave to error out and tell me that I am feeding it incorrect inputs. Feeding an empty cellstr array to strvcat, by contrast, does not generate an error.

In general, Matlab's philosophy seems to be less stringent in checking its inputs. That's fine, but it is a design choice that Octave hasn't followed in the past. In fact, I try and add input validation to functions whenever I can to avoid Garbage In/Garbage Out. In this case, I don't think it makes sense to have a one-off exception to Octave's coding philosophy.

Also, if we decide to keep the new changeset then, at a minimum, strcat() and char() need to be changed to accept empty cell arrays.

To address the reporter's concern. It is still easy to write portable code by using isempty().

Rik <rik5>
Project Administrator
Wed 27 Jul 2011 11:49:45 PM UTC, comment #5:

I've pushed this change on the default branch:


You will have to build the development branch to see the change or wait for the 3.6 release or whatever major release happens after 3.4.2.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Wed 27 Jul 2011 11:22:03 PM UTC, comment #4:

Yes, this is correct. Returns an error.

Arnaud Delorme <arnodelorme>
Wed 27 Jul 2011 11:04:55 PM UTC, comment #3:

You don't mean "crash", you mean "errors out" or "produces an error". "Crash" sounds a lot more alarming than what happens here.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Wed 27 Jul 2011 10:55:24 PM UTC, comment #2:

In some case, one might want to concatenate all the entry in a cell array whatever size the cell array might be. The code below would crash under Octave but work under Matlab.

a = {};

this crashes under Octave but return '' under Matlab


Arnaud Delorme <arnodelorme>
Wed 27 Jul 2011 04:47:35 PM UTC, comment #1:

I think it is useful to have strvcat print a usage message when it is called without arguments. Octave will not follow Matlab on this particular point.

Rik <rik5>
Project Administrator
Sat 11 Jun 2011 03:37:16 PM UTC, original submission:

tmp = strvcat; % return '' under Matlab and crashes under Octave

Arnaud Delorme <arnodelorme>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by arnodelorme (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-07-27 jordigh StatusWont Fix => Fixed
        Operating SystemMac OS => Any
    2011-07-27 rik5 StatusNone => Wont Fix
        Open/ClosedOpen => Closed

    Back to the top

    Powered by Savane 3.4