bugGNU Octave - Bugs: bug #43559, "hold on" causes...

 
 

bug #43559: "hold on" causes "plot" to use incorrect series colouring

Submitter:  None
Submitted:  Fri 07 Nov 2014 12:11:20 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  A. Tombs Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.8.2
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 10 Jul 2016 11:11:59 PM UTC, comment #17: 

@Helios: Can you report that as a separate bug?  I'm not sure when (if?) we want to change over to the new Matlab color scheme, but there should probably be an issue report on the Savannah just to track it.

Rik <rik5>
Group administrator
Sat 09 Jul 2016 08:46:13 PM UTC, comment #16: 

Hi, by the way, perhaps this should be treated in another issue, because it's not strictly associated to "hold on", but it does have to do with the changes of Matlab plots in 2014:

Should be the default color order be changed too? I mean, instead of the older:

         0         0    1.0000
         0    0.5000         0
    1.0000         0         0
         0    0.7500    0.7500
    0.7500         0    0.7500
    0.7500    0.7500         0
    0.2500    0.2500    0.2500


Use the newer:

         0    0.4470    0.7410
    0.8500    0.3250    0.0980
    0.9290    0.6940    0.1250
    0.4940    0.1840    0.5560
    0.4660    0.6740    0.1880
    0.3010    0.7450    0.9330
    0.6350    0.0780    0.1840

Helios De Rosario <heliosdr>
Sat 09 Jul 2016 12:42:37 PM UTC, comment #15: 

The Mathworks controls the Matlab language and there was very little, in the end, that Octave could do.  If we don't eventually follow their syntax then we will get bug reports that scripts run with "hold on" are not properly plotted in Octave.  It has been two years since Matlab introduced their change so we have tried to give a buffer window for people to change their scripts.

As for workarounds, the obvious one is to write code that does not rely on auto-progression.  If you want a green line, code a green line.  This has the advantage of communicating, even to programmers years away, what the intent was.

Matlab has moved to storing the next color and line index style as properties of the axes object.  One option, mentioned by Helios, is to reset the "colororderindex" property to 1 after each new plot addition.

Another method is to change the "ColorOrder" and "LineStyleOrder" properties to single values so that even though rotation happens, it comes back to the same value.


hold on
set (gca, "ColorOrder", [R G B]);
plot (Line1_Seg1)
plot (Line1_Seg2)
plot (Line1_Seg3)
set (gca, "ColorOrder", [R2 G2 B2]);
plot (Line2_Seg1)
plot (Line2_Seg2)
plot (Line2_Seg3)

 

Rik <rik5>
Group administrator
Fri 08 Jul 2016 11:19:24 AM UTC, comment #14: 

Hi. In the changeset there is a reference to the property "colororderindex" of axes. I have not tried it, but I guess that this might reproduce the older "hold on":

plot(x1)
set(gca,"colororderindex", 1)
plot(x2)

If x1 contains more columns that the number of colors in the colororder set, after rolling over the list it will change the style of the line, according to the property "linestyleorder", if I understood correctly the code. You might also want to reset the "linestyleorderindex" to 1.

I also would have preferred to keep the flexibility of holding "on" and "all" as separate behaviors, but if it is not more complicated than that, I think I can live with that change.


Helios De Rosario <heliosdr>
Fri 08 Jul 2016 09:49:20 AM UTC, comment #13: 

An opportunity missed, please do not also copy Matlab help documentation inconsistencies in this area.

What is your recommended way to reproduce the former 'hold on' functionality (which would have been better described as 'hold all', presumably the reason Mathworks programmers didn't realise what it did)?  This is needed when you want to plot a line in segments using multiple calls.  The workaround in Matlab is to always specify the colour and linestyle in the plot call, and do not rely on the auto-progression.

Michael Tombs <mstombs>
Thu 07 Jul 2016 10:40:32 PM UTC, comment #12: 

Rik:  Thanks very much for cleaning this up. This has been
a long standing problem. I will try some tests, but it is
pretty clear that you have done the right thing. Thanks!

Michael Godfrey <godfrey>
Group Member
Thu 07 Jul 2016 08:16:27 PM UTC, comment #11: 

I completely overhauled Octave's broken handling of the ColorOrder and LineStyleOrder properties in this cset http://hg.savannah.gnu.org/hgweb/octave/rev/9121d6584f6a.

Octave is now Matlab compatible.  "hold all" has been deprecated.  "hold on" now continues using colors, styles from ColorOrder and LineStyleOrder rather than always plotting each new addition with the first color and style from those graphic properties.

This will be a part of the 4.2.0 release scheduled for September, 2016.

Rik <rik5>
Group administrator
Tue 09 Jun 2015 11:24:11 AM UTC, comment #10: 

In Version 4.0.0 the behaviour after "hold on" is still inconsistent.

"hold off" and "hold all" do what is documented, but "hold on" resets only the color of the first curve (normally blue), and does the same as "hold all" for the rest.

If the decision is to go on with matlab, "hold on" should be equated to "hold all". That should fix the problem. But I prefer the distinction between both of them, as described in the documentation.

I think that the patch attached solves the issue. At least it does in some tests that I have tried.

(file #34185)

Helios De Rosario <heliosdr>
Thu 01 Jan 2015 04:32:28 PM UTC, comment #9: 

Why copy the lousy move by Matlab?  I have around 1000 calls to "hold" in my current Matlab project, which will all need to be reviewed due to Matlab's unnecessary change/reduction in functionality in Matlab R2014b+.  They have also changed graphics handles to objects, which means all existing code must be reviewed - but at least that crashes any code that expects a numeric, but this change, (and a change to the default colour order) is 'silent' - it is just the appearance of figures, so needs detail manual review.

I have various plots that deliberately have gaps in lines, or are overlayed with symbols at reduced Nos of points - now need to explicitly decide what colour in every case or use some of these tips, suitably wrapped with version protection which will slow all old code down...

"if verLessThan('matlab','8.4.0')
   % execute code for R2014a or earlier"

http://blogs.mathworks.com/loren/2014/11/05/matlab-r2014b-graphics-part-3-compatibility-considerations-in-the-new-graphics-system/#comment-44541

Surely you can do better?

Note in R2014b "hold on" now does the same as "hold all" and "hold all" syntax "will be removed in a future release".

Fortunately Matlab R2014b is unusable slow when plotting large datasets typically 10-20x slower than R2014a (30 seconds to 5 minutes, I have some scripts that take 10 minutes...), so we will not be upgrading to that version - will Octave be an option?

Michael Tombs <mstombs>
Sun 23 Nov 2014 08:32:57 AM UTC, comment #8: 

Seems reasonable to go with the new Matlab.
This will be needed in the future (unless
Matlab switches again).

Michael Godfrey <godfrey>
Group Member
Sun 23 Nov 2014 04:50:47 AM UTC, comment #7: 

Should we just leap ahead to compatibility with 2014b?  In that version 'hold all' is equivalent to 'hold on'.  In that case we just make that change and the bug is fixed.  Trying to replicate the old Matlab behavior is much harder.

Rik <rik5>
Group administrator
Sun 23 Nov 2014 04:32:38 AM UTC, comment #6: 

'hold' applies to axes, not figures, so subplots should have individual hold values.  Although if someone can check that is always a fine idea.

Rik <rik5>
Group administrator
Sat 22 Nov 2014 01:17:38 AM UTC, comment #5: 

This new Matlab feature seems a bit odd. It may be
nice for some plots. But, does it also apply to
subplots? In the case of subplots most people would
expect the colors not to change.

Anyhow, can someone with R2014b try the subplot case?

Michael Godfrey <godfrey>
Group Member
Fri 21 Nov 2014 05:43:53 PM UTC, comment #4: 

@Rik I think you have understood me correctly. I don't own 2014b personally, but had this told to me by a colleague.

The page I linked puts it thus:

> In R2014b, when plot is called with hold on, MATLAB will use the next color in the color order for each call to plot. That gives plots with different line colors. In previous versions, each call to plot would start over in the color order so that each line would be the same color.


As far as colours are concerned, this is the same behaviour as "hold all".

Note that Octave's current behaviour is different from both the legacy and new behaviours.

A. Tombs <tombsar>
Fri 21 Nov 2014 05:17:15 PM UTC, comment #3: 

Just making sure I understand correctly, in the latest versions of Matlab with Handle Graphics 2, 'hold on' seems to be equivalent to 'hold all' in that the color choices continue from the last color used.

Rik <rik5>
Group administrator
Fri 14 Nov 2014 02:55:01 PM UTC, comment #2: 

Note that the latest (currently in beta?) version of Matlab has changed the behaviour of "hold on" so that the colourorder continued, not restarted, with each "plot" command.

http://blogs.mathworks.com/loren/2014/11/05/matlab-r2014b-graphics-part-3-compatibility-considerations-in-the-new-graphics-system/#964c1b3f-363b-4959-b5a4-94c9c3b45d46

A. Tombs <tombsar>
Fri 07 Nov 2014 04:06:01 PM UTC, comment #1: 

Confirmed.  The handling of plot color was reworked between 3.6 and 3.8 to solve other problems (bug #39344, bug #16955) and I'm guessing this bug was introduced then.  Marking bug as a regression.

Rik <rik5>
Group administrator
Fri 07 Nov 2014 12:11:20 PM UTC, original submission:  

Each invocation of "plot" should use the same colour order for data series (usually Blue Green Red etc.). The "hold on" command should cause the graphs produced by each "plot" command to be drawn on the same figure.

It seems to me that when a "hold on" is issued, the colour orders used for the subsequent "plot" calls are modified in a non-trivial way.

To reproduce, run the following:


x=[0;1];
y=[0,0,0;1,2,3];
figure;
plot(x,y);
hold on;
z = y+[0,0,0;0.5,0.5,0.5];
plot(x,z);


Expected: Six lines plotted with colours (in ascending order) Blue, Blue, Green, Green, Red, Red.

Observed: Six lines plotted with colours Blue, Blue, Green, Magenta, Red, Dark Yellow.

It seems as though "hold on" causes the first series of the second plot to use the correct colour (Blue), but the other series use incorrect colours from further along in the colour order.

This behaviour conflicts with Matlab and previous versions of Octave (I tested 3.6.0, which shows the expected behaviour).

Note that his behaviour is also different from the "hold all" command, which causes the subsequent "plot" calls to continue through the default colour order. "hold all" seems to be implemented correctly, giving Blue, Cyan, Green, Magenta, Red, Dark Yellow in my above example.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #34185:  __next_line_color__.patch added by heliosdr (885B - application/octet-stream - Patch to make "hold on" work as documented)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by heliosdr (Updated the item)
  • -email is unavailable- added by mstombs (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by tombsar (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-07 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2015-06-09 heliosdr Attached File- Added _next_line_color_.patch, #34185
    2014-11-10 rik5 StatusNone Confirmed
    2014-11-07 rik5 Item GroupNone Regression

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code