bugGNU Octave - Bugs: bug #50511, colororder property seems to be...

 
 

bug #50511: colororder property seems to be reset on plot

Submitted by:  Andrei Kramer <akramer>
Submitted on:  Fri 10 Mar 2017 06:48:29 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: InvalidAssigned to: None
Originator Name: Andrei KramerOpen/Closed: Closed
Release: 4.2.1Operating System: GNU/Linux

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 Jump to the original submission)

Sun 12 Mar 2017 08:13:31 PM UTC, comment #9:

Executing the test code from comment #3 in Matlab R2016a yields "plot command resets axes" with a blue line.

Since this is also the same behaviour as described by the original reporter and in other comments, closing report as invalid.

The slightly modified code from comment #0 that produces the output with the colororder as expected by the OR:

Markus Mützel <mmuetzel>
Project Member
Sun 12 Mar 2017 07:08:49 PM UTC, comment #8:

Octave is designed to run Matlab scripts without modification. The Mathworks has defined how the "ColorOrder" property is to be implemented. You might not like their specification, but it is their language to do with as they please. Unless Octave is incompatible, for example the test code from comment #3 produces a different result when run under Matlab, then I don't see a bug here.

Rik <rik5>
Project Administrator
Sun 12 Mar 2017 06:35:17 PM UTC, comment #7:

So, are you saying that it is alright that set(gca,"colororder",CO) never does anything unless the defaults are changed or the "NextPlot" property is set to "replacechildren", and only then?

So, you are ok with this

producing a plot with the default colororder (see attached picture). So, the get property gets the misleading gray() colororder, which doesn't reflect the actual graphic.

Note how set xtick worked as expected, but the colororder property did not. If this is the expected behaviour, then your expectation is incorrect. Some consistency should apply with these settings.

I will include an updated testcase and results.

(file #39979, file #39980)

Andrei Kramer <akramer>
Fri 10 Mar 2017 11:06:49 PM UTC, comment #6:

Check the documentation for colororder carefully. It is doing what is documented.

Rik <rik5>
Project Administrator
Fri 10 Mar 2017 08:33:09 PM UTC, comment #5:

Setting:

is a workaround.

But, it should also work without changing the defaults. So there is incorrect behaviour here. Either plot() then set() should do it or the other way around, neither does.

When you changed the status to "Works For Me" did you actually check the colour of the lines?

Andrei Kramer <akramer>
Fri 10 Mar 2017 08:21:22 PM UTC, comment #4:

Well, I tried to change the order (before I posted this bug).
Plotting first, then changing the colororder property has no effect on the plot. Issuing a command like ylim(), that could potentially cause the plot to update, doesn't help with the colors.

But, setting the colororder after plot() will make my little if statement go to printing the "colororder worked." line.

The plot does not change however.

Update: I also tried it with octave 4.2.0 on Gentoo Linux, same problem in both cases. So, it doesn't seem to be my specific build.

So, in summary:
plot() then set(gca,'colororder',CO); does not change the plot.

@rik5: doesn't your test-code show that my proposed order is correct?
I see
So, this property is supposed to be set before plotting.

And, besides, I think that it should work either way, ideally. But, I'd be content if one of the orders worked.

Andrei Kramer <akramer>
Fri 10 Mar 2017 07:55:31 PM UTC, comment #3:

Are you sure this isn't the correct behavior? See the equivalent ColorOrder property for Matlab at http://www.mathworks.com/help/matlab/ref/axes-properties.html.

The ColorOrder property belongs to the current axes. If you issue a new plot command the old axes gets reset. If you want a persistent colororder you can either use 'hold on' for an individual figure, or 'set (0, "DefaultAxesColorOrder", ...) to set a global default.

Test code for both Octave and Matlab:

Rik <rik5>
Project Administrator
Fri 10 Mar 2017 07:10:48 PM UTC, comment #2:

Oh wait. This may be proper behavior. I think "plot" resets almost everything and modifications have to come after the plot command. Isn't that the standard concept? Or maybe it doesn't apply for some features like color maps, don't know. Or, there might be some global settings via the special plot handle 0. Sometimes

set(0, ...)

does some magic stuff.

Dan Sebald <sebald>
Fri 10 Mar 2017 07:06:38 PM UTC, comment #1:

If you are building from source, the easiest way to locate the pertinent code or script is to use "grep". First, keep your build directory separate from the source tree (see "configure" etc.). Then, go to root of the source tree and try:

until something useful seems to appear. Having done that here, it looks to me that none of the scripts (i.e., .m files) set colororder at a base level (there are plenty of demo scripts that call the "set('colororder')" command). So it must be C++ code:

Locating the source of the issue isn't a precise process.

Dan Sebald <sebald>
Fri 10 Mar 2017 06:48:29 PM UTC, original submission:

ColorOrder

a set colororder property is reset when plot() is called.

It is a freshly compiled octave-4.2.1

Example

produces the output:

and of course a plot with default colours.

Further Information

There was this bug [bug #39291](https://savannah.gnu.org/bugs/?func=detailitem&item_id=39291) for an older version and different OS, so it's probably a different thing.

where could I possibly begin to investigate why that is?

This is also happening in Ubuntu's build of Octave 4.0.3, so it is probably unrelated to the change of the default colors.

Andrei Kramer <akramer>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #39979:  ColorOrderTest2.m added by akramer (210B - text/x-objcsrc)
file #39980:  WrongColorOrder.png added by akramer (9KiB - image/png)
file #39967:  ColorOrderTest.m added by akramer (384B - text/x-objcsrc - test script, same as in submission)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mmuetzel (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by sebald (Posted a comment)
  • -unavailable- added by akramer (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 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 12 Mar 2017 08:13:31 PM UTCmmuetzelStatusWorks For Me=>Invalid
      Open/ClosedOpen=>Closed
    Sun 12 Mar 2017 06:35:17 PM UTCakramerAttached File-=>Added ColorOrderTest2.m, #39979
      Attached File-=>Added WrongColorOrder.png, #39980
    Fri 10 Mar 2017 07:55:31 PM UTCrik5StatusNone=>Works For Me
    Fri 10 Mar 2017 06:48:29 PM UTCakramerAttached File-=>Added ColorOrderTest.m, #39967

    Back to the top


    Powered by Savane 3.1-cleanup1