bugGNU Octave - Bugs: bug #34906, Compatibility difference with...


bug #34906: Compatibility difference with ticklabels, linestyleorder

Submitted by:  Ben Abbott <bpabbott>
Submitted on:  Sat Nov 26 17:50:30 2011  
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Matlab Compatibility
Status: FixedAssigned to: None
Originator Name: Ben AbbottOpen/Closed: Closed
Release: devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

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


(Jump to the original submission Jump to the original submission)

Fri Sep 6 00:07:12 2013, comment #16:

I checked in one more change to deal with converting linestyleorder into a row vector char matrix (http://hg.savannah.gnu.org/hgweb/octave/rev/50b2863d10a6). Closing report.

Rik <rik5>
Project Administrator
Wed Jun 26 23:13:08 2013, comment #15:

I checked in a changeset that fixes repetition and string trimming (http://hg.savannah.gnu.org/hgweb/octave/rev/359ac80ecb30). The only thing I trim is spaces. Matlab may be trimming other whitespace as well such as tab (\t) or newline (\n) or return (\r). I doubt they trim the newline because then it would be difficult to have multi-line labels. Someone can check what characters Matlab is trimming or we can just go with what we have here.

Ben, is the general behavior that when given a cell array vector that the return is always a column vector? Is this true for numeric cell arrays as well as string cell arrays? If so then that reshaping should be done more generally than just in the convert_ticklabel_string routine.

Similarly, do all arguments that accept strings split on the delimiter '|'? What about something like title()? Can you get a multi-line title with

I'm wondering if we only need to write one more routine to deal with linestyleorder or whether bigger changes have to be made.

Rik <rik5>
Project Administrator
Wed Jun 26 22:06:16 2013, comment #14:

I pushed another changeset which deals with the a trailing delimeter in the ticklabel string ("abc|") (http://hg.savannah.gnu.org/hgweb/octave/rev/563f8f0a7e29). It also makes use of an option to the charMatrix constructor to get rid of a for loop.

The repetition operation might take a bit more time. I only just found out where the relevant code is gl_render.cc:render_ticktexts ().

Rik <rik5>
Project Administrator
Tue Jun 25 17:21:46 2013, comment #13:

According to Matlab Online documentation, the specified labels are reused until all tick marks are set. (Is it OK to post links next time or will this violate Mathworks terms of use?)

For the first example all ticklabels will be named 'a'.
In the seconds case the labels are 'a', nothing, 'a', nothing and so on. (See picture)
The third example is basically the same as the second: 'a', 'b', 'a', 'b', ...

Attached two pictures (made by markuman(IRC/#octave)).

(file #28412, file #28413)

Stefan Mahr <dac922>
Tue Jun 25 16:40:06 2013, comment #12:

I've never had access to Matlab so I don't always know what I'm aiming for.

What is the desired behavior for the following?

Is it always supposed to repeat the base element until it has enough tick values?

Rik <rik5>
Project Administrator
Tue Jun 25 09:21:52 2013, comment #11:


There's a reason why I did not use getline. It breaks this code:

> The behavior of xticklabels is getting much better, but there is
> still a problem with alignment of the labels.
> If you look at the plot you will notice that the labels for
> 1,2,3,4 are offset to the left from their tickmark.

This problem doesn't appear with gnuplot, only with fltk.

> It seems like a possible solution would be to change to a
> null-delimited character array such that the first label was
> '1\0\0\0\0'.

AFAIK, this would break matlab compatibility when doing
get (gca (), "xticklabel");

IMHO, the font renderer has to trim the strings. Also, there's another problem with fltk frontend:

The xticklabel only appears at the first position and is not repeated.

Stefan Mahr <dac922>
Mon Jun 24 23:38:06 2013, comment #10:

I checked in a changeset which makes Octave always return column vectors of cell strings for ticklabels (http://hg.savannah.gnu.org/hgweb/octave/rev/2ce1ddead134).

Rik <rik5>
Project Administrator
Mon Jun 24 22:18:45 2013, comment #9:

The behavior of xticklabels is getting much better, but there is still a problem with alignment of the labels.

Sample code:

If you look at the plot you will notice that the labels for 1,2,3,4 are offset to the left from their tickmark. The problem is that we are splitting and converting the string to a character matrix where the fill character is a space. Thus, the label '1' is really '1 ' to match the width of '1.500'.

When you pass a cell array of values this isn't a problem.

It seems like a possible solution would be to change to a null-delimited character array such that the first label was '1\0\0\0\0'. Then in the font renderer code we could put in something to look only for a C string so that this would become '1' rather than a 5 character sequence. Just an idea.

Rik <rik5>
Project Administrator
Mon Jun 24 22:10:27 2013, comment #8:

I modified the code to use standard Octave coding conventions (http://hg.savannah.gnu.org/hgweb/octave/rev/969233a27bce). We like to distinguish between indexing and function calls by using a space between the function name and the opening parenthesis.

These rules are maintained in the C++ code as well. I also added missing semicolons to the end of lines for %!test blocks.

Rik <rik5>
Project Administrator
Tue Jun 11 15:03:02 2013, comment #7:

Yes, both "make check" and "rundemos plot" show no problems related to xticklabel.

Stefan Mahr <dac922>
Tue Jun 11 13:40:52 2013, comment #6:

I ran "make check" and "rundemos plot". I didn't see any regressions, but will wait for a confirmation. I'm attached a Stephan's changeset with some tests added.

(file #28293)

Ben Abbott <bpabbott>
Project Member
Tue Jun 11 13:14:19 2013, comment #5:


Have you verified there are no problems with "rundemos plot", and "make check"?

Ben Abbott <bpabbott>
Project Member
Tue Jun 11 11:46:07 2013, comment #4:

With new attached patch the behaviour is now similar to matlab.

(file #28290)

Stefan Mahr <dac922>
Thu Jun 6 18:51:18 2013, comment #3:

attached patch partially solves the issue, but only for xticklabel at the moment.

i do not like to use feval for calling num2str and strsplit, maybe someone has a better solution.

if using '|' as delimiter when setting xticklabel, 'get' returns a cell array instead of a char array, so it's not fully compatible to matlab yet.

(file #28273)

Wed Mar 13 23:34:43 2013, comment #2:

I'm not too concerned with the char vs. cellstr. But Octave has zero support for a string that uses '|' as a delimiter. Instead it treats it as a single label which gets put at the first xtick position.

Rik <rik5>
Project Administrator
Sun Nov 27 00:53:17 2011, comment #1:

I took a look at how linestyleorder behaves under matlab.

ML's behavior looks consistent to me.

Ben Abbott <bpabbott>
Project Member
Sat Nov 26 17:50:30 2011, original submission:

There is a subtle incompatibility in how ML and Octave handle ticklabels. Below I use xticklabels to demonstrate, but the problem exists for x, y, z ticklabels.

ML uses the 3rd variant for the default xticklabel values., and Octave uses the 4th (1x6 cellstr)

Each set() statement works in both Octave and ML. However, the resulting values returned by the get() are different.

Octave returns ...

And ML ...

I see three differences.

(1) The default xticklabel values for ML are char, and are cell (cellstr) for Octave.

(2) ML converts the xticklabel with class double or char with "|" used as a delimiter to a char array. Octave returns the same class and format as was passed to set().

(3) ML converts a cellstr column vector (1xN) to a row vector (Nx1).

Ben Abbott <bpabbott>
Project Member


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

Attach File(s):

Attached Files
file #28412:  matlab_xticklabel.png added by dac922 (10kB - image/png)
file #28293:  changeset.patch added by bpabbott (5kB - application/octet-stream - Stephan's changeset with some tests added.)
file #28290:  ticklabel.patch added by dac922 (4kB - text/x-patch)
file #28273:  ticklabel.patch added by None (2kB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by dac922 (Updated the item)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by bpabbott (Submitted the item)

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

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 12 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri Sep 6 00:07:12 2013rik5StatusIn Progress=>Fixed
    Wed Jun 26 23:13:08 2013rik5StatusNone=>In Progress
    Tue Jun 25 17:21:46 2013dac922Attached File-=>Added matlab_xticklabel.png, #28412
      Attached File-=>Added matlab_xticklabel_a_empty.png, #28413
    Tue Jun 11 13:40:52 2013bpabbottAttached File-=>Added changeset.patch, #28293
    Tue Jun 11 11:46:51 2013dac922Carbon-CopyRemoved -unavailable-=>-
    Tue Jun 11 11:46:07 2013dac922Attached File-=>Added ticklabel.patch, #28290
      Carbon-Copy-=>Added -unavailable-
    Thu Jun 6 18:51:18 2013NoneAttached File-=>Added ticklabel.patch, #28273
    Sun Nov 27 00:53:17 2011bpabbottSummaryCompatibility difference with ticklabels=>Compatibility difference with ticklabels, linestyleorder
    Sat Nov 26 17:50:49 2011bpabbottSummaryCompatibility difference =>Compatibility difference with ticklabels

    Back to the top

    Powered by Savane 3.1-cleanup